Anthropic's Applied AI team on the Evolution of Agentic Surfaces

What must change in the software around a model when the request grows from answering a question to completing a task—or owning an entire outcome? Gagan Bhat and Isabella Kai He approach that question from Anthropic’s Applied AI team, which sits between product, research, and go-to-market. Their work combines building internal agents, evaluating Claude, and helping enterprise customers turn model capabilities into working products.

The progression begins with model capability. Gagan traces it through the transformer architecture, scaling-law research associated with Anthropic’s founders, and successive model releases. As capabilities expand, developers delegate more complex work: first questions, then tasks, then outcomes. The interface for building agents has to absorb the operational demands that come with that progression. A request-and-response API is only the beginning.

The first surface in this progression is the Messages API: information and tokens go in; generated text comes out. Gagan introduces it through the Claude 3 era, although the Messages API beta announcement preceded that generation and included Claude 2.1 examples. As tasks became longer, applications needed the model to fetch information, use tools, and manage its accumulating context.

Developers supplied those capabilities by building an agentic loop beneath their product. The loop called Claude, executed requested tools, returned their results, and managed context before calling the model again. Maintaining that loop was substantial work, but it was only one layer: a production application also needed session management, observability, credentials, hosting, and sandboxing.

The Claude Agent SDK packaged the Claude Code harness into an embeddable component. It supplied the loop, filesystem access, tools, a sandboxing system, and primitives for sessions and observability. The product could embed that harness instead of rebuilding it. Developers still had to decide how to host it, supply credentials, and scale it for customers.

That remaining work becomes clearer as a set of concrete design questions:

• Hosting and scaling: Where does the process run, how long does it live, and what happens under load?
• Session management: Where do history and progress persist, and how do concurrent agents operate?
• Filesystem and isolation: Where can Claude create or edit files, and where does generated code execute securely?
• Credentials: How does the agent reach sensitive systems without seeing their security tokens?
• Observability: How can a developer reconstruct what happened across the orchestration?

These concerns consume time that could otherwise go into the application’s task and context.

Claude Managed Agents moves that infrastructure boundary. The developer owns the product, task, context, and domain knowledge. Anthropic operates the machinery beneath it: a brain containing Claude, the agentic loop, and evolving harness components; and hands, a sandbox created when needed for filesystem access and code execution. Credentials, sessions, observability, and hosting are also managed services.

Each surface absorbs another layer of work between the application and the model. The architectural challenge is to keep that absorbed layer adaptable as the model changes.

Harnesses encode assumptions about what the model cannot do on its own. Context resets and compaction policies are examples: they compensate for limitations in the model’s ability to sustain useful work. Isabella’s design principle is to revisit those assumptions frequently, because a new model can make a previously necessary intervention obsolete.

With Sonnet 4.5, the team observed what it called context anxiety. As the agent approached its context-window limit, it sometimes wrapped up or terminated work early, despite still having space available. Context resets in the harness helped it continue. When the team tested Opus 4.5, Isabella reports that this behavior disappeared. The resets remained, however, adding latency and sometimes incorrectly discarding cached context. The same intervention had changed from a remedy into overhead.

This is a maintenance problem as much as a model-selection problem. A rigid harness built around an older model can take weeks or months to migrate while model release cycles keep shortening. Managed Agents therefore uses a small set of independent, replaceable components: the architecture can remain stable while individual mechanisms change to capture new capabilities.

Products such as Claude Code and Claude Tag, alongside enterprise agents, point toward increasingly asynchronous work. These agents accumulate context, take actions in secure environments, run for hours or days, and divide complex problems into parallel workflows. Supporting that work requires more than a loop that succeeds while its original process stays alive.

The initial Managed Agents design put the agent loop and tool execution in the same container. This made tool calls and result access straightforward, but it also coupled their lifecycles. Model reasoning could not begin until the container finished setting up. A failure in one part could bring down the whole agent. Separating the brain from the hands removed that shared dependency and allowed the brain to request a sandbox only when needed.

The separation creates two recovery paths:

• Sandbox failure: The surviving brain can create a replacement sandbox, retry, and continue.
• Brain failure: A replacement brain can read the durable session log, reconstruct its context, and resume the work.

The session log matters because neither the reasoning process nor the execution container has to be the sole owner of the agent’s history.

The public resource model follows that architecture:

Multiple sessions can use the same environment definition while receiving isolated container instances. Combining an agent and environment creates a session whose persisted interactions support observability, long-running work, and recovery.

The production requirement is different from serving one person on a laptop. At large user counts, long-running work must survive tool failures without losing its identity or progress. Managed Agents exposes four session states:

Recoverable failures can lead back into execution through the existing session; an unrecoverable session terminates.

Context engineering becomes difficult when a harness treats the session and the model’s current context window as the same thing. Discarding material to make room can then mean losing the ability to recover it during that run. A durable session log changes the relationship: the harness can load selected slices into the current window, edit or discard them, and later reread the original material from persisted history. Reducing the active context need not erase the session’s memory of what happened.

Managing the loop, memory, and observability does not eliminate application-specific design. Developers still choose how to manage context and express domain expertise. Claude Code uses tools such as Bash and Grep much as a developer uses a terminal. A legal or go-to-market agent needs different tools and instructions. System prompts, skills, and tool design remain the means of turning a general harness into an agent suited to particular users.

The semi-interactive demonstration turns these primitives into an SRE investigation. An engineer owns Atlas, a dashboard of service metrics. In the Atlas demonstration, checkout P99 latency spikes to 10× its baseline. Logs provide plenty of text but no immediate explanation. The proposed agent should inspect the evidence and return a root cause, potentially before the engineer opens the dashboard.

