Deploying AI Agents in Production: The Four Properties a Pilot Never Tests

Deploying AI agents in production is not a harder version of building a pilot. It is a different examination, and almost nobody studies for it, because a pilot grades exactly one property and production grades four.

A pilot asks whether the agent can do the task. That question is close to solved. The four questions production asks are whether the agent can live inside your controls, whether you can tell which layer failed when it does, whether the number you were sold survives contact with your own scaffolding, and whether any of it still holds on turn forty. Those four properties break independently. Fixing one does not improve the others, and the entire vendor category is optimizing the one your pilot already passed.

This page is the working version of that argument: the four properties, what actually breaks at each, the research that puts numbers on them, and the small test I use to find which one is the real blocker.

Why do AI agent pilots succeed and production deployments stall?

Because a pilot is a short, observed, cooperative run and production is a long, unobserved, adversarial one.

Every difference that matters is a difference in duration or in trust boundary. A pilot runs for a handful of turns while a human watches. It runs against data someone curated, through a harness someone tuned for the demo, with the person who built it available to interpret the output. None of those conditions survive a deployment, and none of the failure modes that emerge when they lapse are visible in the pilot at all.

The field finally has evidence on the time axis rather than anecdote. In September 2026 a group ran Emergence World, eight parallel worlds of ten agents each, continuously for sixteen days, generating more than 850,000 model calls and close to fifty billion tokens while the agents pursued goals, built their own tools, kept persistent memory, and governed shared institutions. Three controlled stress events were injected. No world was fully resilient, and the finding the authors put hardest is that detection did not ensure containment: agents wrote adversarial content into persistent memory and were still acting on it up to 46 hours later.

That is the shape of the production problem in one sentence. The system noticed and kept going anyway.

Two more results from the same window point the same direction. The BLINDSPOT benchmark evaluated thirteen models across 2,500-plus trajectories averaging 14.7 turns and found that safety failures routinely emerge only after several initially safe turns, which means single-turn refusal testing certifies a property the deployed agent does not have. And VentureBeat's reporting on long-running agents describes the mechanism underneath: compliance directives placed in a system prompt get progressively diluted as context accumulates, the agent keeps producing plausible output while quietly ignoring constraints, and larger context windows do not fix it.

A pilot cannot surface any of this. It ends before the decay starts.

What are the four properties production tests?

Containment: can it live inside your controls?

The unit is the agent's relationship to your perimeter. The questions are identity, secrets, runtime isolation, and revocation, and they are decided before anyone evaluates output quality.

This is the property teams most often discover last and should assess first, because it is the one that can kill a deployment outright regardless of how good the agent is. An agent operating on a borrowed human credential is not governable no matter how well it behaves. An agent whose privileges cannot be withdrawn at the speed of an incident is an outage waiting for a trigger. The useful move is to stop asking what the agent does and start asking what it inherited: which identity, which secrets, which isolation boundary, and who can revoke each one.

Depth on this property: enterprise AI agent infrastructure, where I lay out the Inherited-Controls Scorecard.

Attribution: when it fails, do you know which layer failed?

The unit is the failure itself. The question is whether your telemetry can assign a failure to a cause you can act on.

Most agent evaluation reports a pass rate, and a pass rate is not actionable, because an agent is a stack and the rate is an average over all of it. When a run fails, the cause sits at one of four levels: the context it was given, the tools it could reach, the orchestration that sequenced it, or the model underneath. Teams reliably guess the fourth. Foundra's production telemetry across 6,259 agents and 4.5 million runs put 56.6% of failures at the seams, in handoffs, inputs, and monitoring, rather than inside any single reasoning step.

This matters commercially as well as technically, because without attribution every improvement gets credited to whatever changed most recently, which is usually the model, which is usually the most expensive and least effective lever available.

Depth on this property: evaluating AI agents in production, where I lay out the Attribution Ladder.

Transfer: does the number survive your harness?

The unit is the benchmark score you were shown. The question is whether it is a property of the model or a property of the scaffolding around it, and the answer is very often the second.

Harbor Adapters ran eight models across fifty-four benchmarks under both a common harness and each model's native one. On the hard set, no model-harness pair clears 30%. The tau-tau-Bench work, which grades an agent on building an agent, puts a best configuration at 23.9% against an expert ceiling of 82.2%. Numbers published under a vendor's own scaffolding are measurements of a system you cannot buy.

There is a subtler version worth naming, because it is the one that gets past careful people. Benchmarks leak the structure of a solution even when they do not leak the answer, so an agent can be tuned against the shape of a task set and look general. I call that structural contamination, and it is invisible until the task shape changes, which in production it does on day one.

Depth on this property: agent benchmark contamination and scaffolding sensitivity, where I lay out the Four Discounts.

Endurance: does the behavior hold at turn forty?

The unit is the session. The question is whether the properties you verified at turn one are still true deep into a long run, and the honest answer is that almost nobody measures.

Endurance has a cost face and a correctness face. On cost, the agent's wall clock and its bill are dominated by things that are not the model: turns taken, context re-sent, tools waited on. Teams budget for inference and get surprised by everything else. On correctness, the Emergence World and BLINDSPOT results above say plainly that refusal, constraint adherence, and containment all degrade with session length, and that the degradation is silent.

The good news is that the fix is cheaper than the field assumed. The LAST-CQ analysis instrumented a five-agent self-refinement loop across 2,471 live-database queries and six model backbones and isolated which part of the loop actually produces the gains. It is not richer feedback and it is not more sampling. It is detecting failure and routing it to a retry, which recovered 91.7% of queries that failed on a single pass. Swapping sophisticated model-generated feedback for raw database error strings cost almost nothing; spending the same call budget on parallel sampling made quality 10 to 11% worse.

Depth on this property: agent latency budget in production, where I lay out the Trace Split.

Which property is actually your blocker?

They fail in a rough order, and it is not the order teams work in.

Containment is binary and comes first: if it is unresolved, nothing downstream matters, because the deployment will be blocked by someone who is right to block it. Transfer comes next, because it determines whether your plan is built on a real number. Attribution comes third, because without it you cannot improve anything deliberately. Endurance comes last in sequence and first in surprise, because it is the only one that cannot be assessed before you run long.

Most teams work the reverse order. They tune prompts and swap models, which touches none of the four.

What I would actually do

Pick one agent you already run and try to produce four artifacts. Not a plan for them. The artifacts.

One, the containment sheet: its identity, its secrets, its isolation boundary, and the name of the person who can revoke each within an hour. Two, the attribution map: for the last five failures, which of context, tools, orchestration, or model was responsible, and what evidence decided it. Three, the transfer note: every performance number you are relying on, and whether it was produced under your harness or someone else's. Four, the endurance trace: one complete long session, split into model time and everything else, with a marked point where you verified that a constraint stated at turn one still applied.

Then apply what I have started calling the Turn-40 Test. Take any control you believe you have and ask what would prove it still holds on turn forty of a live session rather than turn one. If the honest answer is that the instruction is in the system prompt, you do not have a control. You have a preference that the model is free to dilute, and the research above says it will.

Most teams cannot produce all four artifacts. That is the finding, and it is a better diagnostic than any benchmark, because the artifact you cannot produce names the property you have not tested.

---

Related pillars: multi-agent orchestration architecture covers how these systems are built, and enterprise AI agent governance covers the four scales at which controlling them breaks.

I write one of these every week on Build: NextGen AI, on the architecture, decisioning, and governance that make agentic systems safe to ship. Subscribe and the next one comes to you.