The context tax: why MCP access isn’t enough for AI agents

We took a frontier coding agent, gave it Atomic intents, and then switched off every code-search tool it had. No semantic graph. No content index. Not a single query against the codebase.

It beat the same agent with every tool we could give it. Acceptance went from 60% with plain Git and an LLM to 90% with intents alone, on real Drizzle ORM issues, blind-scored, at the same cost per accepted change.

That wasn't the result we designed the benchmark to find. We expected code intelligence to be the story. Instead: the agent that knew why it was working beat the agent that had more ways to search. That's uncomfortable for the way the industry is building agentic DevOps right now.

The three-day ticket

A one-line ticket like PAY-1427, "authorization fails for delegated admins after migration," takes a good engineer three days, three standups, and two peer reviews to close. Almost none of that is writing code. It's reassembling why the code looks the way it does from Jira, a Confluence page called "final v3," a review comment nobody copied into the ticket, a red Jenkins build, and whatever Harness says is actually running.

Hand that ticket to an agent with MCP and it can reach every one of those systems. What it can't do is know that the records it gets back describe the same change. The joins were never written down. They lived in the engineer's head and in conventions like an issue key in a branch name. So the model does the join, probabilistically, paying in tool calls, tokens, and wrong guesses, and the next agent does it all again.

The root cause isn't the tools. It's that the relationships between them are conventions, not data. An issue key in a branch name is a string a human hopes matches. A typed edge, intent → satisfiedBy → change, is a fact a machine can traverse, validate against an ontology, and refuse when it's missing. The delivery stack has fifteen years of the first kind and almost none of the second.

That's the context tax: paying models, over and over, to infer relationships that were never recorded as traversable links in the first place.

What if the change carried its own context?

That's the question Atomic is built around. Work starts as an intent: why this exists, which acceptance criteria define done, what's in and out of scope, and which tasks satisfy which criteria. Tasks point at files. Changes point at the files they actually modified. Evidence points at the criterion it verifies and the repository state it observed. Reviews point at the exact change they judged. Memories carry decisions forward.

Every arrow in that diagram is a typed edge in a local semantic change graph, validated before it becomes trusted context. Walk forward from an intent to the code and evidence it produced. Walk backward from a file in today's working copy to the reason it exists.

For PAY-1427, the "final v3" decision is a memory on the intent that created the role. The review-comment constraint is a constraint on that intent. The failing test is evidence pinned to the state it ran against. The agent starts where the engineer ended up after three days, every session. Jira, Confluence, and your CI/CD tools can stay where they are; what moves is where the durable identity of a change lives.

What if we could prove it?

That's a nice architecture story. It's also the kind of thing a founder would say. So we built a benchmark designed to make us uncomfortable: ten real, post-cutoff issues from Drizzle ORM 0.45.2 (about 103,000 lines of TypeScript), nine configurations mixing frontier and open-weight models with raw Git, Atomic intents, code intelligence, review, and different reasoning levels.

The surprise: the agent with no code queries won

The cleanest comparison put three frontier configurations side by side: pure Git + LLM, Atomic with full code intelligence, and Atomic intents with code-query access switched off.

Intent-only beat both. Not because code intelligence is useless, but because in a cold project with a strong model, the lift came from the agent knowing why it was working, what done meant, and what it wasn't allowed to touch.

Where the money actually moved

The frontier result is about acceptance. The open-weight result is about economics.

Acceptance up 75% relatively, cost per accepted change down 39%, and about eight minutes slower per task. The intent ceremony itself was roughly 7% of model cost and 2% of step wall time; the rest was the agent doing more engineering against explicit obligations. Cheap tokens didn't make delivery cheap. More of the changes being worth keeping did.

Better search doesn't fix a missing edge

The natural objection is that the fix is better search. We believed a version of that too, and this is where it fell apart.

In one frontier + Atomic treatment, the agent issued 153 successful code-intelligence queries across ten tasks and still performed 314 ordinary search-and-read cycles on top of them. So we reran with a hard cap of three queries per task.

Queries dropped 80%. Search and reading dropped 29%. Acceptance and cost didn't move. The agent swapped graph queries for grep, because fast retrieval had never given it a strategy for which context mattered. One cell that exhausted its budget spent 1,040 model steps, 92.5 minutes, and $9.39 to change zero files.

That's the context tax in miniature. And notice the conditions: one repository, one local index, sub-second queries, every result real. The agent had the best retrieval setup we could build and still couldn't turn it into fewer reads, because retrieval doesn't tell you which result is the reason the code looks the way it does. That edge was never recorded, so no amount of search speed produces it.

Now put MCP in that picture. The agent isn't searching one local index anymore; it's searching Jira, Confluence, GitHub, Jenkins, and Harness, each over the network, each with its own identifiers, permissions, and idea of what "the change" is. MCP makes every one of those calls clean and standardized, and that's genuinely valuable. But look at what the 153-query result says will happen next. The agent gets five sets of results back and has to decide, probabilistically, which ticket, which page, which PR, which build, and which deployment belong together. The join the benchmark showed failing inside a single repository now runs across five systems, with more calls, more tokens, more stale records, and the same missing edge at the center.

Code intelligence makes retrieval precise. Intent makes it purposeful. You need the second before the first pays off, and MCP only gives you the first.

The best system we found wasn't the fastest

The configuration that won on quality paired a cheap open-weight worker with Atomic and a frontier model as an independent reviewer. The configuration that lost was the one most teams reach for first: the frontier model, alone, told to think as hard as it can.

The reviewed pipeline delivered the highest quality in the matrix at 41% less per accepted change than pure frontier, and about six times slower. It's built for asynchronous, consequential work, not the edit you want back in four seconds.

Max thinking went the other direction on every axis. It produced the most expensive accepted change in the entire benchmark, $1.82, more than double the next-worst arm and 4.7 times the same model at low reasoning ($0.39). It also had the lowest quality of any frontier configuration and lower acceptance than the plain Git baseline. The model spent 38k generation tokens per accepted change reasoning about context it didn't have, and the extra reasoning bought nothing. Thinking longer about a missing edge is not the same as having it.

One task shows why the cheap-worker-plus-reviewer pipeline won instead. The worker implemented a naming convention, wrote tests for it, and went green. The convention was the opposite of what the issue asked for. The reviewer, holding the intent and criteria, caught the inversion. A test proves code matches a test; it can't prove both match the reason the work exists unless that reason is part of what the reviewer can see.

Stop paying to rediscover the reason

The thirty green, empty runs didn't fail because the repository was out of reach. They failed because reaching it didn't tell them what the change was for. That's the same failure hiding inside agentic DevOps. Wrapping the old APIs in agents automates the old handoffs. MCP standardizes access to the old silos. The model still rebuilds the change from the pieces, every session.

Atomic's bet is that the change should carry its own context: intent, criteria, code, evidence, provenance, review, and memory in one local semantic graph. The next agent walks the edges the last one recorded instead of searching five systems and hoping the strings line up.

The cheapest context is the context you never have to reconstruct.