Why Coding Agents Underperform — The Four Fixable Limits

A coding agent fails at hour three for the same reason it failed at minute three. Not because the model got dumber. Because it ran out of room to think, lost track of what it had already done, shipped code no one verified, and picked the wrong tool from a menu of forty.

This is the mechanic view. The macro picture — what agent-driven development does to teams and expertise — is covered elsewhere. What practitioners ask first is narrower: why does the thing underperform, and is the ceiling the model or the setup? In practice it's mostly the setup. Four limits account for the bulk of bad agent output, and each one has a fix you can ship this week.

Limit 1: Context overflow

An agent's effective intelligence degrades long before it hits the token limit. Context windows are not a workspace you can fill to the brim. They're working memory, and working memory gets worse under load: instructions from the top of the window go soft, earlier decisions get re-litigated, the agent re-reads files it already understood and contradicts its own earlier edits.

The failure mode looks like this — the agent makes a sensible plan in step two, then around step twenty it quietly abandons the plan because the plan has scrolled far enough away that it's no longer load-bearing. Nothing errors. The work just drifts.

The fixes are structural, not prompt tweaks:

• Budget the window like a resource. Fresh sessions per task, not per day. A session that has touched ten files is a liability, not a veteran.
• Compress deliberately. Summaries, not raw transcripts, carry state across compaction. If you can't reconstruct the task from what the agent kept, the agent can't either.
• Put durable facts in files. Anything the agent must know at step forty belongs on disk — a plan file, a spec, a conventions doc — not in conversation history. Files are re-readable; memory is not.

We run coordinated multi-session work by treating each session as short-lived and giving it one file to read and one file to write. That pattern is described in running a company's development through coordinated Claude Code sessions, and it exists precisely because long single sessions drift.

Limit 2: State amnesia

Overflow's sibling. Even inside the window, agents don't reliably track their own state: what they've changed, what they've broken, what they already tried and why it failed. The classic symptom is the loop — the agent attempts a fix, it fails, and three steps later it attempts the identical fix with slightly different wording. It has no memory of the attempt because the attempt left no trace outside the conversation.

This is why replayability matters more than chat history. Our own agent operations run on structured JSONL traces: every tool call, every file delta, every decision point recorded as data. That's not observability for its own sake. It does three jobs:

1. Recovery. A crashed session resumes from the trace, not from the model's recollection of the trace.
2. Diagnosis. When output is wrong, you read the trace and see the exact step where it went wrong. Guessing is eliminated.
3. State handoff. A new session gets the trace summary, not the old session's vibes.

If your agent stack can't answer "what exactly did it do and in what order" without re-running it, you don't have state management. You have a chat log.

Limit 3: No self-verification

An agent will report success on code it never ran. Not out of deception — out of architecture. Generation and verification are different tasks, and a model checking its own output has the same blind spots as the model that wrote it. Confident, plausible, wrong.

The rule we operate by: agent output that hasn't been executed against a check doesn't exist. Two layers make that enforceable rather than aspirational:

• Tripwire evals. Small, fast, automated checks that run on every agent-produced change — the suite exists to catch known regressions, and it's tuned over time with the failure patterns you actually see. A silent LLM regression looks identical to a good output until something tests it. We keep a standing set of silent-regression tripwires for exactly this reason.
• Tests that can't be gamed by the generator. When agents write the tests too, verification quality collapses — the test suite starts asserting whatever the code happens to do. Mutation testing breaks that symmetry by mutating the code and checking the tests notice. The approach applied to AI-written test suites is the difference between a suite that proves something and a suite that flatters.

The same principle extends past code: any agent workflow needs an output gate that is independent of the output's author. Our production-hardening checklist is built on that assumption — hardening is what you add when you accept that the generator cannot certify its own work.

Limit 4: Tool-surface noise

Give an agent forty tools and it will use the wrong one with complete confidence. Every tool in the surface is a choice the model has to make on every step, and similar tools with overlapping purposes — three file readers, two shells, five ways to search — burn reasoning on a decision that should never have been a decision.

Scoped tool gating fixes it: each task profile gets the minimum toolset for that task class. The deploy-writing agent doesn't get production credentials. The docs agent doesn't get the database. Smaller surfaces produce fewer wrong-tool errors and, more importantly, make misbehavior legible — when the toolset is narrow, an unexpected call stands out immediately.

The gating also gives you an audit boundary for free. You can't review "what the agent could theoretically have done" across an unscoped surface. You can review a scoped one.

What this means in practice

None of these limits require a new model. They require treating the agent as a component in a system — one with a memory budget, a state record, an independent verification layer, and a scoped interface. Teams that ship all four fixes routinely get production-grade output from models they previously judged inadequate. Teams that ship none of them will conclude the technology doesn't work and be wrong about why.

Context overflow → design for short sessions and file-based state. Amnesia → replayable traces. No verification → tripwires and generator-independent tests. Tool noise → scoped gating.

Run agents inside those constraints and they hold up. Run them outside and no amount of model quality saves you. You built it. We optimize it.

If you're running agent-driven development in production and want the operating layer — traces, evals, gating — handled as infrastructure rather than habits, that's the work described in Governed AI Ops.

Frequently Asked Questions

Why do coding agents get worse on long tasks?

Context degradation. Effective reasoning quality drops as the context window fills, even well before the hard token limit — early instructions lose influence, earlier decisions get contradicted, and the agent drifts from its original plan. The fix is short-lived sessions, deliberate compression, and keeping durable state in files rather than conversation history.

What is state amnesia in AI coding agents?

State amnesia is an agent's failure to track what it has already done — files changed, approaches tried, errors hit. The visible symptom is repetition: the same failed fix attempted multiple times. Replayable structured traces (e.g. JSONL logs of every tool call and file delta) give you recovery, diagnosis, and clean session handoffs where raw chat history doesn't.

Can coding agents verify their own work?

Not reliably. The model checking its own output shares the blind spots of the model that wrote it, and will report success on code it never executed. Production use requires verification that's independent of the generator: automated tripwire evals on every change, plus tests designed so the generator can't game them — mutation testing is the standard check for that.

How do you stop an agent from picking the wrong tools?

Shrink the surface. Scoped tool gating gives each task profile only the tools that task class needs — the docs agent doesn't get database access, the deploy agent doesn't get unconstrained shell. Fewer overlapping tools means fewer wrong-tool decisions per step, and unexpected calls become immediately visible for audit.

Do I need a better model or better agent infrastructure?

Most underperformance traces to infrastructure, not model quality: context budget, state tracking, verification, and tool scoping. Teams with all four handled get production-grade output from mid-tier models; teams without them fail on frontier models. Fix the system before replacing the model.