Your pilot didn't stall because of the model. It stalled because nothing was designed to be reused.

In 1975 Fred Brooks gave software teams a piece of advice that has outlived most of the book it came from. In The Mythical Man-Month he argued that the first system a team builds is rarely usable, that it will be thrown away whether anyone plans to or not, and so the team should plan to throw one away. Twenty years later, in the anniversary edition, he took it back. "This I now perceive to be wrong," he wrote, "not because it is too radical, but because it is too simplistic." The biggest mistake in the idea, he explained, was that it implicitly assumed the classical waterfall model of building software, and by then he favored building incrementally.

In my experience, most agentic pilots still follow the 1975 version. They are built quickly, usually to answer a single question, and everyone expects production to be a rebuild. I believe its is a sensible plan for the agent itself. But the trouble is that the pilot usually throws away everything else as well, and everything else turns out to be most of what production needs.

When such a pilot then fails to move forward, the post-mortem tends to blame the model. Sometimes that is right. More often, I think, the pilot answered the question it was built to answer, but then expectation spirals for different questions and expectation gap is too wide to bridge for what built as a throwaway pilot.

What a pilot measures

A pilot asks whether a model can do this task well enough to be worth pursuing. To answer that quickly, teams take shortcuts that are entirely reasonable. Model is treated as the only capability driver. Documents are exported to a folder. Model is called directly. Someone reads the outputs and judges them. The cases that work get demonstrated, and the ones that don't get noted for later.

What that produces is a measurement of a particular kind: on a good run, can it do the task? People who evaluate agents call this pass@1, the chance of success on a single attempt. Production runs on a different number.

Sierra's τ-bench, a benchmark in which agents handle simulated customer-service conversations, introduced a metric called pass^k: the probability that an agent succeeds on every one of k attempts at the same task, with the simulated customer phrasing things differently each time. In its original results, the best GPT-4o agent in the retail domain fell to about 25 percent at pass^8, roughly 60 percent below its single-attempt score. Put plainly, there was about a one-in-four chance that the agent would correctly handle eight customers with the same problem.

Newer models score considerably higher, so those particular numbers have aged. But the concept and arithmetic hasn't. Anthropic's guidance on agent evaluations describes a simpler version: an agent that succeeds 75 percent of the time on one trial succeeds on all 3/3 trials only about 42 percent of the time. A demo is a pass@1 measurement. A claims queue or a prior-authorization queue is pass^k, with k in the thousands. More so, what we have found out is, in regulated work the failures tend to gather in the unusual cases, which are exactly the cases a pilot sample is least likely to contain.

There is a second gap, which cases are being tested or not. A pilot sample is usually chosen by people who want the pilot to work, from documents that were easy to export. The cases that cost a claims or prior-authorization team the most time are the ones that come back: the reworked files, the appeals, the complaints, the submissions with a missing page. An evaluation set that will mean anything to a production reviewer should be weighted toward those cases.

So a pilot that "worked" has usually established something real and limited. It has not established what the production decision needs to know.

What the production estimate contains

Then comes the meeting where someone asks what's the estimate effort or time to production. The list will be familiar to anyone who has been in that meeting. The agent needs read and write access to systems of record, under permissions security will approve. It needs an evaluation set drawn from real cases, hard ones included, with written criteria for what counts as correct, run across repeats. It needs a decision trace a reviewer can follow. It needs a place for the cases it shouldn't decide, and someone to look at them. It needs a cost per case at real volume, which a pilot of a few dozen cases rarely predicts well. Describing how they took a multi-agent research system to production, Anthropic's engineers reported agents using about four times the tokens of a chat interaction, and multi-agent systems using about fifteen times. And it needs a team to run it after go-live, with a way to release prompt and model changes without breaking anything.

The same engineers summed up the experience by saying the gap between pilot and production is often wider than anticipated, because agents are stateful and their errors compound from one step to the next.

None of the items on that list concern whether the model can do the task. All of them have to be answered before a regulated enterprise lets an agent touch live work. The estimate usually amounts to a second, larger project, and hence a business case written to justify a pilot rarely stretches to cover the gap. The usual outcome is a request for more analysis, a smaller scope, or a pause. IDC, in a study with Lenovo, found that for every 33 AI proofs of concept a company launched, four reached production, and put the gap down mainly to low readiness in data, processes and infrastructure. LangChain's survey of 1,340 people building agents, run in late 2025, found quality to be the most cited barrier to production. It also found that only about half of them ran offline evaluations on test sets. A team can't defend quality it isn't measuring.

