← Back to overview
Component 03 · Project Context

Project Context — the web GUI

This is the memory of the system, and it comes with its own web GUI. It runs as a container and serves a browser interface at the container's address — for example http://localhost/ui. From there you manage the projects the agent knows about, inspect what it has indexed, and watch what it is doing — all on your own machine.

Open the GUI

The Project Context runs as a container. Once it is up, open a browser on the same machine and go to its address — the GUI is served under /ui:

  1. Point your browser at the container, for example http://localhost/ui.
  2. You land on Projects — the list of everything the agent knows about.
  3. The tabs across the top take you to the rest: Settings, Tools, Context Engine, RAG Collections and Logs.
Project Context web GUI showing the Projects list with registered projects
The web GUI. Each project card shows its path, type and when it was registered. From a card you can open its Learnings, review Changes, Edit its details or remove it — and Refresh re-reads the list.

Projects

A project is a folder the agent is allowed to understand and work in. The Projects tab is where you register them and keep them tidy:

  • Register a folder so it becomes part of the agent's memory.
  • Edit a project's details, or Delete it when you no longer want it indexed.
  • Learnings shows the notes the agent has saved about that project over time.
  • Changes lists the file changes recorded for it, so you can see its recent history.

Context Engine

The Context Engine tab lets you look at, and try, what the agent uses on every task — an indexed model of the project rather than a blind file read. From here you can browse a project's symbols and run a retrieval query yourself to see exactly what the agent would get back.

The context engine is the source of truth for a project's structure. It is how the agent understands how pieces fit together before it edits anything — which keeps its changes grounded in the real codebase rather than guesses.

RAG Collections

Retrieval is backed by a self-hosted store, and the RAG Collections tab is your window into it. Each project's indexed code and knowledge lives in its own collection, and it holds more than source:

  • Code, chunked around whole symbols so a result is a meaningful unit — a full function or class, not an arbitrary line range.
  • Learnings the agent has saved about the project.
  • Change history — before/after snapshots of edits.
  • Documentation that has been ingested for the project.

Everything here is computed and stored on infrastructure you control: the full codebase stays in your RAG instance, and the agent retrieves the chunks and embeddings it needs to work. When you configure a hosted model, that retrieved context is what gets sent to it — which is why we recommend a fully local setup (with Ollama) when you want nothing to leave infrastructure you control at all.

Tools & Settings

The Tools tab lists the actions the Project Context makes available to the agent through the Gateway — searching the context engine, reading a project's learnings and history, recording changes. The Settings tab holds the server's own configuration.

Keeping the index honest — the file watcher

An index is only useful if it matches the code on disk. The Project Context stays in sync with a companion file watcher that runs on each of your machines:

  • When a file changes and the change is recorded, the watcher on that machine uploads the exact local file.
  • The store re-indexes it, so the next query reflects the change.
  • Because each watcher reports its own address, this works even when the editing machine and the server are different hosts.

The RAG File Watcher is on the JetBrains Marketplace — view the listing or install it directly from your IDE.

Logs

The Logs tab shows what the server is doing in real time — registrations, indexing activity and queries — so when something looks off, you can see why without leaving the browser.

Hardware — indexing quality follows the GPU

Turning code into a searchable index is the compute-heavy part, and it runs best with a GPU. IDEAgent runs on CUDA-capable NVIDIA machines and on boxes with shared-memory GPUs — laptops and Macs — but the two are not equal:

  • NVIDIA (CUDA) is the recommended and tested configuration, and gives the best indexing quality.
  • Shared-memory GPUs (Dell laptops, Macs) work, but indexing quality degrades compared to CUDA hardware.
  • More VRAM and system RAM give more headroom for larger projects, especially when a local Ollama model shares the same machine.

Privacy by construction

Everything here stays on infrastructure you control: indexing runs on your own hardware, the collections live in a store you host, and retrieval returns only the small, relevant slices the agent needs. The file watcher may upload a changed file to the RAG server, and that server can be a different host from the editing machine — but both run inside your own infrastructure (for example, our container installed in your environment), so the codebase is never transmitted to an external model provider. Paired with a local Ollama provider on the Gateway, no code or context leaves infrastructure you control at all.

See the full architecture →