When agents stopped being solo acts
For most of 2024 and into 2025, the standard pattern for an AI coding agent was one model, one session, one task. Run it locally, wait for it to finish, check the output. That worked — up to a point.
The ceiling became obvious once the tasks got bigger: context windows fill up, laptops struggle under a simultaneous browser, code execution sandbox, and LLM session, and anything worth automating for a team can’t easily run under a single developer’s personal subscription. These are the problems managed, cloud-hosted agents are designed to solve.
The architecture shift is simpler than it sounds: instead of running an agent on your machine, you launch it in a cloud sandbox via a single API call. The sandbox handles compute, built-in tools (code execution, file reads and writes, web search), and tool-calling orchestration. What the caller supplies is the goal and, optionally, files the agent should start with.
The piece that makes multi-agent handoffs actually work
The more interesting design decision is how agents in a pipeline communicate without stepping on each other.
The emerging answer isn’t message queues or shared databases — it’s a shared file system state called an environment. Each sandbox has one. An agent reads and writes files inside it; when it finishes, a second agent can attach to the same environment and pick up exactly where the first left off, without inheriting the first agent’s full conversation history.
This matters because context windows are not free. Passing the complete conversation thread from Agent A to Agent B means Agent B starts with a cluttered, possibly contradictory context. The environment separation keeps each agent’s context clean while preserving all the intermediate artifacts — the JSON files, the CSV exports, the analysis outputs — that carry actual meaning.
In practice, a three-agent pipeline for financial research looks like this: a researcher agent fetches SEC filings and writes a structured data file to the shared environment; a quantitative analysis agent attaches to that same environment, reads the file, runs Python analysis, and writes a forecast; a report agent takes the forecast and produces a formatted PDF with charts and source links. Each agent is narrow, focused, and unaware of the others’ internal monologue. The environment is the only thing they share.
Separation of concerns, applied to agents
What this architecture enforces is something software engineers have known for decades: components that communicate through well-defined artifacts — files, messages, schemas — are easier to reason about, swap out, and debug than components that pass their internal state directly.
The same logic applies here. An agent that writes `metrics.json` and stops is testable, replaceable, and inspectable. An agent that receives a 40,000-token context dump from its predecessor is none of those things.
Managed cloud agents add a few operational properties that make this more tractable at scale. Credentials never enter the sandbox: a proxy injects tokens only at the API boundary, so the agent holds only a placeholder. Model choice can vary per agent — faster and cheaper models for routine retrieval steps, deeper-reasoning models for the hard analytical work. And the whole setup is reproducible and shareable across a team, eliminating the “it worked on my laptop” problem that plagues locally-run agent setups.
Where this is heading
The pattern taking shape here — cloud sandbox, clean environment hand-offs, purpose-specific agents with swappable models — is less a single vendor’s product feature and more a set of architectural defaults the field seems to be converging on independently. Multiple platforms are arriving at the same primitives from different directions.
The interesting open question isn’t whether to use managed agents. It’s how to design the artifacts that agents leave behind: the schemas, the file naming conventions, the intermediate data formats that make the pipeline’s outputs readable and auditable. The quality of a multi-agent system increasingly depends not on how capable individual agents are, but on how clean and interpretable their shared outputs are. That is a design problem, and it sits squarely with the practitioners building these systems — not with the platforms running them.
Text summarized and optimized using Anthropic’s models and reviewed by a human.