On Agents Working Alone

by Andrei Roman

Every task closed. Every test passed. The system still fell apart.

I built a code indexer. It maps symbols, callers, and module boundaries across a repository, and it tells the truth about what it doesn't know. I built it for my agents, and instructed my agent-manager to use it.

Then I audited the build logs.

My agents weren't using it.

Worse: when they discovered, mid-task, that two modules depended on each other in a way nobody had written down, they wrote nothing down either. The discovery lived for one session. Then the session ended, and the knowledge died with it.

Every task they ran was correct. Every test was green. The thing that makes a pile of correct changes into one system was nowhere.

The sticky note

Autonomy is bounded by relevance, not by volume. The agent answers what you ask. A colleague answers what you didn't. What nobody can ask on your behalf is the job.

Two failures, one drive

In Switchfinger I named the first failure: an agent wants to reach "done" so badly it deletes the check that would tell it whether "done" is true. That's the task level.

William Louth describes the same drive one level up, in Death by a Thousand Plans: a multi-agent system can satisfy every local delivery contract while gradually losing the program, the evolving conception of what the system's parts are and why they belong together. Each agent acts as directed. Each artifact is defensible. The conception that made them one thing becomes impossible to locate.

Same finger, bigger box.

My audit was the field report. The agents didn't skip the indexer out of laziness. They skipped it because using it costs a step, and a step delays completion. They didn't record the dependency because writing it down delays completion. Completion drive doesn't just skip verification. It skips learning.

More context did not help

My first response was the obvious one. Explain more. Plans, roadmaps, a vision document, layered instructions, progressive disclosure of everything an agent might need.

Context grew. Autonomy did not.

Steve Yegge ran the same experiment at larger scale and reported the limit case in Seats and Sunsets: his factory accumulated 400 rulings, 185 rules, and 650 refusal sites, until no work was legal and the machine stopped. Every rule had been earned by an incident. Nobody's job was curating them.

The mechanism is not mysterious. An agent's performance is bounded by what is relevant at the moment of action. Front-loaded context dilutes attention, breeds contradictions between rules, and raises the odds that the one line that mattered gets ignored. Companies are discovering this too, with vision decks and roadmaps instead of prompt files, just slower, because their loop runs on meetings.

What, intent, but not why

Here is the shape of the limit, as I see it from inside a large codebase.

On the small and the medium, agents are excellent. Give one a bounded module and it will find the bug, explain what the code does, and often reconstruct the intent behind it. A friend who writes firmware for unusual processors told me his job got easy: hand the agent the processor manual and the assembly comes out right.

What agents do not reconstruct is why the system is shaped the way it is. Why this boundary exists here. Which of three similar structures is the real one and which two are accidents of who built what, when. Which assumption from the system's first year still holds everything up. The veteran engineers I work with carry exactly that. When a tangled problem resists, they don't search; they go back to first principles, the handful of ideas the whole system was built around, and reason forward. That knowledge isn't in the code. It's in the history of decisions, and most of it was never written.

The agent reads the what. Sometimes the intent. Almost never the why. The why is the program.

The "unaskable"

Here is why no amount of explaining fixes it.

The ideal agent would ask for what it needs. Good harnesses now instruct that: ask instead of filling the gap. It helps. It cannot close the gap, for one structural reason:

An agent cannot ask about a concept it doesn't have.

It can't request the dependency nobody documented. It can't ask whether this task should exist, or whether three tasks are secretly one change. Those questions require a model of the whole that the task's framing excluded. The task defines what is visible. The unaskable is everything outside the frame that still matters.

Call it that: the unaskable. The class of information an agent cannot request because it lacks the concept to request it. It is the operator's irreducible contribution, and it is why "deploy the right information, at the right abstraction, at the right moment" is a skill rather than a config file. Doing it well requires a model of what this agent, in this state, does not know and would not think to ask. That's theory of mind, applied to a machine.

Why the model maker's harness wins

A public data point. Anthropic reportedly builds its own products largely with its own agent; its agent is widely considered the best in class. Microsoft, with vastly more resources, ships a competitor with near feature parity and more rough edges.

Feature parity is not model-harness fit. Anthropic trains its model on trajectories from its own harness, tunes the harness to the model's failure modes, and trains again. Its builders are its heaviest users, so every friction reaches someone with authority to fix it the same day. The loop runs at the speed of use.

A harness over several vendors' models, built by one team for other teams, can match the feature list. It cannot match the fit, because fit comes from the loop.

The lesson isn't "pick the model maker's tool." It's that the harness, and especially what enters it and when, is where raw capability turns into outcomes. That part was always ours.

The editing room

Hollywood solved a version of this once. LaurieWired tells it well: studios once enforced shooting ratios of 5:1, because 35mm was expensive. In the 1970s, cheaper film and portable cameras made the constraint obsolete. Shooting ratios exploded to 50:1, 100:1. Editing went from a back-office job to the center of production, and the editor's work became a continuous conversation with the director about vision. By the 2000s, digital made footage free, everyone shot 100:1, and entire genres were born from the surplus.

When footage is free, the scarce role is the one that holds the picture of the film while deciding what belongs in it.

Cheap generation does the same to software. Except code isn't footage: unused film costs nothing on the floor, while unedited code that reaches production compounds. And footage doesn't lie about itself. So the software editor can't work from taste alone. The editor needs instruments: characterization tests, conservation checks, gates that fail loudly. Verification is the editing.

What I changed

• The indexer is now in the critical path, not on the shelf. Before touching a module, the agent must run the impact query and paste the result into its plan. Optional tools don't survive completion drive. Gated ones do.

• A write step before "done." Any dependency or impact discovered mid-task is appended to a module ledger before the task can close. The next session reads the ledger first. Knowledge that isn't written isn't reusable.

• Conditional disclosure instead of front-loading. Context is attached to the step that needs it and retrieved when a trigger fires. Standing context has a budget and gets curated on a schedule, like any other fence.

• A conception document with authority. One versioned page: what the system's parts are, which distinctions are domain and which are process debris, and why each boundary exists. Read at every task start. Allowed to reopen finished work.

• A recomposition pass every N tasks, asking one question across completed work: does this difference come from the domain, or from how we divided the work?

Where the job is moving

Three conclusions emerge for me.

For now, agents excel at small and medium bounded problems and struggle with large interconnected systems. The boundary isn't context length. It's whether the problem fits inside a frame the agent can hold at once, with the why already supplied. Inside that frame, delegate freely. Outside it, watch the agent and guide it closely.

That boundary is where our job is moving. Not writing the parts. Holding the whole: deciding what the parts are, what counts as the same thing, which distinctions the domain supports and which are debris, when a finished plan has to reopen because building revealed it was wrong, and answering for the call. Louth ends his essay asking where, in our system of software production, the program is still allowed to exist as a living conception. The answer is a person. It was always going to be a person, because authority follows accountability, and accountability doesn't delegate.

And if we ever hand most of the coding to agents, we will still have to watch them closely. Not because they're careless, but because they're complete: they finish, and finishing is not the same as being right about the whole. The more of the work they do, the more the remaining human work concentrates in exactly the place they can't see.

One more thing, for whoever is training the next generation. The temptation is to let juniors execute with the agent and call it learning. Executing with an agent teaches nothing; the agent did the learning and discarded it at session end. Learning with an agent is a different act: use it to reach the first principles faster, then hold them yourself. The people who can do the job I just described are the ones who learned the why. The tool can help them get there. It can't carry it for them.

Agents working alone produce correct parts. Someone has to hold the whole. That job got scarcer the day generation got cheap, and it isn't going anywhere.