Note: This article was translated for me by AI. I wrote the original in Chinese. I never use AI to write my articles, because that would cost me my own expression; my freedom to express myself is always the most valuable part of my work. So if you can read Chinese, I recommend reading the Chinese version, where you will get the most original and unfiltered version. That said, technological progress exists to give us more convenience, so I will continue using AI to translate my writing into multiple languages, allowing valuable content to reach more people.

Anthropic’s Managed Agents have been out for a few months now, so this is a good time to analyze them. Starting from the technology, I want to look at Anthropic’s future positioning. Personally, I think this is a direction every AI-related company should watch closely—and think deeply about.

Just try it yourself!

The best way to learn something is always to taste it yourself: use it, try it, and dig into it. That gives you far more depth than asking AI to do deep research for you!

(As an aside, I have to say that many people who could not write documents before have become even worse at it after using AI. But seeing AI turn a few sentences into a full article in a few—or a dozen—minutes must give them quite a rush of self-importance, right? Then they gather everyone else and read through the AI-written document line by line. The irony is hilarious. Maybe it would be better to hand an AI-generated document to someone else’s AI to summarize and extract. Or, put another way, everyone else has AI too, and nobody wants to read Document Slop. I happened to see something Wang Junyu wrote in a magazine today. Screenshot below:

）

That was a tangent. Back to the point: for something like this, once you have read the official docs, you can usually just go and try it yourself.

These are basically the core concepts:

Agents

Here is a standard definition for creating an Agent. Both YAML and JSON are supported.

You can also create one through chat in Quickstart—a very AI-native approach.

Here is the result:

You can edit it or start a Session from this Agent.

There are three kinds of uploads: GitHub Repo, File, and Memory Store.

Sessions

Starting a session opens a chat interface. At this point, the Session is Idle and not being billed.

Here is one after an actual run:

You can see that it is split into Transcript and Debug. The former can be understood as Events, although Anthropic now calls them Transcripts throughout Claude Code. Debug contains more detail and feels closer to a Trace. The interface does not do much beyond showing events and letting you continue the chat.

Environments

You can create two kinds of environments, or sandboxes: Cloud is the default, and the other is Self-hosted.

For the cloud environment, you can preconfigure egress policies, preinstalled software, third-party libraries, and so on.

Self-hosted lets you run a worker on your own machine.

ant beta:worker poll \
  --environment-id "env_01AzQWp3SXQEATgdCFUNwteR" \
  --workdir "/path/to/workspace"

This is how it runs. The code for ant is here; it is Anthropic’s official CLI. In practice, it is merely a tool executor. You can basically think of it as receiving events from above, executing them locally—running a command, for example—and reporting the result. It is still relatively rudimentary, and custom tools are difficult as well: essentially Skill + Shell. This is not Anthropic’s real enterprise play, though; I will get to the key part later.

The software and dependencies preinstalled in a Cloud sandbox vary by template. The environment used for direct chat on claude.ai differs from the Managed Agents environment, for example. I am recording the differences between them here.

Chat

Anthropic’s sandbox comes with these runtimes preinstalled:

Additional packages can be installed through apt, cargo, gem, go, npm, and pip.

Build tools:

Preinstalled Python packages:

Global Node.js packages

System tools

Managed Agents

Languages and runtimes:

Commands and tools

Python libraries

Global Node.js packages

Deployments

Scheduled jobs—nothing magical. You define the associated resources and mounts.

When it executes, you get Runs, with each Run mapping directly to a Session.

Credential Vaults

Credentials can be injected in three ways:

1. Configure OAuth for MCP. You log in through the web interface during setup, grant authorization directly to Anthropic, and the credential is automatically injected into subsequent MCP requests.

2. Configure a Bearer Token for MCP, which is automatically injected into subsequent MCP requests.

3. Inject a credential directly into a request—for example, adding an API key to the HTTP Header of an outbound request.

With all three methods, the sandbox cannot see the secret itself. This differs from injecting an environment variable directly into the sandbox, where its value can be retrieved from the environment.

Here, for example, I asked it to send a request to my api.ifuryst.com.

It executed:

curl -s --http1.1 -X POST https://api.ifuryst.com
  -H "Authorization: Bearer $TEST"
  -H "Content-Type: application/json"
  -d '{"status":"completed","email_success":true,"email_id":"629d4d14-399e-43dd-b77a-bb2caa913dc6"}'

What my server actually received was 123. In other words, an egress gateway service replaced $TEST at the network boundary.

Memory Stores

This is straightforward: it is an LLM wiki, or a filesystem-based approach to memory management like OpenClaw and Hermes.

Files

There is not much to say here.

Skills

There is not much to say here.

RE

After trying it for myself, I think Managed Agents can be compared to AWS in the cloud era. At first, we had to buy physical machines and put them in a server room or IDC. Later, we only needed to provision an ECS instance from AWS, GCP, Alibaba Cloud, or another provider, along with services such as databases and S3. We stopped caring about the physical hardware underneath; we only cared about the configuration we provisioned and paid for it by time.

Managed Agents are the AWS of the Agent era. We do not need to care what the underlying Harness is written in, how to implement sandbox security and isolation properly, or keep a machine running around the clock solely for an Agent. We just pay and use it. The charges include:

• LLMs: model API calls, or token fees. Straightforward.

• Tools such as web_search: $10 per 1,000 requests.

• Session time: $0.80 per session-hour, billed only while running. This essentially bundles and abstracts away the underlying hardware, network, and other costs, making the pricing easier for users to understand.

Does the picture feel clearer now? This is PaaS for the Agent era—or what some call Harness as a Service.

In the past, we benefited from AWS handling the hardware and networking for us. Now, we benefit from Anthropic building the Harness for us.

With all that said, it is time to begin the analysis. I wanted to use the sandbox as an entry point for exploring the possibilities of the overall architecture. Naturally, the first step was to collect everything inside the MicroVM. I tried a number of approaches along the way. I did not record every idea and action as they occurred, so I will briefly recount what I remember:

• My first instinct in situations like this is usually to establish a tunnel, SSH in, and rummage around. This time was no different. With the ant CLI, it was even easier: I gave Codex a public machine and had it do the grunt work.

• I discovered that the sandbox’s outbound network was restricted by policy. Ports such as 80 and 443 worked, but other ports could not get out, so I tunneled SSH over HTTP with Chisel.

• After SSHing in and playing around for a while, the connection dropped. It looked like the environment stopped after becoming idle. So I had Codex work both sides itself: pick up a task, then go in and collect everything.

• In the end, I identified several key binaries and packaged them all for analysis.

• This involved reverse engineering the binaries. I was able to confirm the roles of several of them:

• process_api: A Rust service running as PID 1 and acting as the root process. It is effectively the process control plane inside the sandbox, responsible for init, system-level mounts, networking, the WebSocket API, cgroups/OOM, and other internal process management. It also receives external exec commands such as CreateProcess, along with related stdin/stdout/stderr and signals.

• environment-manager: The runner at the Managed Agents product layer. It handles initialization work including Git, snapshots, Claude Code configuration, MCP configuration, leases, observability, and more. Its behavior differs depending on whether Claude Code runs inside the sandbox.

• rclone-filestore: Mounts data actually used by the Agent, including uploaded files, memory, and skills. It uses FUSE, with a backend that talks to Anthropic’s HTTP API (api.anthropic.com) rather than directly to object storage.

At this point, I had a basic picture of the whole system. I also happened to find some related articles:

• https://johnsonlee.io/2026/03/28/when-claude-starts-to-awaken.en/?lang=en

• https://aprilnea.me/zh/blog/reverse-engineering-claude-code-antspace

• https://github.com/AprilNEA/reverse-engineering-claude-code-antspace

Johnson Lee’s article shows that in March, the sandbox was still running inside gVisor—and Claude Code itself broke out of it! This also demonstrates the differences in isolation. Even gVisor’s virtualized kernel does not provide sufficient isolation, let alone Docker/runc based on namespaces and cgroups. It also explains why so many systems now use Firecracker.

Today, it no longer uses gVisor. It launches MicroVMs with Firecracker, which has become a mainstream industry choice and is also used by E2B. This approach has prerequisites, the most important being KVM. That generally means going down to bare metal to get KVM easily, although nested KVM can work too. For example, I successfully used an n2-standard-4 VM on GCloud with --min-cpu-platform="Intel Cascade Lake" --enable-nested-virtualization.

AprilNEA’s article uncovered the March Firecracker version. The key difference is that it contains an unstripped environment-runner, making it easy to reverse engineer back into source code. I am sure other “inspired” products at home and abroad have been more than happy to analyze it and build from the blueprint 🤡.

Here is the structure listed in that article:

internal/
├── api/                  # API client (session routing, task polling, retries)
├── auth/                 # GitHub App Token provider
├── claude/               # Claude Code installation, upgrades, execution
├── config/               # Session modes (new/resume/resume-cached/setup-only)
├── envtype/
│   ├── anthropic/        # Anthropic-hosted environment
│   └── byoc/             # Bring Your Own Cloud
├── gitproxy/             # Git credential proxy server
├── input/                # Standard input parsing + secret handling
├── manager/              # Session manager, MCP configuration, skill extraction
├── mcp/
│   └── servers/
│       ├── codesign/     # Code-signing MCP server
│       └── supabase/     # Supabase integration MCP server
├── orchestrator/         # Polling loop, Hooks, identity discovery
├── podmonitor/           # Kubernetes lease management
├── process/              # Process execution + script runner
├── sandbox/              # Sandbox runtime configuration
├── session/              # Activity recorder
├── sources/              # Git clone + source classification
├── tunnel/               # WebSocket tunnel + action handling
│   └── actions/
│       ├── deploy/       # ← The key part is here
│       ├── snapshot/     # File snapshots
│       └── status/       # Status reporting
└── util/                 # Git utilities, lock files, retries, streaming logs

There is quite a lot of information here:

• Anthropic’s internal code appears to live in a private GitHub repository at github.com/anthropics/anthropic. It is a monorepo, mostly written in Go.

• One hilarious detail: **github.com/mark3labs/mcp-go v0.37.0**** **. Instead of the official MCP Go SDK, they use a third-party one.

• AntSpace, its PaaS competitor to Vercel, is also interesting. It is unclear whether it will be opened to the public later, which gives us something to ponder. Here is a passage from the article:

• BYOC clearly looks like something built for enterprise customers.

You can also see that Claude Code can run inside the sandbox at /opt/claude-code, but in production it runs outside the sandbox by default. This is the optimal architecture for enterprise use at scale, because the sandbox is what consumes resources. Keeping Claude Code outside has several benefits:

• LLM calls happen outside the sandbox, eliminating the risk of leakage.

• The Agent runtime stays outside the sandbox, reducing security issues.

• Large-scale scenarios can be optimized more deliberately.

• It could even move away from the standalone Claude Code version and replace it with a specialized cloud version.

DIY

I covered a lot in the RE section, but the ideas are still fairly scattered because much of the information was lost during exploration and I did not record every detail immediately. I have shared related things from time to time before. Once again, what I want to share here is a hacker mindset. Now that we have AI, we can use it as leverage to move far more than before; often, our thinking is the real bottleneck. These days, a tiny bit of guidance is often enough for AI to produce a great deal. This is also one of the abilities that lets you break through when everyone has access to the same AI.

With this information, the natural next step was to build one. AI drives the cost of building something toward zero. I learned a lot during the analysis, and I could continue learning through the act of making it. That is the delight of learning by doing.

I made a one-to-one replica of the Anthropic Managed Agents web interface, extracting its menus.

The API server acts as the control plane and writes data to the database. Scheduling is handled through the orchestrator, which asks sandboxd to provision sandboxes with Firecracker or Docker. process-api corresponds to process_api; env-runner accepts tasks inside the sandbox; and fs-bridge handles the relevant synchronization work.

One design difference is that this is intended to support Codex, Claude Code, OpenCode, Pi, and custom-built Agents. In practice, each Agent can determine whether it runs inside or outside the sandbox. Something highly configurable like Pi can run outside, while something less open like Codex can run inside the container.

I have had a lot going on recently, so this project is still a work in progress. I will keep moving it forward and finish it. If you are interested, follow along for future updates. When the time comes, I will also write a more detailed article about building a Managed Agents-like foundation for enterprise scenarios: the pitfalls, the technologies involved, how the architecture should be planned, and all the related insights, ideas, and solutions.

Closing Thoughts

This article should have been published last month, but I genuinely had too much going on and kept postponing it. Then I remembered a line I have believed in for the past year or two: “Done is more important than perfect.” So I decided I needed to finish this article. I believe the value of letting the people who need it see it matters far more than the perfection I imagine in my head. I did my best to bring it to a close instead of letting it rot in my notebook like so many of my Drafts.

Once again, this is an article about how I made something happen. As I said earlier, AI may make us dumber and lazier, but it can also let us stand on the shoulders of giants and do more of what was once difficult to achieve. What matters is how you think and what you do. Once your ideas are set free, the next step is to Push and execute; everything else comes down to external opportunities. Is love, career, or life really any different?