Surgical fixes in agentic pipelines
An agentic pipeline generates large objects. A page is one. It is structured, many blocks deep, each block a piece of data with a shape. And it is not built by one call. An agent builds the object by calling sub-agents. Those sub-agents call sub-agents of their own. A finished page is the output of a tree of agentic work, agents nested inside agents.
When the tree finishes, an auditor reads the object and looks for what is wrong. The auditor is another agent. Most of the time the object is fine. Sometimes one part is not. A property is malformed, or a value has drifted out of range, or a block came back in a shape the rest of the object cannot use. The question is what you do about that one bad part.
The expensive answer
The obvious answer is to generate the object again. You run the step that made it once more and hope the second draft is clean. It usually is. But it is the most expensive fix there is. A large object costs a lot of tokens and a lot of seconds to produce. You are paying all of that to correct a single property a much smaller effort could have repaired. And a regenerated object is a new draft with its own risks. The property that was wrong might come back right. Three that were right might come back wrong. You spent tokens to throw away work that was already correct.
And cost is not the worst of it. Sub-agents are how this pipeline does almost everything. A step that matters has children, and often children of their own, making the tree wide and deep. Every sub-agent earns its place. But each one is also a call that can fail. The odds that an entire tree comes back clean are the odds of every call in it succeeding at once. Those odds fall off fast as the tree grows. You can hold each call to a declared shape. Shape is rarely the trouble. A call can still die on a transient error, or simply not return. A full regeneration re-rolls every one of those calls. It is a fresh chance for any of them to fail. On a deep tree it can fail, and fail again on the retry, because every retry starts the entire tree over. The bigger the tree, the less likely a clean rebuild. Each failed attempt has cost you a full one anyway.
The surgical answer
The better answer is to fix only what is broken. The auditor did not just say the object is bad. It said which part is bad and how. That is a location and a defect. With both, you do not have to touch the rest of the object. You regenerate the one property, aim the fix at exactly where the defect is, and insert it in place. Everything that was already correct is left alone. A surgical fix, not a rebuild.
A block comes back with one field out of range, a list that should hold four items holding six, or a required value left empty. The auditor names that block and that field. The fix regenerates that block alone, against the same inputs, checks it, and drops it back into the slot the broken one held. The page around it never moves.
It works the same when the failure was not a bad value but a dead call. One node of the tree failed on a transient error. You re-run that node, not the tree. The children that came back fine are never re-rolled. They never get the chance to fail the way the first one did.
Why it takes the whole stack
You cannot do this on a blob of text. A surgical fix is only possible because of everything the pipeline already is. The object is structured, blocks and typed data rather than prose. A single property is something you can name and reach. The audit is specific. It hands you a location, not just a verdict. The contract holds the object's shape while you edit it. Replacing one part in place cannot put the object out of shape. And because the job is durable, the fix is one more step in a run that survives, not a fragile retry. Each of those was built for its own reason. Together they are what make a fix surgical.
Small fixes win at scale
A surgical fix is always cheaper to run. It spends a fraction of the tokens and a fraction of the time, because it touches a fraction of the object. And it spends that little every time, on every draft, for as long as the system runs. The platform drafts and audits constantly. A fix that fires on even a small share of that work still fires a great many times. A saving that is small once becomes large across all of them.
It is also more expensive to build. Regenerating the whole object is easy to write. The location does not matter. You just run the step again. Targeting one property and inserting a repair in the right place is harder. You pay that build cost once, in engineering. After that you pay a smaller run cost, for the life of the system.
At the scale an agentic pipeline runs, that trade is not close. The smallest fix that works is the cheapest one to run. The ability to make it is the return on all the structure underneath. When a surgical fix cannot be made cleanly, the pipeline still falls back to regenerating the section. Nothing is lost by trying the small fix first. Smaller fixes cost more to build and less to run. In a system that runs this much, that is the trade you want every time.
The smallest fix that works is the cheapest one to run.
Have questions?
If you're interested in my work or Giant Context, contact me!