What Breaks When You Put AI Agents in Production

The agent conversation has moved on. In 2026 the question is no longer whether a model can plan a multi-step task — it obviously can — but what happens when you leave one running against real systems, unattended, for ten hours.

The adoption figures show the split clearly. Around 86% of organisations report using AI coding agents against production code, with enterprises ahead of smaller firms. But only about 8.6% have non-coding AI agents genuinely deployed in production. Coding agents got there first for a reason that has nothing to do with model capability: software engineering already had the safety rails. Version control, pull requests, code review, CI, staging environments. An agent that writes code lands inside a system built over thirty years to catch humans doing the wrong thing.

Point an agent at anything else and you discover how much of that infrastructure you have been taking for granted. We wrote up what happened when we handed a product team's entire bug lifecycle to a fleet of agents — 150 issues in, 50 fixed and PR-ready ten hours later. This is the other half of that story: what we had to build around the agents to make it survivable.

Four problems, none of them about the model

Teams running agents in production converge on the same four gaps: verification, permissions, memory and observability. They are distributed-systems problems wearing an AI costume.

1. Verification: who checks the work?

An agent that produces output nobody validates is a random number generator with good manners. The single highest-leverage design decision in an agentic system is where the checks go and who owns them.

The pattern that works is separation of concerns: the agent that produces the work is never the agent that approves it. In our own line, the fix agent writes the change and the test — and then a distinct review agent critiques it for correctness, scope creep and test quality, with the explicit mandate to reject. A security and standards gate runs after that. Several fixes bounced at review more than once, which is the gate working rather than failing.

This matters because self-assessment is where agents are weakest. A model asked "is this good?" about its own output is being asked to contradict the reasoning that produced it. Give the critique to a different context with a different job and it finds things.

Design the rejection path first. A pipeline where nothing can be sent back is not a pipeline, it is a conveyor belt.

Verification also needs an artefact. Every gate in a working line should hand forward something concrete — a reproduction, a diff, a test result — not a status change. Artefacts are what let the next gate do real work and what let a human audit the chain afterwards.

2. Permissions: blast radius is a design parameter

Most production incidents involving agents are not the model being wrong. They are the model being wrong while holding credentials that let it act on being wrong.

Treat every agent as a service principal with the narrowest scope that lets it do its job:

• Separate identities per agent. The triage agent needs read access to the backlog. It does not need to push branches. Shared credentials collapse your entire permission model to the union of everything any agent might need.
• Irreversible actions require a human. Merging to main, sending external email, moving money, deleting anything. Our line deliberately keeps two of its eight gates human — filing the bug and merging the fix — and merging stays human precisely because an agent that can write a change and merge it has no gate above it.
• Prefer proposals to actions. An agent that opens a pull request is safe in a way that an agent which commits to main is not. Look for the equivalent shape in every domain: a draft, a staged change, a queued transaction.
• Budget as a permission. Token spend, API call counts and wall-clock runtime are resources an agent can exhaust. Cap them per run and alarm on the cap.

The rule of thumb: if you would not give a competent contractor on their first day unsupervised access to it, do not give it to an agent.

3. Memory: the context window is not a database

Long-running agents accumulate state, and the naive approach — keep appending to the conversation — degrades in a specific, expensive way. Cost grows with every step. Latency follows. And past a certain length, relevant instructions get crowded out by transcript noise, so quality falls at exactly the point the run has cost the most.

The working discipline is to treat memory as an engineered subsystem with four distinct operations: write state out to durable storage rather than holding it in context; select only what the current step needs; compress completed work into summaries; and isolate separate concerns into separate contexts.

That last one is why specialist agents outperform one general agent with a large prompt. An agent that only reproduces bugs gets very good at reproducing bugs — partly through focused instruction, but mostly because its context contains nothing else competing for attention. Splitting a task across specialists is a memory-management strategy before it is an org chart.

4. Observability: you cannot debug what you did not record

When a conventional service misbehaves you read the logs. When an agent misbehaves, the equivalent question is what did it actually see, and what did it decide? — and if you did not capture that at the time, it is unrecoverable. Agent runs are not deterministic; you do not get to reproduce it later.

The minimum viable trace for each step:

• The full context that went in — instructions, retrieved documents, prior state.
• Every tool call, with arguments and results.
• The output, and which gate accepted or rejected it.
• Tokens, latency and cost, attributed to the step.

Two things follow from having this. First, debugging becomes ordinary — most agent failures turn out to be a retrieval step that returned the wrong document or a tool that errored quietly, both obvious in a trace and invisible without one. Second, you get an evaluation set for free: real runs with known outcomes are the data you need to tell whether next month's change is an improvement.

Add cost attribution from day one. Agentic workloads spend non-linearly — a retry loop that triggers on 2% of inputs can quietly dominate the bill, and you will only find it if spend is broken down per step rather than per month.

What this actually buys

None of this is glamorous, and all of it is the reason a fleet can run unattended for ten hours without anyone chasing it. The published results from teams who have done the work are substantial — Spotify's internal coding agent has produced over 1,500 merged pull requests at a claimed 60–90% time saving against writing the code by hand. Our own line converted an estimated 500 hours of engineering into ten hours on the clock, on day one.

Those numbers come from the scaffolding, not the model. Everyone has access to the same models.

Start with the pipeline, not the prompt

If you are putting agents into production, the useful first question is not which model to use. It is: what are the steps, what artefact does each hand forward, who checks it, what can each one touch, and how would I know afterwards what happened?

Answer those and the model choice becomes an implementation detail you can revisit any time. Answer none of them and no model is good enough.

We build and run agent pipelines against real codebases and real backlogs — with the gates, permissions and traces that make them safe to leave running. Talk to us about your workflow.