Anthropic releases Managed Agents: Aiming to eliminate all self-built Harnesses

Anthropic doesn’t want you to build your own Agent infrastructure anymore.

Recently, Anthropic officially launched the public beta of Claude Managed Agents—a set of prebuilt, composable agent frameworks (officially called the Agent Harness) running on Anthropic-managed cloud infrastructure. Developers no longer need to wrestle with sandbox environments, session management, error recovery, and permission control. You just define via API what the agent should do, and Anthropic handles all the messy work.

Simply put, this marks a key step for Anthropic in shifting from selling models to selling Agent runtimes.

Why they’re doing this

Over the past year, nearly every team that has run AI agents in production has hit the same wall: the maintenance cost of the Agent Harness far exceeded expectations.

A “Harness” is the layer of scaffolding around a large model—it manages the conversation loop, tool invocation, exception handling, and context window maintenance. The problem is that this scaffolding compensates for the model’s current limitations—but models evolve quickly. The compensating logic you write today could become dead weight next month.

Anthropic’s announcement gave a concrete example: Claude Sonnet 4.5 had a habit of prematurely ending tasks when nearing the context window limit. The team added a context reset mechanism to the harness. But when they ran the same harness with Claude Opus 4.5, the issue was gone—and the reset logic had become an unnecessary performance burden.

That’s not an isolated case. Every model upgrade brings a round of harness debugging and adaptation. Anthropic, of all companies, knows best how their models will evolve—so it makes sense for them to maintain this layer themselves.

For developers, this presents a choice: keep maintaining control logic that will continuously age, or let the people who understand the model’s evolution best handle it.

Architecture: Decoupled like an operating system

Anthropic’s design analogy for Managed Agents is the operating system.

Operating systems abstract hardware into processes and files so applications don’t need to care about CPUs or disks. Managed Agents does something similar—it divides an agent system into three independent layers:

• Brain: Model reasoning and control loop. Responsible for thinking, decision-making, and planning.
• Hands: Sandbox containers and tool execution. Responsible for running code, calling APIs, and manipulating files.
• Memory: Independently stored session logs. Records what the agent has done and its current state.

The three communicate through standardized interfaces, so if one fails or needs replacement, the others keep working.

The most direct benefit of this decoupling is that containers become disposable, rebuildable execution units. Previously, the control program and runtime lived in the same container—if the container crashed, the whole agent crashed. Now, the control program interacts with the container via standard interfaces like a normal tool. If the container crashes, the control program reports the error back to Claude, which decides whether to retry and launches a new container to continue.

Because the session log is stored externally, the control program itself is stateless. Even if it crashes, it can resume exactly where it left off by replaying the event log.

For long-running tasks, this is a qualitative leap. Previously, a multi-hour agent task could be ruined by a single failure. Now every step is logged, and each component can recover independently.

Performance gains: more than just clean architecture

Decoupling isn’t for aesthetics—it brings tangible performance improvements.

The standout metric: p50 First Token Latency (TTFT) reduced by about 60%, and p95 by over 90%.

The reason is intuitive—previously, inference had to wait for the container to start. Now inference and container startup are decoupled. The model can start thinking while the container initializes in parallel. For users, the perceived “reaction speed” is much faster—no more awkward waits of tens of seconds after submitting a task.

The 90%+ drop in p95 (long-tail latency) is especially notable. The p95 metric reflects the slowest 5% of requests—the true bottleneck for production UX. Cutting it by 90% shows that the new architecture is highly stable even under worst-case conditions.

Security: finally getting credential isolation right

Security improvements may be the most underestimated aspect of this release.

Previously, all components lived in one container, meaning Claude-generated code and authentication credentials (OAuth tokens, API keys, etc.) shared the same environment. That means one successful prompt injection that convinces Claude to read environment variables could leak tokens.

This isn’t a theoretical risk. Agents process inputs from many sources—uploaded documents, web pages, third-party APIs—any could contain malicious instructions. Storing credentials alongside the execution environment is like locking the burglar in the same room as the safe.

Under the new architecture:

• OAuth tokens are stored in a separate vault outside the sandbox.
• Claude calls MCP (Model Context Protocol) tools through a dedicated proxy service.
• The control program and sandbox never touch any credentials directly.

This is the right design. Credential isolation should be a standard feature of agent infrastructure, but the previous “everything in one container” setup made it nearly impossible.

Developer experience: how it feels to use

Managed Agents is fully API-driven. You create an agent via API, define its behavior (system prompt, available tools, execution environment), then submit tasks and retrieve results asynchronously.

The core steps are simple:

1. Define the agent: specify model, system prompt, toolset
2. Submit a task: send user instructions, get a task ID
3. Poll or use callbacks: retrieve intermediate states and final results asynchronously

For developers already using the Claude API, migration is easy. It’s essentially the Messages API + orchestration & execution as a managed layer.

If you call Claude via an API aggregator like OpenAI Hub, you can check compatibility with the Managed Agents endpoints. Here’s a minimal example using the Anthropic API format to create and use a managed agent:

import requests
import time

# Call Anthropic API through OpenAI Hub
BASE_URL = "https://openai-hub.com/anthropic/v1"
API_KEY = "your-openai-hub-key"

headers = {
    "x-api-key": API_KEY,
    "content-type": "application/json",
    "anthropic-version": "2025-01-01"
}

