Context Engine

The Problem

Context is not a bigger prompt. It is infrastructure.

Today's coding assistants don't actually understand your codebase. Every question starts cold. The model re-reads files, follows imports by hand, and rebuilds context from scratch in the prompt window. The same project. The same architecture. Every single turn.

For a small repo, you don't notice. For a real production system — with dozens of services, hundreds of packages, decades of decisions encoded in the structure — the cracks show fast.

Context windows aren't memory. A larger window just delays the failure. The model still has to discover the relevant pieces, every time, by reading. As the codebase grows, more of the window goes to navigation and less to thinking.

Retrieval is shallow. Vector search pulls back text snippets that look related. It can't tell you which callers depend on this function, which interfaces it satisfies, which concepts it implements, or which other modules quietly mirror the same idea under different names.

Every session forgets. Whatever the model worked out about your code last time — the patterns it inferred, the architectural relationships it noticed — evaporates the moment the session ends. The next question pays for the same discovery work again.

Why Retrieval Falls Short

The industry's answer to large codebases has been retrieval: chunk everything, embed it, search by similarity, paste the top results into the prompt. It's a useful primitive. It is not understanding.

Snippets aren't structure. A function definition is meaningless without its call graph. A type isn't useful without its implementations. Retrieval returns text; reasoning needs relationships.

Similarity isn't relevance. The chunk that embeds closest to your question is often not the one that answers it. The right answer might be three hops away — a caller of a caller of a helper — that no vector will surface on its own.

Recall isn't reasoning. Even with perfect chunks, the model still has to derive the connections in the prompt: who uses what, how the pieces compose, where the boundaries are. That derivation burns tokens and produces inconsistent answers.

What's needed isn't more text in the window. It's a structure the model can query — a graph the model can walk — and a loop that learns from every walk.

What Context Engine Does

Context Engine moves codebase understanding out of the prompt and into a persistent, queryable substrate.

At index time, CE walks your project and routes each file through a language plugin. It extracts a property graph: symbols, namespaces, concepts, and the relationships between them — calls, imports, implementations, references. Everything lands in a local SQLite database.

At query time, the model doesn't read files. It activates the graph. A strategizer agent picks anchors. An activation layer propagates through related nodes. Six cognitive tools fan out to retrieve call graphs, references, cross-project matches, concepts, file context, and namespace summaries. A reviewer validates and enriches the results. A synthesizer writes the final answer.

At learn time, Hebbian-style updates strengthen the edges between nodes that co-activate during real queries. The graph keeps adjusting to how you actually use the code.

Structured retrieval. Multi-step reasoning. Memory that survives the session.

The Cognitive Loop

Every query runs through a fixed cognitive loop. It is not a single LLM call — it is an engine with stages, each one playing a specific role.

query → Strategizer → Activation → Fan-out (6 tools) → Reviewer → Synthesizer → answer

Strategizer. Reads the question against the project's base prompt and architectural notes. Identifies which parts of the graph to anchor into and which cognitive tools to dispatch.

Activation. Propagates through the substrate from anchor nodes. Edges with higher learned weight light up faster. Top-K nodes per turn become the working set the next stages reason over.

Six cognitive tools. Specialized retrievers running in parallel: call graphs, references, cross-project matches, concepts, file context, namespace summaries. Each contributes a different shape of evidence.

Reviewer. Inspects the surfaced evidence, decides whether the picture is complete, and either enriches it or requests another loop. Up to max_loops iterations, configurable per project.

Synthesizer. Produces a grounded answer that cites the graph nodes it relied on. The trace is auditable end to end.

Index Once, Reuse Forever

Indexing isn't a side effect of a single question. It's a first-class operation that produces a durable artifact.

ce project init
ce index .
ce index . --watch

Incremental by default. A content-addressed hash per file means CE only re-extracts what changed. Watch mode keeps the graph live as you edit. --full forces a clean rebuild when you want one.

The substrate lives at ~/.ce/graphs/local.db — a real database, not a black box. You can inspect it, back it up, diff it across branches, ship it with your repo if you want. CE never depends on a remote service to answer a question about your code.

Indexing is the bill you pay once. Every query after that runs against structure, not raw text.

Cross-Project Intelligence

Most teams don't work in a single repo. They work across a constellation of services, libraries, and applications that share ideas without sharing code.

