Building AI Agents That Survive Production

The default assumption in 2025 was that agents needed better models. Smarter, longer-context, more capable. That bet was half right. Models did get dramatically better; agents that used them still broke in production, just for different reasons. The failures clustered in four places that had nothing to do with model quality and everything to do with the plumbing around it.

That's a familiar pattern. Cloud computing went through it: the first generation of cloud apps used virtual machines as if they were physical servers and got eaten by reliability problems. The second generation accepted that cloud was a different substrate and built for it. AI agents are at the same crossover. Per Osmani's analysis, the teams shipping reliable agents in 2026 are the ones who've stopped treating the model as the product and started treating the surrounding stack as the product.

The third bet is the easiest to nod along to and the hardest to build yourself, because two separate problems hide inside it. The first is recovery. A long-running agent will be interrupted, whether by a crash, a timeout or simply you shipping a new version of the code it runs on. If the only option is to start the job again from zero, every deploy becomes a gamble on whatever was half-finished. The second is the pause. Some steps (sending money, emailing a customer, posting in public, deleting data) should not happen until a person says yes, and that yes can take minutes or days to arrive.

Cloudflare Computer (Cloudflare's toolkit that gives an agent a workspace to run code in, shipped as the @cloudflare/computer package) is a concrete example of both problems moving into the platform. According to Cloudflare's changelog of 26 October 2026, version 0.7.0 lets an agent's code resume after a deploy or a crash, and lets a function pause the run until your application supplies an approval decision. Recovery re-runs the code from the start but reuses the recorded results of calls that already finished, so completed steps are not redone. The same changelog states that time spent waiting for approval does not count toward the run's timeout, and that the wait survives a deploy. (More on it in our Cloudflare Agents Week 2026 round-up.)

The fine print is the most useful part. Cloudflare notes that a call whose result was not recorded before the interruption may run again, even if its action already succeeded. That is the general rule of replay-based recovery rather than a quirk of one product: anything with a side effect has to be safe to repeat, usually by passing an idempotency key so a second attempt is recognised as a duplicate. Durable execution removes the restart-from-zero problem. It does not remove the need to design each action so that doing it twice is harmless.

Why build the approval step in rather than bolt it on? A home-made approval usually means the agent stops, writes a note somewhere, and a separate process restarts it later with the answer pasted back in. Every one of those handovers is a place to lose state. When the pause is part of the runtime, the agent's position is saved with it, the human answer goes straight back to the waiting call, and a rejected action fails cleanly instead of leaving the job in limbo. Whichever platform you pick, the lesson for a small team is the same: put the riskiest actions behind an explicit approval gate, and check that the gate survives the agent being restarted.

An agent harness is the software wrapped around a language model that turns it into something that can finish a job. The model only ever does one thing: read some text and propose what comes next. The harness does the rest. It runs the loop, it carries out the model's tool calls, it decides what the model gets to see, and it keeps a long task alive. Strip the harness away and you have a chatbot. Add one and you have an agent.

In plain terms, a harness has four jobs:

• The loop. Send the model the task, read its reply, act on it, send back the result, and repeat until the model says it is done or a limit is hit. Our walk-through of Claude Code's while-loop design shows how little code the core of this needs.
• Tool calls. When the model asks to read a file, run a command or call an API, the harness checks that the request is allowed, runs it, usually inside a sandbox, and passes the output back.
• Context. A model's context window fills up. The harness chooses what goes in, what gets summarised and what gets dropped, which is where context rot on long-running agents is won or lost.
• Long-task management. Timeouts, retries, checkpoints, approval pauses and budgets. Everything in the crash-and-approval section above is harness work.

On 28 October 2026 Microsoft made its own harness available to outside developers. According to Microsoft's announcement, the Microsoft Copilot harness, built by GitHub's engineers, already runs Copilot Code, Copilot Studio, the GitHub Copilot app, the command-line tool, VS Code and more, and is now offered through Microsoft Foundry (Microsoft's cloud platform for building and running AI apps and agents). The announcement states that the harness works with more than 20 frontier models plus bring-your-own-key, supports MCP and agent skills, comes as a downloadable SDK or as a cloud service managed by Foundry, and that its runtime was recently rewritten in Rust. In the hosted version, Microsoft runs the agent loop and the sandbox; you supply the instructions, skills, tools and choice of model. The speed and quality claims in the announcement are Microsoft's own; it cites no independent benchmark.

The interesting part is not the product but the shape of it. Microsoft has put one harness behind every Copilot surface and lets the model underneath change. That is the fourth bet, platforms rather than custom stacks, playing out at the largest scale available: the model has become the swappable part, and the harness is the thing the company standardises on, tunes and sells. It matches a pattern visible in desktop coding tools such as Claude Code and Cursor, where much of what separates two tools running the same model is the loop, the tools and the context handling.

Should you build your own loop or use a managed harness? A basic loop is a weekend's work, and writing one is still the best way to understand agents. The cost arrives later, in the four jobs above: context handling that holds up over hours, tool sandboxing, recovery after a crash, and re-testing everything each time a new model lands. A managed harness hands that maintenance to the vendor. The trade is control and portability. Model choice stays open, but your agent's behaviour now depends on a loop you cannot read or pin, and an improvement the vendor ships can change it overnight, which is exactly the silent-change risk covered in the next section. Two habits limit that lock-in whichever way you go: keep your tools behind open standards such as MCP servers and your instructions in portable agent skills, and keep your own eval set so you can tell when the harness, not just the model, has changed under you.

The four bets deal with failures you can see: a session dies, a credential leaks, a job restarts. The harder class is the failure nothing reports. An agent can keep answering on time, return well-formed output and log zero errors while the answers themselves are quietly wrong. Latency, error rates and uptime describe the machinery. They say nothing about whether the output still means what the business thinks it means.

The first way this happens is meaning drift. An agent that turns questions into database queries has to map everyday words onto your data, and the same word rarely means one thing across a company. A "customer" in sales might be anyone with a signed contract, while support counts anyone who has opened a ticket. If the agent flattens those into one definition, every report it produces runs cleanly and every trace looks fine, but the numbers are subtly off, and nobody notices until a decision rests on them.

The second is a component changing underneath the agent. Many guardrails rely on embeddings (numerical fingerprints of text that let software measure how similar two pieces of writing are) and a fixed similarity threshold. Swap or update the embedding model and the distances shift, so a threshold tuned last quarter now lets through what it used to block and blocks what it used to allow. An InfoQ report of October 2026 on a panel about AI in production describes exactly this: a financial compliance agent whose embedding model was updated in the background, after which false positives and false negatives both spiked while the infrastructure health checks stayed green.

Neither failure is a bug in the usual sense. The code did what it was written to do. What changed was the meaning around it, and conventional monitoring is not built to watch meaning.

Three controls do most of the work, and none of them is a cleverer prompt.

Continuous evals, fed by real traffic. An eval is a set of test questions with known good answers that you run against the agent to score its behaviour. A one-off eval at launch tells you the agent worked on launch day. The version that catches drift runs all the time: sample live conversations, flag the odd or contested ones, and add each real edge case to the test set so the next model or embedding update is checked against it before it ships. Pin the versions of models and embedding services where the provider allows it, so an update arrives as a change you test rather than a surprise.

Separate identities with tiered permissions. This extends the first bet. Each agent gets its own identity, and that identity gets only the access its job needs, in tiers: read-only by default, writes that can be undone at the next level, and irreversible actions (payments, deletions, outbound messages) behind the approval gate described above. Keep API secrets outside the agent's own runtime, so a manipulated agent cannot read them. A prompt that tells the agent not to do something is a request, not a control; a permission it does not hold is.

A named person signs off on business risk. Engineering can prove the guardrails work. Whether an agent that is right most of the time is good enough to approve refunds or answer compliance questions is a business judgement, and someone with authority over that outcome should make it explicitly, in writing, before launch and again after a significant change.

The common thread is that an agent is not ordinary application code. Ordinary tests check that code does what it was written to do; an agent also needs checks that its answers still mean the right thing as the world and its components shift around it.

If you're a solo builder or a small team, the four bets read like enterprise problems. Mostly they are. But two of them matter even at the smallest scale, and the other two are worth understanding before you commit to architecture decisions that will hurt later.

Identity matters from day one. If your agent calls an API on a user's behalf, the credentials need to look like that user's, not a generic service account. Get this wrong on a hobby project and the cost is a leaked key. Get it wrong on a paid product and the cost is a compliance event. Either way the fix is much cheaper at the start than at scale.

Session survival becomes urgent the moment your agent does anything that takes more than a few minutes. If your agent's longest task is one prompt-and-reply, the surrounding session story doesn't matter. The moment you ask it to process a queue, fill a form across multiple steps, or run an overnight job, you need state checkpointing or you'll be hand-restarting it daily.

The other two (universal context, platform stack) you can defer. Most hobbyists don't have an enterprise data fabric to integrate with, and the cost of using a custom stack is rounding-error at small scale. Revisit when the scale forces you to.

Three categories where the four-bet architecture is overkill.

Throwaway scripts. An agent that runs for ten minutes once a week to do a thing you'd otherwise do by hand doesn't need an identity layer or durable execution. A shell script with a one-line LLM call is the right answer. Don't over-engineer. It is a pocket version of YAGNI, one of the principles collected in Laws of Software Engineering.

Interactive editor agents. Claude Code, Cursor, and similar in-editor agents already live inside your editor's session. They borrow your identity (your git config, your shell credentials) and lose state when you close the window, and that's correct for the interactive use case. The four bets matter for agents acting autonomously; interactive ones have a human in the loop already.

Prototypes you intend to throw away. If you're learning the space, building a quick demo, or testing whether an agent can do X at all, custom plumbing is fine. The four bets matter when you're committing to running the thing for years; before that point the architectural discipline is friction without payoff.