Anthropic Turns the Agent Runtime Into the Product

The hardest part of deploying an AI agent is rarely getting it to produce a clever answer. It is keeping the work alive when a process crashes, understanding what it did when something goes wrong, and ensuring that a model given access to a business does not accidentally gain the keys to all of it. Anthropic’s Managed Agents architecture treats those anxieties not as implementation details, but as the central product problem. Its answer is deceptively simple: separate the brain that reasons, the hands that act, and the durable record that remembers.

An agent begins with an ordinary human hope. Someone wants a system to investigate an incident overnight, update a codebase, reconcile a set of contracts, or assemble the evidence needed for a decision. They do not want a chatbot that offers a few plausible next steps. They want work to continue after they close the laptop.

That wish changes the engineering problem.

A language model can reason through a task one turn at a time. But work that lasts hours, touches production systems, calls external services and survives changing requirements is no longer merely a conversation. It starts to resemble a distributed application, with all the uncomfortable properties that phrase implies: partial failures, repeated messages, credentials, queues, timing problems, audit requirements and state that must outlive any one machine.

For a while, many agent systems treated this complexity as something a single container could absorb. Put the model loop, its working files, its tools and its memory in one isolated environment. Let the agent operate there until it finishes. This is a reasonable way to make a prototype feel tangible. File edits are simple. Commands run locally. The whole system appears to have one home.

It is also a fragile bargain.

Anthropic’s engineering post, published on April 8, 2026, describes Managed Agents as a hosted service for long-horizon work built around interfaces intended to survive changes in harnesses, sandboxes and other surrounding components. The central architectural decision is to decouple the “brain,” meaning Claude plus its harness, from the “hands,” meaning sandboxes and external tools, and from the session, an append-only log of what occurred.

This is not just a cleaner diagram. It is a claim about what an agent is.

The agent is not a model trapped in a machine. It is a recoverable process whose reasoning, actions and durable history can be managed separately. That distinction matters because the industry is moving from agents as impressive demonstrations to agents as staff-like infrastructure. The latter must be restartable, observable and bounded by policy, even when the model behaves unexpectedly.

The familiar trap: one clever machine that cannot be allowed to fail

Imagine an internal agent assigned to repair a broken software deployment. It receives an alert, reads logs, checks a repository, runs tests, proposes a patch, opens a pull request and leaves a record for the on-call engineer.

In the simplest architecture, all of that happens inside a single container. The agent harness calls the model. The model writes files and executes commands. A WebSocket emits progress. Credentials may be mounted in the environment so that the agent can clone a repository or reach a ticketing system.

From the outside, it seems coherent. From an operations perspective, it is an awkwardly precious server.

If the container stalls, the system cannot easily distinguish among several very different situations. Did the model finish but the progress stream fail? Did a shell command hang? Did the network break? Did the harness crash? Has the container disappeared entirely? The answer often requires a human operator to look inside the same environment that holds customer work and possibly sensitive tokens.

That is not simply inconvenient. It defeats a basic purpose of managed infrastructure. A production system should fail in ways that can be diagnosed without turning every incident into a privileged forensic expedition.

Anthropic describes this condition using the old computing distinction between pets and cattle. A pet is a named, individually tended machine that cannot be casually lost. Cattle are interchangeable instances that can be replaced when one fails. In the initial coupled design, a lost container could mean a lost session, while an unresponsive one required nursing back to health.

The metaphor is slightly crude, but the lesson is durable. A long-running agent becomes dangerous when its identity is inseparable from one runtime. The runtime accumulates working context, partial state and authority. Soon, the organization is protecting the machine because it is the only thing that knows what has happened.

This is the opposite of resilient design. It turns an agent into a pet server with unusually persuasive prose.

The key insight behind Managed Agents is that the container was doing too many jobs. It was a place to think, a place to remember, a place to execute and a place to store authority. Those are not the same responsibility, and they do not need the same reliability or security properties.

Three separations that make an agent operational

Anthropic’s replacement architecture divides the system into three independent elements.

First is the harness, the control loop around the model. It decides what context to present, calls Claude, interprets tool-use requests, emits events and determines when the work has reached a terminal state. This is the brain’s operating environment, not the place where generated code runs.

