Tech • AI • Robotics • Game
Opus 5.5 Build an AI Agent from A to Z: Official Training!
7/10TL;DR
Anthropic outlined a managed-agent architecture that separates the agent loop, execution environments, and persistent session logs to improve reliability, security, and scalability for long-running AI tasks.
KEY POINTS
What an agent is
An agent was defined as a model in a loop with tools: the model decides the next step, calls tools, observes results, and repeats until the task is complete. A harness wraps that loop, manages tool calls and context, and compensates for model-specific weaknesses.
Why the harness matters
The harness is designed to encode assumptions about a model and adapt as those assumptions change. One example involved Sonnet 4.5, which was described as becoming eager to finish tasks near the end of its context window, prompting the use of a context reset in the harness. That mitigation was no longer needed with Opus 4.5, underscoring why the harness must evolve with each model generation.
Sandboxing as a safety requirement
Managed agents are expected to write and run code, edit files, and install dependencies, so execution must happen in a sandbox or container. Because model-written code can be buggy, each task should run in its own isolated environment to limit the blast radius and prevent one task from affecting another.
Problems with the first architecture
An early architecture placed the session log, harness, and sandbox execution all inside one container. That made local edits fast and eliminated service boundaries, but it created a fragile, stateful system likened to a pet rather than cattle. Debugging was difficult because network issues and dead containers looked similar, and investigations were constrained because customer data lived inside those containers.
Decoupling the brain from the hands
The revised design split the system into three interfaces: an append-only session log, the brain running the agent loop, and the hands, meaning sandboxes and external tool endpoints. These components became replaceable and recoverable. If a sandbox fails, a new one can be started; if the harness fails, it can replay the session log and resume from the last event.
Security through credential isolation
A key security change was to keep credentials out of the sandbox entirely. When a sandbox needs to access a protected service, requests are routed through a proxy that injects the token before contacting the external endpoint or MCP server. That design reduces exposure to prompt injection because the model never sees the underlying credentials.
Append-only logs and flexible context management
The session event log is kept append-only, with nothing removed from the underlying record. Instead of deleting history, the system uses different compaction strategies to decide what to place into model context, whether a summary of the full history or only recent events. This preserved auditability while allowing context handling to evolve independently.
Faster startup and more modular infrastructure
By delaying sandbox creation until it is actually needed, the system can begin inference immediately. That architectural change cut time to first token by about 90%, producing a faster interactive experience while also allowing one agent loop to work with multiple interchangeable execution targets, including customer environments and MCP servers.
How managed agents are configured
The workflow begins with creating Environment V1, which defines sandbox network policy, allowed domains or MCPs, and installed packages. Builders then create an agent with a name, model such as Opus 3.5, Haiku, or Sonnet, a system prompt, and a base toolset including commands like bash, read, write, and grep. A session binds the agent and environment into a unit of work that remains inactive until it receives an event.
Event streams, custom tools, and long-running work
Sessions communicate through an event stream carrying user messages, tool calls, tool results, errors, status changes, and interrupts. Custom tools allow developers to define external actions and return results back into the same stream. The platform is aimed not only at chat interfaces but also at asynchronous tasks that can run for hours, days, weeks, or months, with support for outcomes, multi-agent delegation, shared memory, and scheduled recurring jobs.
CONCLUSION
The architecture reflects a shift from tightly coupled containers to a more resilient service model built around interchangeable components and durable logs. The main technical stakes are reliable long-running execution, safer credential handling, and the ability to scale agent workflows without locking assumptions to any single model or runtime.
Ask a question