CE lifts nodes from each project into an org graph (~/.ce/graphs/org.db) and detects cross-project edges: the same concept implemented in two services, the same pattern repeated across libraries, the same vocabulary used with subtly different definitions.

Org-level concept vocabulary makes this explicit:

ce config org-concepts add --term "event-sourcing" \
  --definition "..." \
  --related "cqrs,domain-events" \
  --synonyms "event-driven"

Ask a question in one project and CE can pull in the matching implementation from another. Architecture decisions become traceable across the whole portfolio.

Local-First by Design

CE runs on your machine. The graph is yours. The audit log is yours. Your code never leaves your environment unless a query explicitly calls an LLM provider — and even then, only the minimal, relevant nodes go in the request, not your whole codebase.

~/.ce/
  meta.db        — project registry, paths, settings, API tokens
  audit.db       — sessions, turns, access log
  graphs/
    local.db     — current project's knowledge graph
    org.db       — org-wide graph (cross-project intelligence)

ce.yaml          — project-level config (in your repo root)

All storage is SQLite. No CGO outside of tree-sitter. Single Go binary on macOS, Linux, and Windows. Works offline for everything that doesn't need an LLM provider — and you choose which provider you want.

Auditability is the default, not a feature. Every session, turn, and access is logged. You can see exactly what the engine retrieved and what it sent.

Integrations

CE is designed to disappear into the tools you already use.

MCP server — ce server start exposes an MCP endpoint over SSE for remote use and a hidden stdio transport for local IDE integration. Native support in Cursor, Claude Code, Claude Desktop, and any MCP-capable client.

{
  "mcpServers": {
    "ce": {
      "command": "ce",
      "args": ["mcp-stdio"]
    }
  }
}

REST + WebSocket API. The same server exposes/api/v1 for tooling and a WebSocket endpoint for streaming queries — the surface that powers CE Studio.

Interactive TUI. ce query with no arguments opens a Bubbletea-based terminal UI: ask questions, watch the cognitive loop run, inspect retrievals as they happen.

Scriptable CLI. Every command is one-shot friendly. Drop CE into CI for code review, indexing on commit, or automated architecture checks.

Extensible by Plugin

Languages are not hardcoded. CE delegates indexing to plugins — TypeScript modules compiled to WebAssembly that teach CE how to read a language or framework, what symbols to extract, what concepts the code contributes, and optionally what custom analysis passes to run.

Default plugins ship for Go, TypeScript, Python, and PHP. Adding support for a new language, dialect, or framework is a matter of writing a plugin against the SDK — no fork of CE required.

Plugins are authored, sandboxed, and validated in a sibling project, ce-plugin-sdk, which provides the types, host bindings, sandbox, ESLint rules, and a create-ce-plugin scaffolder. Plugins published as .wasm drop straight into ~/.ce/plugins/.

Inspect Everything

An engine you can't see is one you can't trust. CE pairs with a dedicated inspector UI, CE Studio, that connects to a running CE server and gives you a window into the substrate.

Graph explorer. Visualize the indexed knowledge graph. Walk symbols, callers, concepts. Watch activation propagate through real queries.

Query workbench. Run questions against the engine, stream the cognitive loop live, and see which nodes and tools contributed to the answer.

History and traces. Every past session is replayable. Inspect the strategizer's plan, the reviewer's critiques, the tools that fired, and the final synthesized answer.

Studio is optional — CE is fully usable from the CLI and over MCP — but during architecture work or debugging weird answers, it's where the engine becomes legible.

CLI

ce project init          # Register a project, write ce.yaml
ce index .               # Index (or reindex) the codebase
ce index . --watch       # Live reindex on file changes
ce query                 # Interactive TUI
ce query "how does X work?"  # One-shot question
ce server start          # Start MCP + REST + WebSocket server
ce config show           # Print merged config (flags, project, global)
ce token create          # Issue an API token for the server
ce plugin list           # Inspect loaded language plugins

Single Go binary. macOS, Linux, Windows on amd64 and arm64. Also distributed as @atheory-ai/ce on npm for Node-based dev environments.

Get Started

npm install -g @atheory-ai/ce
export ANTHROPIC_API_KEY=sk-ant-...

cd ~/your-project
ce project init
ce index .
ce query "where does authentication happen?"

Or download the binary from GitHub Releases. Plugins for Go, TypeScript, Python, and PHP are embedded in the released binary.

Philosophy