Second is the session, a durable append-only event stream. It records inputs, outputs, tool calls, tool results, checkpoints and other material facts about the work. It is the historical record from which a new harness can reconstruct its position.

Third are the hands, which include sandboxes, remote tools and customer-controlled systems. These are the places where an agent actually changes files, queries services or performs an action in the world.

Each element can fail, be moved or be replaced without making the other two disappear.

Anthropic frames the session as a durable log of events, the harness as the loop that calls Claude and routes its requested actions, and the sandbox as an execution environment for code and file edits. The company’s point is that the interfaces between these parts should remain stable even as the implementations behind them change.

That is a familiar move in the history of computing. Operating systems did not survive because every underlying disk, processor or network card stayed the same. They survived because the interfaces above the hardware were durable enough to accommodate systems that had not yet been invented.

The analogy should not be overstated. An agent runtime is not an operating system. It has softer boundaries, probabilistic decisions and a model that may reinterpret instructions in surprising ways. But the architectural ambition is similar. Preserve a few durable primitives, then let the machinery behind them evolve.

For an agent runtime, those primitives are likely to include:

The table is intentionally more abstract than a product API. That is the point. The lasting value is not a particular tool name or container image. It is a contract that makes replacement possible.

This separation changes the failure model in a useful way.

If the sandbox dies, the harness receives a tool failure. It can record the failure, ask the model to choose a recovery path, provision a new sandbox and retry only if the operation is safe to retry. The death of an execution environment does not automatically erase the narrative of the work.

If the harness dies, a new stateless harness can wake the session, fetch the event history, restore the relevant context and continue. Anthropic says its design allows a replacement harness to resume from the last recorded event, rather than requiring the original process to remain alive.

And if the tool endpoint is temporarily unavailable, the session can preserve that fact rather than converting it into a vague absence of progress. That makes a difference to both automation and people. A human reviewer can see whether the agent chose to stop, whether an approval gate intervened, or whether a dependency failed.

In other words, the log becomes the agent’s continuity of identity.

A session is not a context window

This distinction may be the most consequential part of the design.

Language models have bounded context windows. Even as those windows grow, long-running work eventually confronts a difficult choice: what should the model retain, summarize, discard or retrieve later?

Most current answers involve compaction. A system condenses past work into a smaller summary, stores notes in files or trims old tool results before sending the remaining material back to the model. This is practical. It is also irreversible in a way that many agent builders underestimate.

A summary is an interpretation of the past. It may capture the plan while dropping the edge case that will matter six hours later. It may preserve the conclusion while losing the failed test that explained why the conclusion was uncertain. It may remove a tool result because it looks old, only for the agent to need the exact value when deciding whether to retry an action.

Anthropic explicitly distinguishes the durable session from Claude’s active context window. Its session log can be interrogated in slices, allowing a harness to revisit the events around a particular decision or action rather than treating compaction as destruction. The harness may still summarize, trim or organize material before presenting it to the model, but the underlying record remains available.

That looks like a technical refinement. It is actually a change in institutional memory.

Consider the difference between a meeting and its minutes. Minutes are invaluable, but they are not the meeting. They omit interruptions, uncertainty, competing proposals and the exact phrasing that later explains a decision. An organization that keeps only summaries eventually discovers that its past has become too neat to audit.

Long-running agents have the same problem. The model needs a compact working memory to reason efficiently. The organization needs a fuller record from which to reconstruct why a consequential action occurred. Those needs should not be forced into the same object.

A well-designed runtime therefore distinguishes at least three layers:

1. The canonical event record, which is durable and append-only.

2. The working context, which is a deliberately selected and possibly transformed view sent to the model.

3. Derived memory, including summaries, plans, task lists and semantic indexes that improve speed but are never mistaken for the original record.

The harness is responsible for selecting the view. That means context engineering becomes replaceable policy rather than permanent data loss.

A later generation of models may need less aggressive compaction. A domain-specific harness may retrieve evidence by task phase rather than by time. A compliance-heavy workflow may demand that certain actions always bring supporting records back into context. If the log endures, these strategies can change without rewriting history.

