Managed Agent
An AI agent hosted by a platform (most commonly Anthropic's infrastructure) rather than running inside a personal terminal session. A Managed Agent persists beyond the operator's session, exposes a stable invocation surface (an API call or a button in an internal app), and reaches external systems through a governed tool gateway.
What a Managed Agent Actually Is
A Managed Agent is the same agent loop you would run in Claude Code on your laptop, except the loop now runs in the cloud. The session does not end when the operator closes the terminal. The agent has a stable identity that the rest of the application can call. Tools the agent uses are exposed through a controlled gateway rather than wired up ad hoc. Outputs land in a defined location (a database row, a file in object storage, a webhook payload) rather than scrolling past in a terminal window.
The mechanism varies by platform. Anthropic’s Managed Agents run inside the Claude infrastructure with a hosted session, controlled tool access, and a callable API. Custom-built equivalents on AWS Bedrock, Google Vertex, or Azure OpenAI follow the same shape: hosted compute, persistent identity, audited tools, returned artifacts. The common feature is that the operator is no longer the host of the agent. A platform is.
How a Managed Agent Differs From a Skill
A Skill is instructions. A Managed Agent is execution infrastructure that can read those instructions and act on them autonomously inside an organization’s systems. A team that has written a strong Skill in Claude Code is one significant step away from having a Managed Agent: the Skill becomes the doctrine the Managed Agent follows. What the Managed Agent adds is everything around the Skill that turns it from a personal tool into a product feature. Authentication. Authorization. Quotas. Job history. Output storage. Multi-user invocation. An admin panel.
This is the gap most teams underestimate. Writing the Skill takes a day. Wrapping a Skill in the surrounding infrastructure to make it a Managed Agent takes weeks, sometimes months. The Skill is the easy part. The architecture around the Skill is the work.
For this reason, TWO’s standing recommendation is that most workflows should remain at Floor 3 (Skill in a terminal session) until the Skill has been used reliably for at least thirty real runs. Promoting a Skill to a Managed Agent before that threshold is the single most common failure mode of corporate AI projects. The Skill works. The Managed Agent built around an unproven Skill does not, because the operator never had the chance to discover what the Skill should actually do.
How a Managed Agent Differs From a Distributed Agent
A Managed Agent runs when called. A Distributed Agent runs on a schedule, potentially across multiple regions, without anyone deciding it should run today. Both are hosted. Both are persistent. The difference is whether the agent’s invocation is event-driven (a user clicked a button, an API call came in, a webhook fired) or schedule-driven (a cron expression, a watcher, a background loop).
Most teams should reach a working Managed Agent before considering Distributed Agents. A scheduled agent that runs poorly written workflows simply runs them more often. The Distributed Agent (Floor 5) amplifies whatever exists at Floor 4. Get Floor 4 right first.
The Architecture It Belongs To
A Managed Agent does not stand alone. It is one component of a larger system that typically includes:
A control plane that owns user identity, role-based access, quotas, and job history. In most internal builds, this is the application’s existing portal extended with an “AI Tools” module rather than a standalone product.
A storage layer for the inputs the operator submits and the outputs the agent produces. Files, structured records, run-history rows. This is usually a database the application already has.
A tool gateway that exposes typed, audited capabilities to the agent. Operations like “search account by domain” or “get inventory levels for SKU X” are wrapped as named tools through the Model Context Protocol rather than direct API access. The gateway handles permissions, logging, and the rate limits the underlying systems impose. Without a gateway, every agent ends up with its own bespoke API client, its own auth code, and no audit trail.
An invocation surface, usually a form in the application’s UI. Form-driven workflows have predictable cost and clear success criteria. Chat-driven workflows have neither and should rarely be the first interface to a Managed Agent.
When all four of these are present, the Managed Agent is genuinely a product feature. When any of them is missing, the Managed Agent is a Skill in expensive packaging.
How TWO Uses It
The Wise Operator’s curriculum positions Managed Agents as the natural graduation target for an operator who has already proven a Skill at Floor 3. The full architectural progression, including the cross-cuts between workflow and chat agents, read-only and write-enabled agents, and the role of the tool gateway, lives in the Five Floors of AI Architecture Scroll. For builders evaluating whether their next AI initiative belongs at Floor 4, the practical filter is whether the underlying Skill has been used successfully thirty times by the operator who would own the Managed Agent. If yes, climb. If no, stay on Floor 3 until the Skill has earned the trip.
The promise of Managed Agents is real. The premature reach for them is the more common reality. Most operators are better served by patient Skill work than by ambitious agent infrastructure that has not yet earned the privilege of existing.