The Harness Is the Product: What Three Vendors Just Admitted About Agents

The Harness Is the Product: What Three Vendors Just Admitted About Agents

The demo was never the hard part

Every team that has shipped an agent past a prototype has hit the same wall, and it is not the model. A demo agent completes one task, in one session, with a developer watching the terminal and ready to stop it if something goes sideways. A production agent has to survive a container restart mid-task, ask a human before doing something expensive or irreversible, remember what it was doing three days ago when the customer finally replies, log enough detail that someone can debug it at 2am, and not burn an unbounded token budget doing any of it.

None of that is a prompting problem. It is a systems problem. The industry has started calling the software layer that solves it the harness: the code that sits between the model and the outside world, controlling what the agent can see, what it can touch, and what happens when something breaks.

What makes this worth writing about now is that three vendors with no obvious reason to coordinate shipped production-grade harness infrastructure within about ten weeks of each other this spring:

• April 8, 2026: Anthropic published Scaling Managed Agents: Decoupling the Brain from the Hands, describing a rebuilt agent architecture where the model, the sandbox, and the session state are three separately recoverable systems instead of one.
• May 12, 2026: Google published a guide to building long-running ADK agents that pause, resume, and never lose context, built around durable session storage and webhook-triggered resumption.
• June 17, 2026: Cloudflare opened its Agents SDK as a runtime platform for any agent framework, with durable execution, a durable filesystem, and checkpointed workflows as the first primitives any framework gets for free.

Three companies, three different product motions: a foundation model vendor, a cloud/mobile platform, and an edge infrastructure company. All three landed on overlapping architecture almost simultaneously. That is not a coincidence worth ignoring. It is a signal that the how-do-we-get-an-agent-past-the-demo problem has a converging, nameable answer, and that answer is the harness, not the model.

What a harness actually has to do

Strip the marketing off all three announcements and the same five responsibilities show up every time.

The five jobs of a production harness

• Permissions and approvals: What is the agent allowed to do without asking, and what requires a human? Without this layer, agents either cannot do anything useful or can do something expensive or irreversible unsupervised.
• Memory and state: What does the agent remember across a restart, a pause, or a new session? Without durable state, every interruption becomes amnesia and multi-day workflows are impossible.
• Resumability: Can a task survive a crash, a scale-to-zero event, or a three-day wait for a human? Without resumability, long-running work silently dies and nobody notices until the customer complains.
• Observability: Can someone reconstruct what the agent did and why after the fact? Without this layer, debugging becomes archaeology and nobody trusts the agent enough to expand its scope.
• Cost control: What is the ceiling on tokens, tool calls, and compute per task? Without a hard ceiling, a stuck agent can loop silently until someone notices the bill.

None of these are new engineering problems in the abstract. Distributed systems people have solved versions of state recovery and idempotency for twenty years. What is new is that they are now showing up as first-class, named primitives in agent SDKs because agent workloads hit all five at once and hit them harder: an agent's crash can happen mid-reasoning, its restart has to reconstruct intent, not just resume a stack frame, and its cost is denominated in an LLM API bill that can run away in a way a stuck cron job never could.

Three vendors, three different cuts at the same problem

Anthropic: decoupling the brain from the hands. The older architecture for Claude-based agents put everything, the model's reasoning loop, the sandbox where its code ran, and the record of what happened, inside one container. If that container died, the whole session died with it: what Anthropic's own writeup calls a pet system, where every instance is unique and irreplaceable.

Managed Agents splits this into three independently recoverable pieces: the brain (Claude plus the harness logic), the hands (sandboxes where tools and code execute), and the session (a durable log that lives outside Claude's context window). A failed sandbox becomes a tool-call error Claude can see and react to; a failed harness process recovers against the session log and picks up where it left off. Containers and harnesses become replaceable. Credentials do not enter the sandbox either: tool auth lives outside the code execution environment, and Claude calls through controlled interfaces rather than holding the keys itself.

That is the permissions and recovery layer, solved as one architectural decision.

Google: resumability as the headline feature. ADK's long-running-agent guide starts from a blunt admission: a stateless chatbot cannot survive workflows that span days with real-world pauses in the middle, such as waiting on a signed document, a hardware delivery, or a customer reply.

The fix is a persistent session service that writes every tool-state change durably instead of holding it in memory, plus a webhook pattern: an external event calls an endpoint, updates the agent's state machine, and wakes it without replaying the entire conversation history to rebuild context. The container running the agent can scale to zero while it waits, and come back only when the webhook fires.

That is resumability and cost control solved together. The agent is not idling on a meter while it waits three days for a signature.

Cloudflare: making the primitives available to everyone else's framework. Cloudflare's move is structurally different from the other two. It is not shipping only its own opinionated agent product; it is opening the Agents SDK as infrastructure that other frameworks build on top of, starting with Flue.

The SDK's core primitives are a checklist of the same five layers in different packaging: durable execution through checkpointing, sandboxed code execution, a durable filesystem backed by SQLite, and workflows that persist and retry on failure. This is the piece worth reading alongside Agent9's coverage of Cloudflare OS's Gadgets and Blueprints model: the same Durable Objects-based runtime is now the shared foundation for both a user-facing agent workspace and the raw infrastructure layer for anyone building a harness.

What this means if you are building, not buying

If your team is deciding how to take an agent from prototype to something that runs unattended, the practical question is not which model. It is which of the five layers you build yourself and which you adopt from a platform.

Build the layer that touches your proprietary process or data. Your approval rules, what counts as expensive, who the escalation path is, and what irreversible means in your domain are specific to how your organization actually operates. No vendor's default policy will get this right for you, and it is the layer where being wrong is most expensive.

Adopt the layer that is pure infrastructure. Durable state storage, checkpointing, sandbox lifecycle management, and cost metering are solved problems now, shipped by vendors with more engineering hours behind them than most internal platform teams will spend. Building your own durable session layer from scratch in 2026 is the same mistake as building your own message queue in 2015.

Instrument for observability regardless of which way you go. Every vendor's approach above assumes you can reconstruct what the agent did. If you cannot answer why it did that after the fact, you cannot expand its scope later, no matter how solid the resumability story is. The organizational trust problem is as real as the technical one.

The teams that get stuck are not the ones with weaker models. They are the ones that treated the harness as an afterthought, glue code bolted on after the demo worked, instead of as the actual infrastructure decision. Three vendors just told you, independently and within ten weeks of each other, that they think this layer is the product. That is worth taking at face value.

The practical checklist

Before you ship an agent past prototype, you should be able to answer all five of these in one sentence each:

1. Permissions: What can this agent do without asking, and what is the exact trigger for asking a human first?
2. Memory: If this process restarts mid-task, what does it remember, and what does it have to reconstruct or re-ask for?
3. Resumability: If a task pauses for three days waiting on something external, does it wake up cleanly, or does someone have to notice it is stuck?
4. Observability: Can someone who was not watching in real time reconstruct exactly what the agent did and why, six weeks from now?
5. Cost: What is the hard ceiling on tokens, tool calls, and compute for one task, and what happens when it is hit?

If any of those does not have a crisp answer, that is the next thing to build, not a bigger model, not a better prompt.