For agentic workflows
How agentic AI coding workflows can avoid repeated context discovery
The short answer
Agentic AI coding workflows chain together many tool calls: searching, reading, editing, testing, and repeating, to complete a single task. Each step is a fresh chance to rediscover the same repository context, so unnecessary discovery can compound over a long-running agentic session far more than it does in a single one-shot prompt.
An agent working, with CodeMesh attached
This is the loop the page is about: the agent asks a structural question, gets the spans that answer it, and moves on. No repository crawl between the question and the answer.
- you
Where does the transport give up retrying, and what happens to the job when it does?
- codemesh
code-contextretry budget and exhaustion - src/transport/retry.ts:34
const MAX_ATTEMPTS = 5; - src/transport/retry.ts:72
if (attempt >= MAX_ATTEMPTS) return dead(job); - src/queue/dead.ts:19
export function dead(job: Job) - agent
retry.ts stops at MAX_ATTEMPTS, which is 5, and hands the job to dead() in src/queue/dead.ts. That moves it to the dead-letter queue rather than dropping it, so it stays inspectable.
What makes a workflow “agentic”
A one-shot prompt asks a model a question once and gets an answer back. An agentic workflow is different: it chains together many steps, searching the repository, opening files, making an edit, running tests, checking the result, and deciding what to do next, with the agent deciding along the way what step comes after the last one. A single coding task can involve dozens of these steps before it's done.
Why repeated discovery compounds in longer workflows
In a single prompt, repository discovery happens roughly once. In an agentic workflow, discovery can happen again at every step where the agent decides it needs to re-check something: after an edit, before running a test, before finishing up. The cost of unnecessary discovery doesn't just scale with how large the repository is; it scales with how many steps the workflow takes.
In an agentic workflow, discovery cost can multiply with the number of steps, not just the size of the repository.
Every tool call is a chance to re-discover the same context
Consider a realistic sequence: the agent searches for a service, opens the file, searches for its callers, opens a caller file, makes an edit, then, to be safe, re-searches for callers again to confirm nothing else was missed before finishing. Several of those steps are re-deriving the same relationship (who calls this service) that was already established a few steps earlier in the same run.
How structural context retrieval reduces the compounding
Structural code retrieval finds relevant source code using explicit software relationships rather than relying only on textual or semantic similarity. It can retrieve information based on relationships such as function calls, imports, dependencies, inheritance and containment, helping an AI coding agent identify relevant context more directly.
If a fact like “this function is called from these three places” is retrievable directly, an agent can ask for it once and reuse the answer at whichever later step needs it, instead of re-running a search-and-read cycle every time that fact becomes relevant again over the course of a long workflow.
MCP: how supported agents reach CodeMesh
The Model Context Protocol (MCP) is an open protocol that lets AI coding agents call external tools and context providers as part of an agentic session, in a standardized way. Rather than relying only on generic file-search and file-read tools, an MCP-compatible agent can query a dedicated context source directly as one of its tool calls.
CodeMesh is a context optimization layer for AI coding agents. It helps agents understand a codebase without repeatedly searching, opening and reading large amounts of source code, allowing them to work with more precise repository context and dramatically fewer unnecessary tokens.
Supported coding agents reach CodeMesh through MCP: issuing a structural context query as a single tool call in the workflow, in place of the multi-step search-open-read sequence that would otherwise have to run at that point.