Optimizing Agentic Development: The Signal Ratio
Contents
An agent’s intelligence isn’t a property of the model. It’s a property of the tokens you let through.
The conversation about AI coding agents has been stuck on prompts for two years. Better system prompts, better instructions, better personas. That conversation is mostly over. The work that matters now is the work around the model: the tools the agent calls, the context it reads, the way its loop is structured, and which model handles which step.
Most agent traces I’ve inspected — my own and other people’s — are mostly ceremony. I haven’t measured the share; it’s what reading the traces shows, not a number I can defend. File dumps the agent didn’t need. Re-reads of files it already had. Tool JSON that wraps three useful lines in two hundred lines of structure. Retries after a malformed call. “Let me think about this step by step” prepended to a 4,000-token system prompt. The reasoning is buried in the noise; the noise also makes the reasoning worse. Optimizing agentic development is mostly about turning that ratio around.
This post is the frame I’ve arrived at after a year of building tools in the space — symgraph, casual-review, colab, devc, genie. They’re not unified by what they do; they’re unified by what they refuse to do, which is waste the agent’s attention.
Inherent vs. Incidental Tokens
Fred Brooks’s No Silver Bullet (1986) split software complexity into two parts. Essential complexity is the irreducible difficulty of the problem — the thing you actually have to think about. Accidental complexity is the artifacts of our tools — build systems, language ceremony, import boilerplate. Brooks’s argument was that no single tool would 10x productivity, because programmers had already attacked most of the accidental complexity, and the essential remainder is just hard.
Agentic coding has the same split, with one important difference.
Inherent tokens are the tokens genuinely required to specify the task and inspect the load-bearing code. The bug report. The function with the failing assertion. The schema the agent has to honor. Removing them would make the task unsolvable.
Incidental tokens are everything else. The 200-line file read when twelve lines were needed. The directory listing dumped because the agent didn’t know where the symbol lived. The JSON envelope around every result. The retry after a tool-call schema mismatch. The verbose chain-of-thought on a system prompt the agent never actually consulted.
The difference from Brooks: incidental tokens aren’t just overhead. They actively poison the reasoning. Chroma’s context rot research tested 18 frontier models and found that all of them degrade as input length grows, with a U-shaped curve and roughly 30% accuracy loss for information in the middle of context. Even 1M-token windows rot at 50k. So an agent that solves a bug in 200k tokens where 8k were load-bearing isn’t just spending more dollars than an agent that solves it in 30k where 6k were load-bearing — it’s measurably worse at the next decision.
The metric that matters is the signal ratio: inherent tokens over total tokens. Today’s agents run at maybe 10–20%. Most of the work in agentic development optimization, across every category below, is moving that number up.
The rest of this post is three categories of incidental tokens worth attacking, ordered by payoff.
Beyond Grep
The single biggest source of incidental tokens is the agent reading whole files because it can’t query the structure of the code. An agent armed only with grep and read is a very fast intern with no IDE. To find a function, it greps. To understand the function, it reads the whole file. To understand callers, it greps again. To verify a refactor, it reads more files. Each step is text-walking the codebase to recover information an LSP or AST index already has indexed.
Mews published the cleanest data on this in early 2026. On the open-source MassTransit codebase (~5,500 files), an agent equipped with semantic navigation completed a non-trivial change in 21k tokens with one full-file read. The same task with grep-and-read tooling took 98k tokens and 43 full-file reads — a 4.6x bloat. On a 20,000-file proprietary codebase the ratio rose to 22k vs 235k tokens — 10.5x. Roughly 78% of the tokens in the grep-only run were incidental.
Cursor’s own internal numbers are smaller but pointing the same direction: their semantic search adds 12.5% average accuracy across models, with the gain rising to +56% success rate on codebases of 1,000+ files. The accuracy gain came from removing irrelevant context, not from adding more.
The architecture that wins is symbol-level. Tree-sitter or LSP parses the code; a graph stores symbols and their relationships; the agent calls a tool that returns the function, not the file. Serena wraps existing language servers (Pyright, rust-analyzer, tsserver) as MCP tools. Aider’s repo map PageRanks the symbol graph and fits the most relevant signatures into a fixed budget. CODEXGRAPH (NAACL 2025) formalizes the multi-hop case. My own symgraph sits in the same category — a Rust MCP server that builds a tree-sitter knowledge graph in SQLite and exposes symgraph-callers, symgraph-callees, symgraph-impact, symgraph-definition, and a dozen others. The whole point is that the agent never has to read the file to learn what’s in it.
This is the code knowledge graph argument applied to the agent’s tool surface. Vector embeddings, notably, have fallen out of fashion for this specific job — Sourcegraph dropped them from Cody Enterprise. Embeddings are good at “what’s vaguely related”; agents need “what calls this and what does this call,” which is a graph query. The 2025–2026 consensus is hybrid grep + semantic, with semantic doing the structural work and grep reserved for cases where you genuinely need substring matching.
The interesting question in 2026 isn’t “embeddings vs grep.” It’s why is your agent reading files at all when a language server already has the answer.
Token Minimization in the Loop
Once the retrieval layer is sane, the next category of incidental tokens lives inside the loop itself.
Tool output is usually 5–10x bigger than it needs to be. A linter that emits a fifty-line pretty diagnostic costs ten times what the same finding costs as a structured JSON object. This is why casual-review’s --format json emits one diagnostic per line as a single JSON object — it isn’t a feature, it’s the entire shape of the contract with the agent. Same binary, two output modes; the human gets ariadne rendering, the agent gets a stream of facts:
|
Anthropic’s token-efficient tool use (introduced with Claude 3.7) reports up to 70% output token reduction on tool calls, with a 14% average in early production use. The order-of-magnitude gains come from designing tool output for the agent in the first place rather than retrofitting compression on top of human-readable text.
Re-reading is a structural problem. Agents forget what they’ve already pulled in and re-fetch. The fix is either explicit memory (Anthropic’s memory_tool) or sub-agents that summarize and return condensed results to the orchestrator. Claude Code’s Explore subagent is exactly this pattern: a Haiku worker reads twenty files and returns a 1–2k token summary. The orchestrator never sees the files, only the conclusion. Anthropic reports their multi-agent research system uses 15x more tokens than chat and 4x more than single agents, but outperforms single Opus 4 by 90.2% on internal research evals — because the cheap workers absorb the bloat and don’t pollute the planner’s context.
Cognition has made the opposite argument for coding specifically: prefer single-threaded linear agents with hierarchical compaction, where a dedicated LLM compresses history into “key details, events, decisions” before the window fills. Both views are right in their domain. Coding agents need decision continuity — parallel agents make conflicting implicit choices because they can’t see each other’s traces. Research agents need parallel breadth. The shared insight is that you can’t let the raw trace grow unbounded — either compress it or shard it.
Prompt caching is free money. Anthropic’s prompt cache cuts costs up to 90% and latency up to 85% for stable prefixes, and on Sonnet, cache reads no longer count against ITPM rate limits. The cost of a long system prompt is therefore not “long system prompt” — it’s “long system prompt that changes.” Pinning the tool surface, the project map, and the style guide at the front of the context, and varying only what’s task-specific, turns 200k tokens of header into a near-free cache read after the first call.
Stack these together — semantic retrieval up front, structured tool output, summarizing sub-agents, cached prefixes — and the math compounds. A loop running on those four can carry 5–10x more inherent work in the same budget, which is the only thing that actually moves quality.
Model Balance: SLMs vs. LLMs
The last category is the most expensive piece of advice in modern engineering: use the best model. Frontier models on every step is the GPT-4-for-everything anti-pattern, and it’s still the default in most agent harnesses I see.
Belcak et al. at NVIDIA made the strong version of the case in June 2025: small language models are not just cheaper but more suitable for the repetitive, narrow, schema-constrained calls that dominate agent traces. Tool calling. JSON generation. Summarization. Retrieval ranking. The frontier reasoner plans; cheap specialists execute. Their cited gap: Llama 3 1B vs Llama 3.3 405B is 10–30x cheaper inference at comparable quality on those narrow tasks, and fine-tunes in GPU-hours instead of days.
RouteLLM (LMSYS) is the open-source router formalization — difficulty-classify the call and route accordingly. Reported numbers from their MT-Bench comparison: up to 85% cost reduction at 95% of GPT-4 quality. Production deployments cite 30–70% cost reduction with under 2% quality loss.
Anthropic ships this pattern in Claude Code itself. The Explore subagent is a Haiku worker; the planner is Sonnet or Opus. You’ve been using a router and a fleet of cheap specialists for months without anyone calling it that.
The personal-tools version of this is even simpler. My genie CLI takes Unix pipes and routes them to either ChatGPT or a local Ollama model:
|
Mistral-7B on local hardware is fine for commit-message summarization. Calling Opus for that is paying frontier prices for a job a 7B model finishes in 200ms — and you’re paying twice, because Opus’s verbose reasoning trace then gets stuffed into the next turn’s context and degrades the next decision via context rot.
The 2026 architecture isn’t agent-vs-agent. It’s a planner with a fleet of cheap specialists — a senior engineer with interns, not a roomful of principals.
The Signal Ratio
Pulling the threads together: the unit of measurement that should govern agent infrastructure work isn’t pass@1, and it isn’t tokens-per-task. It’s the signal ratio — inherent tokens over total tokens, on a representative workload.
A pass@1 metric tells you whether the agent finished. It doesn’t tell you whether it finished cleanly or by brute force. Two agents both passing the same eval, one at signal ratio 50% and one at 10%, are not the same agent. The 10% agent will fall over the moment the task gets large enough to exhaust its working memory; the 50% agent has 5x the headroom. The 10% agent costs 5x more to run. The 10% agent’s reasoning is 5x more polluted on every subsequent turn.
I haven’t seen anyone publish their signal ratio. Nobody’s eval card has it. Nobody’s pricing page mentions it. The thing I’d want coming out of this post is for agent vendors to start instrumenting it — what fraction of the tokens in a typical agent trace were load-bearing — and to publish that alongside the leaderboard scores. It’s the metric that aligns “good agent” with “cheap agent” with “agent that doesn’t degrade on long sessions.” Three goals, one number.
Brooks’s argument was that no single silver bullet would 10x productivity, because the irreducible essence had already been laid bare. Agentic development is the inverse situation: there’s no silver bullet, but there is enormous low-hanging fruit, because, going by the traces I’ve read, most of what today’s agents process is accidental. Every category in this post — semantic retrieval, structured tool output, prompt caching, sub-agent compaction, model routing — claws some of it back.
The model is the part you can’t change. Everything around it, you can.