Gagan assembles the investigator in four steps:

1. Define the agent. Name it the SRE investigator, select its model, and provide a system prompt describing its behavior. Standard tools include Bash, Grep, and Glob; an MCP toolset connects it to Atlas metrics and deployment data.
2. Define the environment. Create the SRE sandbox in Anthropic’s cloud. Restrict network access to the intended MCP server so the execution environment has an explicit communication boundary.
3. Supply evidence. Upload application logs and any needed skills so the agent can read them during the investigation.
4. Create the session. Reference the agent, environment, and uploaded log-file resource together to establish the durable run.

The resources separate what the investigator does, where it can act, and which evidence it receives.

Once the resources live in the cloud, the application sends an incident request about checkout latency. The brain begins work and uses the sandbox to search the application logs. A shell search can narrow a large log to relevant lines while retaining nearby context; for an uploaded file named application.log, that operation could look like this:

grep -n -C 3 -i -- 'checkout' application.log

The line numbers and surrounding records make it easier to inspect the evidence around each match. This is the filesystem side of the investigation; service telemetry comes through a different tool boundary.

The investigator retrieves metrics and recent deployments through MCP, locates the incident’s onset, and then inspects a code diff. It combines those sources into a root-cause response. The demonstrated sequence matters: logs narrow the symptoms, telemetry and deployments establish timing, and the diff supplies a possible explanation for the change in behavior.

This demonstration follows one session. An application can create sessions dynamically for different users, while the Claude console provides a place to inspect them. Opening a session exposes the event trace: tool calls, their results, and agent messages. The same durable record that supports recovery also lets a developer examine how the investigator reached its answer.

The first deployment lesson begins with a common customer concern: an agent that can inspect files might read an environment file containing security tokens. Separating the loop from execution provides part of the boundary. Managed Agents adds vaults that store credentials and decrypt them only when needed at tool-execution runtime. In the design Gagan describes, the model can use an authenticated tool without seeing its security token.

The second lesson concerns latency. With the coupled design, container provisioning sat directly on the path to model reasoning and the first response token. With the decoupled design, reasoning can start immediately while container setup runs in parallel. If a task never needs sandbox execution, setup can be skipped entirely.

Isabella reports roughly 60% lower P50 time to first token and over 90% lower P95 time to first token after decoupling container startup from reasoning. Anthropic’s engineering account identifies this as latency from session acceptance to the first response token, rather than total task duration. The workload, absolute timings, sample size, and model configuration are not specified. The mechanism is clear even without those details: container provisioning no longer has to finish before inference begins.

The third field lesson joins two questions: how can developers see what an agent is doing, and how can they improve its future behavior? The session log records user messages, model responses, tool executions, and results in order. Displaying it in a UI provides observability. Retaining it also gives the agent a history of past executions that can complement user-specific memory. Gagan introduces dreaming as a way to use that history to update memory between runs.

The fourth lesson is control over tool execution. Security-conscious teams wanted execution inside their own virtual private cloud. Because the hands are independent of the brain, self-hosted sandboxes can place tool execution in customer-controlled infrastructure while the agent loop remains on Anthropic infrastructure. Customers control the sandbox control plane and the policies under which tools run.

MCP tunnels address the related problem of reaching private MCP servers without publishing them on the internet. A gateway inside the private network establishes an outbound connection, allowing the managed agent to use those servers without requiring a public MCP endpoint or inbound firewall access. Execution placement and private tool connectivity become separate choices from where orchestration runs.

These foundations also support capabilities beyond the basic agent loop. Gagan names scheduled deployments, self-hosted sandboxes, multi-agent orchestration, dreaming, outcomes, and memory as areas of ongoing development and experimentation. Dreaming and outcomes receive the detailed treatment: one changes what future sessions remember; the other changes how a current task is judged complete. Dreaming was introduced as a research preview, while outcomes, multi-agent orchestration, and memory were described as public beta.

Dreaming takes two inputs: transcripts from the agent’s sessions and its current memory state. A periodic batch process reviews them, extracts insights, organizes information, and edits memory for subsequent sessions. The feedback loop operates through remembered information; it does not describe retraining model weights. Gagan frames this as a path toward agents that improve through repeated work, with the next day’s sessions benefiting from what earlier sessions revealed.

The direction extends beyond remembering details about one user. Organizational memory could hold a team’s runbooks and shared operational knowledge, with dreaming maintaining and enriching those structures over time. The unified-memory diagram connects ongoing sessions, shared team files, and periodic review. This is an emerging architecture for accumulated organizational knowledge, rather than a fully specified memory system.

Outcomes starts with a developer-defined rubric: what counts as successful completion, and which failure cases should prevent acceptance? A separate grader agent evaluates the working agent against that rubric. After the agent attempts the task, the grader checks the result. If it falls short, the agent receives another opportunity to work toward the criteria.

Isabella describes this as continuing until the success criteria are reached. The current Outcomes documentation makes the stopping condition more precise: success or exhaustion of the iteration budget. That distinction matters when designing a workflow around grading. A rubric provides a mechanism for evaluating and revising work; it does not guarantee that every task can be completed. The intended benefit is more reliable completion of increasingly complex tasks as model capabilities improve.

The closing architectural concern is the gap between what a model can do and what a product allows it to do. A static harness can preserve old limitations long after the model has moved past them. Managed Agents addresses that gap with independent execution and reasoning, durable sessions, and replaceable harness mechanisms, then builds memory refinement and explicit outcome evaluation on that foundation. The goal is a production system whose surrounding software can advance alongside the intelligence it exposes.