The Workflow Has to Survive the Agent

Most coding-agent workflows begin with the agent itself. Pick a model, give it tools, load the repository, and ask it to make a change. That can produce excellent work. It can also produce work nobody else can safely continue, because the plan, discoveries, and reasons for each decision exist only inside one conversation.

The failure shows up the moment anything interrupts the happy path. The context fills up. A command stalls. A reviewer asks for a change. Production reveals a case the original task never mentioned. The next agent sees files and a diff, but not the chain of judgment that made them. It has to reconstruct the job from debris.

Our position is blunt: if the workflow depends on one agent remembering what happened, there is no workflow. There is a talented operator with temporary memory. A factory starts when the state of the work can outlive the operator doing it.

A plan that lives only in a prompt cannot coordinate anything. Put it somewhere the next stage can find it. Break the work into bounded pieces, name the condition that finishes each one, and record which pieces depend on which. Now a stalled task has a restart point instead of a mystery.

This does not mean preserving every thought an agent produced. Most of that is disposable. Preserve decisions that constrain later work: the requirement being satisfied, the boundary that must not move, the evidence still missing, and the reason a tempting approach was rejected. That is working state. A transcript is merely exhaust.

Once the plan has an address, different agents can take different pieces without pretending they share a mind. A builder can implement one change. A reviewer can challenge it against the same acceptance condition. A verifier can reproduce the claim somewhere the builder did not control. The handoff becomes an object the factory can inspect rather than a request to trust the last conversation.

Code tells you what changed. It rarely tells you whether the change solved the right problem, which alternatives failed, or what proof survived outside the author's setup. Treating the diff as the complete record forces every later agent to infer intent from implementation. That is how accidental choices harden into architecture.

The workflow needs a receipt beside the diff. What was requested? What did the agent change? Which checks ran? Which claims were reproduced independently? What remains uncertain? Keep those answers small and mechanical enough to generate during the work, not as a heroic write-up after it.

This record also makes failure useful. When a check sends the change back, the rejection should point to a specific condition and return with the work. The next attempt begins with a failed claim it can test, not a vague instruction to try again. Without that loop, an automated workflow can burn through retries while making the same mistake in different words.

A larger tool belt can make an agent more capable inside a session. It can search farther, edit faster, run more commands, and reach more systems. It does not make the work durable. In fact, more capability raises the cost of missing state because there are more actions to explain and more consequences to recover from.

Tools should enter through contracts. Define what each tool may read, what it may change, what evidence it must return, and what happens when it fails halfway through. Store the result where another stage can verify it. If the only proof is that the agent said the command succeeded, the tool call expanded authority without adding control.

The same rule applies to models and agent frameworks. They will change. Some will plan better, some will navigate code faster, and some will be cheaper enough to run everywhere. If replacing one of them means rebuilding the workflow, the framework owns the process. The factory should own the contract and make every agent compete inside it.

The first agent gets the clean brief and the fresh context. The second agent reveals whether the system is real. Can it see what is done, what is blocked, what evidence exists, and what decision comes next without replaying the first agent's entire history? Can it challenge the result without inheriting the author's assumptions? Can it recover a partially completed action without starting over or guessing?

Designing for that second agent changes the machinery. Plans become explicit. Checkpoints become resumable. Tool results become typed evidence. Failures return to a named step. Human judgment moves to the boundaries that matter: choosing the destination, setting the standards, and deciding which consequences require approval.

That shift eliminates coordination work people perform today. Status chasing, context retelling, manual routing, and repeated review exist because the state is trapped in people and sessions. Put that state into the factory and agents can carry the work forward without waiting for somebody to remember what happened. The winning agent is not the one that completes the best isolated demo. It is the one the workflow can replace tomorrow without losing the work today.