← Back to overview
System Overview

How IDEAgent Fits Together

Think of IDEAgent as a small graph, not a pile of boxes. A few focused components sit as nodes, connected by clean edges: the plugin lives inside PyCharm, the backend runs as Docker containers, and file watchers reach out to each machine you work on. Follow any node to read its details.

The graph

Each node is a component. Follow the arrows to see how a request travels — and click any node to read its details.

In PyCharm · IDE level
IDE Gateway Plugin The GUI in your IDE — chat, tasks, edits, local voice Open → RAG File Watcher Also a plugin — watches your files, keeps the index current Open →
↕talks to the gateway
In Docker · containers Gateway Runs the agent, keeps you in the loop, calls your model Open →
↕reads your project context
Project Context
MCP Server Finds and assembles the right code for the agent Open → RAG Server Local index of your code, learnings and docs Open →

The plugin (with its file watcher) runs in each teammate's IDE — two machines in the demo, and they register themselves, so more can join.

A request, end to end

1
You ask
You type in the plugin; it hands your message to the gateway.
2
Agent gathers context
The gateway's agent asks the project context for the right code.
3
Agent acts
It plans, uses its tools, and proposes or makes edits — pausing for your approval when you ask it to.
4
Index updates
The file watcher notices the change and refreshes the index, so the next request sees it.

Privacy is the whole point

Running locally gives you the strongest control over where your code and context are processed, so that's the path we build for. IDEAgent is multi-user by design, though the first release rolls out to a limited number of users while our infrastructure catches up; serving several projects in parallel from separate workstations is already tested. An enterprise version is on the way. To run entirely offline you point it at Ollama and nothing leaves infrastructure you control — see the local hardware setup for what that takes.

None of the backend nodes above — plugin, gateway, MCP server or RAG server — send product-usage telemetry back to us: no analytics, no usage tracking, no phone-home. Outbound calls go only to the model provider you choose and to optional services you configure yourself, and we ship ChromaDB's built-in telemetry disabled by default.

Optional redaction of tool and terminal output. When you enable it, the gateway replaces detected secrets — IP addresses, emails, API keys and tokens — with placeholders in tool and terminal results before that output is sent onward to the model. It filters what those results contain; it does not cover text you type or paste into the chat yourself. When you run fully local with Ollama, nothing leaves your infrastructure in the first place.

What it needs to run

Containers
Docker Compose — the backend nodes come up together.
Model provider
Your choice of OpenAI, Anthropic, Google or a local Ollama endpoint — the gateway builds the model through one multi-provider factory. For fully offline work, point it at Ollama; we can ship a self-contained Ollama if it isn't already installed as a service.
Hardware
Runs on CUDA GPUs, and on shared-memory boxes like Dell laptops or Macs. On non-CUDA machines, RAG indexing quality degrades.
Voice (optional)
The plugin offers speech-to-text (Whisper) and text-to-speech (Piper). Pre-install them and the plugin detects them on its machine.