# 1. Create a managed agent
create_resp = requests.post(
    f"{BASE_URL}/agents",
    headers=headers,
    json={
        "model": "claude-opus-4-5-20250630",
        "system": "You are a code review assistant skilled at spotting potential security and performance issues.",
        "tools": [
            {"type": "code_execution"},
            {"type": "file_access"}
        ],
        "max_turns": 20
    }
)
agent_id = create_resp.json()["id"]
print(f"Agent created: {agent_id}")

# 2. Submit a task
task_resp = requests.post(
    f"{BASE_URL}/agents/{agent_id}/tasks",
    headers=headers,
    json={
        "messages": [
            {
                "role": "user",
                "content": "Review the src/ directory of this repo, find unhandled exceptions and potential SQL injection risks, and generate a remediation report."
            }
        ]
    }
)
task_id = task_resp.json()["task_id"]

# 3. Poll for results
while True:
    status_resp = requests.get(
        f"{BASE_URL}/agents/{agent_id}/tasks/{task_id}",
        headers=headers
    )
    status = status_resp.json()
    
    if status["status"] == "completed":
        print("Agent completed:")
        print(status["result"])
        break
    elif status["status"] == "failed":
        print(f"Execution failed: {status['error']}")
        break
    
    print(f"Executing... current step: {status.get('current_step', 'N/A')}")
    time.sleep(5)

This code shows the basic flow. In real use, you can also configure MCP tool servers, mount file systems, and set up OAuth credentials.

Compared to competitors: Anthropic’s bet

Many players are already offering managed agent infrastructure. OpenAI has the Assistants API (though positioned slightly differently), Google has Vertex AI Agent Builder, Microsoft has the AutoGen + Azure combo, and numerous open-source frameworks—LangGraph, CrewAI, AutoGPT—are competing for developer mindshare.

But Anthropic’s angle this time is different.

Most frameworks help you orchestrate your own agents more easily. Managed Agents takes a bolder stance: “Don’t even bother orchestrating—I’ll handle that too.”

The underlying bet: as models improve, the harness layer will get thinner until most of the control logic is absorbed by the model itself. If that’s true, then instead of developers maintaining depreciating control code, it’s more logical for Anthropic—the ones who best understand model evolution—to do it.

In the short term, this makes sense. Claude is iterating rapidly, and each generation improves tool use, long-context handling, and error recovery. The workarounds you wrote for Sonnet 4.5 likely aren’t needed in Opus 4.5.

In the long term, however, this implies deeper platform lock-in. Your agent logic runs on Anthropic’s infrastructure, using Anthropic’s orchestration, depending on Anthropic’s understanding of model behavior. Moving elsewhere won’t be easy.

For Anthropic, that’s precisely the point. As model capabilities homogenize, it’s harder to build moats around the models themselves. But if your agent infrastructure, state, and tool integrations all run on my platform, migration costs become the moat.

What this means for indie developers

A developer on the Linux.do forum shared their experience building their own harness—after investing serious time, they finally got it working… just in time for Anthropic to release Managed Agents. Their honest reaction: “Can’t beat theirs—fine, I’ll just study Anthropic’s harness.”

This is a classic pattern in infrastructure. Once a platform provider steps in and offers the capability natively, independent efforts risk being subsumed.

But it’s not necessarily bad news. The experience of building your own harness isn’t wasted—understanding the low-level mechanics helps you make smarter architectural choices when using a managed service. And since Managed Agents is still in public beta, custom-built solutions still make sense for specific needs (e.g., private toolchains or strict compliance environments).

The key question: is your core competitive advantage in infrastructure, or in the business problem your agent solves? If it’s the latter, outsourcing the infrastructure and focusing on logic is probably wiser.

Key details worth noting

Deep integration with the MCP tool protocol. Managed Agents natively supports MCP (Model Context Protocol), meaning you can mount any MCP-compatible tool server. MCP is becoming the de facto standard for agent tool invocation, and Anthropic elevating it to a first-class citizen in their managed platform will accelerate its adoption.

Asynchronous-first design. Managed Agents is explicitly designed for “long-running tasks and async workflows.” It’s not a chatbot container—it’s for multi-minute or multi-hour tasks like code review, data analysis, document generation, or multi-step research. This clear positioning avoids overlap with the existing Messages API.

The significance of stateless control programs. Stateless control means true elastic scaling is possible in theory. Spin up more controllers when demand is high, scale down when low—no state-sync issues since everything’s logged externally. This is vital for enterprise environments handling many concurrent agent tasks.

In closing

Anthropic’s Managed Agents may appear to be just another new product, but it actually redefines the AI agent development paradigm: model providers now offer not only the model, but also the optimal way to run it.

This is a shift all agent developers should pay attention to. It doesn’t mean you should move everything to Managed Agents today—it’s still in beta, the API may change, pricing is unknown. But the direction is clear: agent infrastructure is moving from self-hosted to managed—just as compute moved from on-prem to the cloud a decade ago.

Whether to get on board depends on your tolerance for platform lock-in, and your honest assessment of self-managed maintenance costs.

---

References

• Anthropic launches managed agent service, using decoupled architecture to simplify long-running agent deployment – iThome: iThome’s detailed technical coverage on the architecture and performance improvements of Managed Agents
• Anthropic releases Harness product – Linux.do: community discussion and firsthand experiences from developers building their own harnesses