Kill the Correction Queue: The Agent Lands When the Fix Stops Waiting for Its Builder

Marco Di Santo published a post this morning that most people who built the first agent in their company will recognize before the end of the second paragraph. He built one with the person who owned the process. They defined every step, down to the tone of voice. The first time the people who actually do the work used it, they followed a different process from the one he had been given. Nobody had hidden anything. He rebuilt it around what they did, and it started helping.

Then the part that is the post. Every correction after that came to him. One agent, one team, fine. More agents, more teams, and every correction from every one of them waited for the same head. His line: a company cannot have 200 copies of that person.

I have sat on the other side of that handoff, the vendor side, enough times to have written five posts about it. His post is the view from inside the customer. The two views agree on the problem and differ on one piece of the fix, and the piece is worth the argument.

The short version

Marco Di Santo, in "The Person Who Built Your AI Agent Is Now Its Bottleneck" (October 20, 2026), built an agent fast because one person held requirements, build, and release, and then became the place every correction waited. His split hands the team the instructions, the knowledge and examples, and the test cases, keeps the integrations and the runtime, and ends with a check: for the last five corrections, write who noticed, who made the change, and how many days passed. Kill the correction queue, the arrangement that puts the builder's name in that middle column. Replace it with three things from the FDE Transition: the keys line (a named person on the team with hours), a diff and an undo on the customer layer, and a go-live set the builder keeps frozen and reruns on every change the team ships. That last one is where I differ with his split. Then take his ledger weekly: time to landing is days to the first change the customer makes without you, and the ledger is that number every week.

What he found

Di Santo's agent went live fast for a reason he names honestly: one person covered the whole chain. Choosing the use case, writing the requirements, building, releasing, all in one head. He reaches for Fred Brooks for why, the communication paths that grow faster than the people, and the conceptual integrity that comes from one mind. He adds the agent-specific reason: the first version is a guess about how the work is done, and the sooner the guess reaches real users the sooner you learn where it is wrong.

Then the same person becomes the limit. The people using the agent see a problem the same day. They describe it to the builder, the builder understands it, and the fix waits for a free slot. He uses Eric von Hippel's sticky information for the shape of it: the knowledge needed for the fix stays with the team, and it moves to the builder more expensively than the fixing would move to the team.

He looked for research on central AI teams turning into a queue and says he found vendor blog posts and no study he would cite. He also says he found no public, verifiable case of a business team that owns and improves an agent after a central team built it. I am not going to supply one that I cannot verify either. What I can supply is the vendor-side instrument that measures whether it is happening, which his post stops just short of.

Kill the correction queue

The practice to retire is the arrangement itself, not the builder. Call it the correction queue: every change to a live agent routes through the person or team who built it, waits for their slot, and ships when they get to it. It survives because it feels responsible. The builder knows the agent best, so the builder should make the change. That reasoning is exactly backwards after go-live, because the person who knows what the change should be is the one who noticed it needed making, and in Di Santo's own account that person was never the builder.

Killing without replacing is removal, and removal gets reversed inside a quarter. So the replacement runs first. Three pieces, all of which already exist in The FDE Transition, because the vendor side of this handoff has had to solve it on a deadline.

The keys line. Month Two: The FDE Leaves, the Workflow Has to Stay is the handoff page I use when an FDE's attention drops from one of three customers to one of twelve accounts. One of its four lines is the keys: the named person at the customer who can change the customer layer without calling you. If the keys line is blank at day 60, the deployment has not landed. Di Santo got to the same place from inside the building: the handoff worked where one person took the agent as their own, and where nobody did, the agent stayed exactly as he left it. His phrasing is that "hand it to the team" means handing it to a person with a name, and his instruction is to give that person hours in their week. Both go on the line.

A diff and an undo. Under Same Model, Twice the Bill: The FDE Codebase Contract, the customer layer (prompts, rules, thresholds, connector settings, and the customer's eval rows) changes the same day with no review, on two conditions: it is versioned, and it diffs against the shipped default in one command. Di Santo lists the two things he would keep in place in any company however much freedom the team has: every change saved as a version, and a way back to the previous version in minutes. Same two conditions, written from the other side. He quotes the AWS guidance that the target state is one where every production prompt has a documented version history, an evaluation record, and a clear owner, and the mistake to avoid is instructions written into the code so that nobody can change behavior without a release. His advice from that: find where your agent's instructions live, and if changing a sentence needs a developer and a release, move that first.

A frozen go-live set. This is where I differ with his split.

Where I differ: the test cases do not move across whole

Di Santo's team took three things: the instructions, the knowledge and examples, and the test cases. They changed all three and released on their own. The test cases, in his design, are the safety net: the team reruns them after every change, and a case that used to pass and now fails tells them to go back.

That net has a hole, and one reader of his post put a finger on it in the comments within hours: the team now owns both the change and the check that catches a bad change. What is left as a backstop is the undo, and an undo is only useful once someone has noticed.

So the rows are the customer's, and the go-live set is the receipt. The team adds rows, edits rows, retires rows that no longer describe the work. The builder keeps a copy of the set the agent passed on the day it went live and reruns that set on every change the team ships. The FDE Scorecard already has the number this produces: reversal rate, the share of go-live workflows the customer switched off, overrode, or routed around by day 60. The frozen set is how you measure it without asking anyone. An edit that breaks month three should be caught by someone who did not make it.

Di Santo quotes AWS on exactly this risk, the warning against treating prompt changes as low-risk because they involve no code, and he quotes a 2024 MIS Quarterly Executive study on low-code tools finding that handing development to novices risks substandard quality, shadow IT, and technical debt. His reading is that the team and the builder need each other after the handoff. The frozen set is what needing each other looks like as a mechanism rather than a sentiment.

The ledger, weekly

His closing check is the one to steal, and I would run it on a schedule. Take the last five corrections. Three columns: who noticed, who made the change, how many days between. If the middle column is the builder's name five times, that is the bottleneck.

In the FDE Transition the same measurement has a name. Time to landing, from the scorecard, is days from signature to the first change the customer makes without you. It is taken once. Di Santo's ledger is that number taken every week, which is better, because landing is not a date, it is a column that changes names and stays changed.

Under AI Product Management the argument is that the build got cheap and the scarce work is knowing which part to build. Here the scarce work is knowing which part to hand over. Di Santo's answer and mine agree on the instructions and the examples, agree on the version and the undo, and differ on who holds the receipt. Hold it.

This week: pull the last five corrections to the agent your team depends on. Fill the three columns. If the middle one has one name, write the keys line today, with hours, and copy the go-live set somewhere the team cannot edit. Then start the ledger. The week the middle column changes is the week the agent landed.

Related answer: Who should fix a live AI agent after it is handed to the team?

Sources: Marco Di Santo, "The Person Who Built Your AI Agent Is Now Its Bottleneck," Operational AI, October 20, 2026, read in full. Fred Brooks (The Mythical Man-Month), Eric von Hippel ("Sticky Information" and the Locus of Problem Solving), Matthew Skelton and Manuel Pais (Team Topologies), Harrison Chase at LangChain ("Communication is all you need"), the AWS Well-Architected Agentic AI Lens, and the 2024 MIS Quarterly Executive study by Altus Viljoen and co-authors are cited only as Di Santo quotes them. Falk Gottlob, "Month Two: The FDE Leaves, the Workflow Has to Stay," "Same Model, Twice the Bill: The FDE Codebase Contract," and "The FDE Scorecard: Count What Stayed, Not Who Was Sent."