Scaling Managed Agents: Decoupling the brain from the hands

In the rapidly evolving field of artificial intelligence, the development of effective agents capable of long-horizon tasks is a critical area of research. One of the significant challenges in this domain is the design of harnesses that can adapt as models improve. This article explores the concept of Managed Agents, a hosted service designed to run long-horizon agents while ensuring that the underlying interfaces remain stable even as the models evolve.

The Problem with Traditional Harnesses

Traditional harnesses encode assumptions about the capabilities of AI models, which can become outdated as these models improve. For instance, in earlier versions, the AI model Claude Sonnet 4.5 exhibited a behavior known as “context anxiety,” where it would prematurely conclude tasks as it neared its context limit. This behavior was addressed by implementing context resets in the harness. However, when this same harness was applied to Claude Opus 4.5, the issue was resolved, rendering the resets unnecessary.

This scenario highlights the need for harnesses to evolve alongside AI models. To address this, we developed Managed Agents, a hosted service within the Claude Platform, which allows for the execution of long-horizon agents through a stable set of interfaces.

Learning from Computing History

The design of Managed Agents draws inspiration from historical advancements in computing, particularly the way operating systems have managed to create abstractions that outlast the hardware they run on. For example, the read() command remains agnostic to whether it is accessing a disk from the 1970s or a modern SSD. This stability in abstraction allows for flexibility and innovation in implementation.

Similarly, Managed Agents virtualize the components of an agent into distinct interfaces: the session, the harness, and the sandbox. This separation allows for changes in one component without disrupting the others, fostering a more resilient and adaptable system.

The Evolution of Agent Components

Initially, all components of the agent were housed within a single container, which presented several challenges. While this approach facilitated direct file edits and eliminated service boundaries, it also led to significant drawbacks. The container became a “pet” in the pets-vs-cattle analogy, meaning that it was a named, hand-tended entity that could not be easily replaced. If the container failed, the session data was lost, leading to inefficiencies in recovery and debugging.

Decoupling the Brain from the Hands

The solution to this problem was to decouple the “brain” (Claude and its harness) from the “hands” (sandboxes and tools that perform actions) and the “session” (the log of session events). This decoupling allows each component to fail or be replaced independently, enhancing the overall robustness of the system.

Redefining the Harness

In the new architecture, the harness operates outside of the container, calling it like any other tool through a simple command structure: execute(name, input) → string. This change means that if a container fails, the harness can handle the error gracefully, allowing for the reinitialization of a new container without the need to nurse the failed one back to health.

Session Management and Recovery

With the session log now external to the harness, it is possible to recover from harness failures more efficiently. If the harness crashes, a new instance can be rebooted using the session ID to retrieve the event log, enabling a seamless continuation of tasks. During the agent’s operation, the harness continually writes to the session log, ensuring a durable record of events.

Enhancing Security Boundaries

In the previous coupled design, any untrusted code generated by Claude was executed in the same container as sensitive credentials, posing significant security risks. If an attacker managed to exploit this, they could gain access to tokens and spawn unrestricted sessions. To mitigate this risk, we implemented a structural fix that ensures tokens are never accessible from the sandbox where Claude’s generated code runs.

We employed two primary patterns to enhance security:

• Token Bundling: Authentication tokens can be bundled with resources or stored in a secure vault outside the sandbox. For instance, when using Git, access tokens are utilized during repository cloning without the agent handling the token directly.
• Dedicated Proxy for Custom Tools: For custom tools, we use a dedicated proxy that manages session-specific tokens, fetching credentials from a secure vault without exposing them to the harness.

Addressing Long-Horizon Tasks

Long-horizon tasks often exceed the context window of Claude, leading to challenges in retaining essential information. Traditional methods for managing context often involve irreversible decisions about what to keep or discard, which can result in failures.

In Managed Agents, the session log serves as a context object that exists outside Claude’s context window. This design allows for the durable storage of context, enabling Claude to access critical information without the constraints of its limited context window. The interface getEvents() provides the brain with the ability to retrieve necessary events from the session log, ensuring continuity in task execution.

Conclusion

The development of Managed Agents represents a significant advancement in the design of AI systems capable of long-horizon tasks. By decoupling the brain from the hands and establishing stable interfaces, we can create a more resilient and adaptable architecture that evolves alongside AI models. This approach not only enhances performance but also addresses critical challenges in security and context management.

Note: The concepts discussed in this article reflect ongoing research and development in the field of AI and may evolve as new insights are gained.