This does not mean replay is easy. Nor should it be confused with rerunning everything.

A durable log gives the system evidence of what happened. It does not guarantee that every event can safely be repeated. The difference becomes crucial when tools produce side effects.

The moment an agent touches the world

Suppose an agent sends a payment, creates a user account, merges a code change or pages an on-call engineer. Then the network drops before the tool result returns.

What happened?

The agent cannot safely infer that the action failed. It also cannot safely assume that it succeeded. This is one of the oldest problems in distributed systems, and an AI model does not make it go away merely by being good at explaining it.

The dangerous response is an unstructured retry: “The request timed out, so try again.” For a search query, that may be harmless. For a payment or an email to thousands of customers, it may be costly.

The proper response is an idempotent tool contract.

Each externally visible action should carry an operation identifier generated before execution. The target system should record that identifier with the result. A retry using the same identifier should return the first completed outcome, not create a second action. If a tool cannot offer that guarantee, the runtime should expose its uncertainty and require a verification step before trying again.

This is where agent design meets ordinary operational discipline. The model can propose what it believes is the best next move. The runtime must constrain how that move reaches the world.

A mature tool result should include more than a string that says “done.” It should ideally return a structured record:

• an operation ID
• the requested effect
• whether the effect is pending, completed, rejected or unknown
• a reference to the external audit record
• whether retrying with the same key is safe
• the scope of the authority used
• any approval that authorized the action

The model does not need to see every field in every turn. The session should preserve them, and the harness should surface the fields that matter to the decision at hand.

This makes failures legible. A tool timeout becomes an explicit unresolved operation. A harness restart becomes a new worker examining a known operation ID. A human escalation becomes a conscious choice, not the accidental consequence of lost context.

The same principle applies to reads. A search result, a database query or a ticket snapshot can become stale. The event log should capture when the observation occurred and, when it matters, the version or revision it observed. Otherwise, a restarted agent may reason from yesterday’s reality while believing it is acting in the present.

The design target is not omniscience. It is honest uncertainty.

Security improves when the model cannot reach the secret

The strongest part of Anthropic’s architecture may be its simplest security rule: generated code should not be able to read the credentials that authorize external actions.

In a coupled container, the temptation is obvious. Mount a token as an environment variable. Let the agent-generated script use it. The system works until a malicious instruction, a compromised dependency or a careless piece of generated code reads the environment and exfiltrates the token.

At that point, the problem is no longer limited to one mistaken action. The credential may permit an attacker to create new sessions, access more data or act outside the intended workflow. Narrower permissions help, but permission scope alone is not a sufficient answer. If the sandbox can read the secret, the sandbox is part of the secret’s attack surface.

Anthropic says it keeps tokens out of the sandbox through two patterns. Repository access can be bound to a resource during initialization, allowing Git operations without handing the token to the agent. For custom tools, an MCP tool proxy receives a session-associated token, retrieves the relevant OAuth credentials from a secure vault and makes the external call without exposing credentials to the harness or generated code.

This is the difference between handing someone a master key and asking a guarded clerk to unlock one specified door after checking their authorization.

The latter is not infallible. An agent can still request a harmful action if the proxy permits it. But the security boundary is stronger because the agent does not receive portable authority that it can copy, inspect or reuse elsewhere.

A secure delegated-credential design should answer several questions before an agent is allowed near production systems:

Who is acting? The system should distinguish the human principal, the organization, the session, the harness version and the tool identity.

What exactly is authorized? Authority should be scoped to an action, a resource and ideally a time limit. “Can access GitHub” is too broad. “Can open a pull request in this repository from this branch during this approved session” is closer to a useful policy.

Can the action be escalated? High-impact actions should be marked as requiring approval, dual control or a policy evaluation external to the model.

Can authority be revoked? A session that becomes suspicious should lose future access promptly, without relying on code inside a sandbox to cooperate.

Can the organization reconstruct use? The session and tool logs should connect the request, policy decision, credential delegation and external result.

This is not merely about defending against prompt injection. It is about recognizing that a model should be treated as an intelligent but untrusted planner. It is allowed to suggest and invoke narrowly defined capabilities. It should not be treated as a safe place to store a company’s raw secrets.

