CodeAlive 3.0: From Context Engine to Code Research Agent

CodeAlive has been running in production since April 2025. We spent most of that time building, so the blog stayed quiet. Time to fix that.

Today we are introducing CodeAlive 3.0. The name covers the current generation of the product: a context engine hardened on real repositories, our own code research agent, a benchmark for measuring repository understanding, and a new Tool API and MCP surface for other agents.

Here is what changed and why we built it.

The context engine grew up

Early versions of CodeAlive focused on a familiar problem: finding useful context in a repository that is too large for an LLM prompt.

Production added less glamorous requirements. Repositories mix languages, generated code can swamp search results, symbols move, providers fail, and long processing jobs occasionally need to recover halfway through. We spent the year working through those cases.

CodeAlive now builds several views of a repository:

• symbols and their source content;
• a Repository Ontology for orientation;
• calls, references, and inheritance relationships;
• semantic and exact-text indexes;
• short descriptions of what individual artifacts do.

Repository Processing is incremental and split into retryable stages. Retrieval combines semantic search with exact search. An agent can get a map of the repository, find a relevant symbol, inspect its relationships, and then read the source before answering.

We have learned how this system fails as well as how it works. Production incidents led to better recovery paths, tests, telemetry, and operational tooling. That experience is now part of the product.

Our own code research agent

This spring we added the ContextResearchAgent, a read-only agent for questions about code.

It works against the processed repository rather than a shell checkout. Its research loop is straightforward:

1. Orient with the Repository Ontology or a bounded file tree.
2. Locate relevant code with semantic and exact search.
3. Follow calls, references, and inheritance.
4. Read the source used in the answer.

The details took longer. The agent has limits for iterations, tool calls, and wall-clock time. It detects repeated calls, compacts long research traces, and receives practical hints with tool results. If a request is repairable, the tool explains what to change instead of returning an empty result.

The agent now powers code research inside CodeAlive. It is also a useful test of our own interfaces. Awkward tool output becomes obvious when your agent has to use it all day.

RepoContextBench

A good demo can make almost any agent look capable. We wanted repeatable tests that would tell us whether a change to retrieval, prompts, models, or tools actually helped.

We built an evaluation system that we are introducing publicly as RepoContextBench.

Our internal evaluation asks practical questions about a real repository pinned to a fixed commit. Each question has weighted factual claims and source evidence. The agent writes a normal answer, and a fixed judge evaluates coverage, grounding, contradictions, and unsupported claims. We also record whether retrieval found the files containing the expected evidence.

In one clean 20-question internal run, CodeAlive's deep research mode with Qwen 3.6-35B-A3B scored 77.6 out of 100. This was a single run on an internal dataset under fixed judging conditions, so it is a useful regression signal, not a public leaderboard result.

RepoContextBench deserves its own post. We will publish the dataset design, judging method, evidence metrics, model and harness differences, and the limitations behind the scores there.

Tool API v3 and MCP 3.0

On July 11, we shipped Tool API v3, MCP 3.0, and version 3 of the CodeAlive skill and Claude Code plugin. MCP production is now on the 3.0.2 maintenance release.

Tool API v3 has eleven read-only operations. They cover:

• discovering available repositories and workspaces;
• orientation through ontologies and file trees;
• semantic and exact-text search;
• reading artifacts and files;
• traversing artifact relationships;
• querying repository metadata;
• delegated research through stateless chat when needed.

The API follows the way an agent researches code. Search returns useful leads, reading tools provide the evidence, and relationship tools help trace a flow without launching another broad search.

Every operation has a generated OpenAPI contract. Responses can include structured JSON, compact agent-oriented text, or both. Repairable requests, such as an invalid path or ambiguous repository selector, return clear retry guidance. Authentication, quota, transport, and unexpected server failures remain HTTP errors.

The public chat operation is stateless. A call must include the findings, artifact identifiers, scope, and constraints it needs. Agents with their own reasoning loop will usually get more control from the lower-level tools.

You can explore the Tool API reference, connect an agent with the MCP guide, or use our reference architecture for a code research agent.

More engineering notes to come

We have a backlog of things worth writing about: how semantic and exact search work together, what RepoContextBench can and cannot measure, how smaller models change tool design, and which production failures led to useful architectural changes.

This time we plan to write the posts while the work is still fresh.