Now consider a second program with the same pilot results, built differently. Its pilot read from the claims system through a read-only connector with scoped permissions, where the first pilot used an export. Its evaluation was forty real cases taken from adjuster rework, with written grading criteria, rerun on every change. Every run wrote a trace in the format production reviewers would use, and the cases the agent couldn't decide went to a standard exception queue. Its production estimate covers the difference: write permissions, a larger eval set, load and cost testing, and review of whatever is new. That becomes a smaller decision, and an easier one to approve.

The model and the task are identical in the two programs. What differs is what each pilot left behind. When we built the claim system for a mid-size insurance provider, the provenance record and human review of exceptions were part of the first build for exactly this reason. A coverage decision without them can't be reviewed at all, so a pilot without them would have told us nothing about whether production was possible.

Across a portfolio, the mistakes compound in the wrong direction. Ten pilots built as standalone projects can leave ten evaluation spreadsheets, ten logging approaches and ten partial integrations, and none of them helps the eleventh. Each pilot arrives at its go/no-go meeting carrying the full cost of the production layer, and each is judged as though it were the first. Our companion piece on reuse economics follows what happens to that cost once agents are in production; the point here is that without shared components, many pilots never get that far.

Which half to throw away

This is where Brooks's revision helps. He wasn't arguing that prototypes should be kept. He was arguing that systems grow in increments, so the useful question is which parts of an early build the next increment stands on. We had learnt those lessons over last couple of decades - remember Agile, XP and similar methodologies? Keeping that in mind, for agents, I'd split the pilot in two.

The agent logic can be disposable. Prompts, orchestration and the choice of model will probably change with the next model release and with the scope, and there is little point polishing them during a pilot. The layer around the agent is a different matter. The connector, the evaluation cases, the trace format and the exception queue take somewhat longer to build properly than their pilot shortcuts. They are also exactly what the production review will ask for, and what the next use case can reuse. That layer is worth building to keep from the first day.

There are fair objections to this argument, and they tell us where the lessons stop applying.

Some pilots should stop. The IDC analysts pointed to proofs of concept started under board pressure, underfunded, or approved on loose ROI assumptions. Reusable components don't make a low-value use case worth running. A pilot that stops because it showed little value has done its job, and the right outcome is for it to stop cheaply.

Sometimes the model really can't do the task. For some work, particularly long multi-step tasks, current models don't reach the consistency a regulated process needs, however good the scaffolding. In those cases the title of this piece is simply wrong. The hard part is telling those cases apart from the others, and the only reliable way I know is an eval suite run on real cases, across repeats. Without one, a team can't say whether a failure came from the model, the prompt, the retrieval or the data. Anthropic's guidance describes what tends to follow: teams fix one failure, create another, and can't tell a regression from noise. With a suite in place, a team can also rerun it when a better model comes out and see whether the answer has changed.

Sometimes the data isn't ready. Gartner predicts that organizations will abandon 60 percent of AI projects that lack AI-ready data, and points out that AI-ready data is specific to each use case. A connector gets an agent into the claims system. It doesn't make the claims data representative of the cases the agent will meet.

And it is possible to overcorrect. A program that spends a year on a general-purpose agent platform before any agent handles live work usually ends up with a platform built for needs nobody had yet. Team Topologies' idea of a thinnest viable platform, aimed at one specific problem and extended as real use appears, is a better model. The reusable layer should come out of the first path to production, built to a standard the second use case can adopt, and generalized once it has actually been used twice.

Deciding at kickoff

Machine learning has been here before. In 2017, several of the Google engineers behind the technical-debt paper published the ML Test Score, a rubric of 28 tests and monitoring needs for judging whether a model was ready for production. Their premise was that production readiness is hard to pin down after the fact, because the behavior of a learned system is hard to specify in advance. Agents need the same kind of rubric, agreed before the pilot starts.

The practical change is small: agree what the production decision will need to see, and design the pilot to produce it. That means writing down several things up front. The pass rate the agent has to reach across repeated runs, and how many repeats. Where the evaluation cases come from, and who labels them. What share of cases the agent may route to people. Which fields the decision trace must hold, agreed with the people who will review it in production. Which systems the production agent will read and write, and under what permissions. Cost and latency per case at expected volume. How a prompt or model change will be tested and approved. And which team will run the agent after go-live.

A pilot that reports against those gives the people evidence to make the production decision. A pilot that reports a demo and some good examples gives them a reason to ask for more analysis. This is how we run the first two stages of our engagement loop, and why the trace and eval work starts in the pilot rather than after it; the piece on observability covers what that trace has to contain.

For a CoE running several pilots at once, we have a recommendation for this quarter: list the evaluation harnesses, trace formats, connectors and review queues across every current pilot. If each pilot has its own, consolidate them before starting the next one.

Brooks's advice was to plan to throw one away. For agents I would amend it slightly: plan which half you are throwing away.

If you have pilots that worked and didn't move forward, talk to us about what production would take on your stack.