Many brains, many hands

The decoupled architecture also creates an economic advantage.

If every session begins by provisioning a sandbox, cloning a repository and preparing a complete execution environment, the user waits even when the first meaningful step is simply to think, inspect a session history or ask a clarifying question. Anthropic reports that by provisioning containers only when a tool call requires them, its p50 time-to-first-token fell by roughly 60 percent and p95 fell by more than 90 percent.

The important number is less the exact percentage than the design logic behind it. Compute should appear when it is needed, not because an old architecture assumed that reasoning and execution must always inhabit the same machine.

This also changes how agent work can be distributed. A single session may need to examine a repository in one environment, query a customer-controlled service in another and retrieve material through a SaaS connector elsewhere. Treating every hand as a tool makes location a routing decision rather than an architectural trap.

That introduces a new challenge: the model must reason about multiple environments. Which system is authoritative? Where can a command safely run? Which tool has access to the required data? What is the cost of moving information between environments?

Earlier systems often simplified these questions by giving the agent one shell and pretending that was the world. More capable models make the limitation harder to justify. The better answer is not to erase boundaries, but to make boundaries explicit enough that the harness can guide decisions and policy can enforce them.

The practical result is a new operating model for agent teams. Instead of managing fleets of persistent agent machines, operators manage sessions, workers, tools, policies and recovery guarantees. The individual harness becomes disposable. The session becomes durable. The tools become governed service endpoints. The agent is the coordinated whole.

What a serious runtime specification should contain

Anthropic’s announcement should be read less as a final blueprint than as a sharp statement of design priorities. A company building its own agent runtime does not need to duplicate every Managed Agents interface. But it should be able to state its answers to the same questions.

Start with recovery objectives.

A conventional service might define a recovery time objective and a recovery point objective. Agent systems need similar measures, but they should be expressed in the language of work:

• Session recovery time: How long after a harness failure until a replacement can continue?
• Recovery point: What is the maximum number of events that could be absent after a failure?
• Tool reconciliation time: How quickly can the system determine whether an uncertain external action happened?
• Human takeover time: How quickly can a reviewer receive a coherent account of the state, evidence and pending decisions?
• Credential revocation time: How quickly can future delegated tool access be halted?

Then define the event model. An event should be immutable, ordered and attributable. It needs a schema version, timestamp, actor identity and correlation IDs. It should distinguish an intention to act from an attempted action, a confirmed result and an inferred interpretation. These distinctions can feel bureaucratic during a demo. They become essential during an incident.

Next, specify replay semantics. Some events are safe to replay into a model’s context. Some are safe to reissue to a read-only tool. Some are unsafe to execute twice. The runtime must know the difference. “Replay” should mean re-reading history by default, not blindly redoing work.

Finally, define the boundary between model discretion and organizational authority. The model may decide which evidence to seek, which low-risk query to run or which draft to prepare. Policies and approval systems should decide whether it may delete data, change access controls, deploy code, notify customers or move money.

That division will shape how people trust these systems. Workers do not need agents to be flawless. They need them to be understandable when they fail, interruptible when stakes rise and recoverable when infrastructure behaves badly.

The larger shift

The most interesting thing about Managed Agents is not that it promises longer-running work. Many systems can keep a process alive for a long time. The question is what survives when the process does not.

Anthropic is arguing that durable state, secure action boundaries and replaceable orchestration are not secondary operational features to be added after the agent becomes capable. They are the conditions that allow capability to enter serious organizations in the first place.

That will likely become a dividing line in the agent market.

The companies that build agents as impressive model loops may deliver quick demonstrations. The companies that treat sessions as durable records, tool calls as contracts and credentials as delegated authority will be better positioned to operate where failures carry real costs.

There is a cultural implication too. The popular image of an agent is an autonomous worker, a digital employee left alone with a browser and a task list. The more useful image may be less romantic: an apprentice working inside a carefully designed institution. It can investigate, draft, execute bounded tasks and recover from interruption. But its authority is explicit, its work is recorded and its mistakes do not vanish with the machine that made them.

That is not a retreat from autonomy. It is what makes autonomy survivable.