A managed agent is an AI agent that runs on infrastructure the platform hosts and operates, so the provider handles the operational work around agent execution, long-running background tasks, remote tool connections, state between steps, and the reliability of running in production. You configure and call the agent instead of building and running that machinery yourself.
In plain language
Building an AI agent and running one in production are two different problems. Getting a model to plan a step, call a tool, and read the result is the first problem. Keeping that going for minutes or hours, surviving restarts, connecting to tools that live on someone else's server, and doing it for thousands of users at once is the second. The second problem is plumbing, and it is a lot of it.
A managed agent hands that second problem to the platform. Instead of standing up your own servers, queues, and retry logic to run an agent, you describe the agent to a provider and let the provider run it. The reasoning still comes from the model, and the agent behaviour is still an agent, planning, tool calls, checking results. What changes is who owns the runtime underneath.
The pieces a managed offering typically takes over are the ones that are tedious and easy to get wrong. Long-running work becomes a background task the platform tracks, so a job that takes an hour does not need your own process babysitting it. Remote tool connections let the agent reach tools and data hosted elsewhere, often through MCP, without you wiring each one by hand. State between steps is stored for you, so the agent can pick up where it left off. And the operational side, scaling, restarts, and the ability to see what the agent did, sits with the provider.
The trade is the usual one for managed services. You give up some control over the runtime and you accept the provider's shape for how agents are defined and run, in exchange for not having to build and operate that layer yourself.
An everyday picture
Think of the difference between owning a car and using a car service. Owning the car, you still decide where to go, but you also handle fuel, maintenance, parking, and what to do when it breaks down on the highway. A car service leaves the destination to you and takes the rest, the vehicle, the driver, the upkeep, the problem when something fails at midnight. A managed agent is the car service. You still decide what the agent should do and give it its goal; the platform handles the vehicle underneath, keeping it running, refueling the long trips, and dealing with the breakdowns.
Where it shows up
Managed agents show up wherever a team wants agent behaviour in production without owning the runtime. Cloud AI platforms are the clearest place, where a provider offers a hosted way to define an agent, connect it to tools, and run it at scale, as with Google's Managed Agents in the Gemini API. The pattern fits long-running back-office jobs, research and data tasks that run for minutes, and assistants that need to reach many remote tools through MCP. It overlaps with orchestration once several agents or steps have to be coordinated, with monitoring because seeing what a hosted agent did is part of what the platform provides, and with the API layer, since a managed agent is usually something you call rather than something you host.
A small example
In July 2026 Google described expanding Managed Agents in the Gemini API, pointing to background tasks, remote MCP connections, and more, framed as helping developers build reliable, production-ready agents. Read against the definition, each piece maps to the operational layer a managed offering takes over. Background tasks are the long-running work the platform keeps going on its own. Remote MCP is the agent reaching tools hosted elsewhere through a standard connector rather than bespoke wiring. And production-ready is the reliability side, the part a team would otherwise have to build and operate. The exact limits and settings sit in Google's own documentation; the shape is the point here, a provider offering to run the agent so the developer does not have to.
Common misunderstanding
One line to take with you
A managed agent is an agent you configure and call while the platform runs it, taking over the operational layer, long-running background work, remote tool connections over MCP, state between steps, and production reliability. It does not make the agent smarter and it does not remove your responsibility for what the agent is allowed to do. It removes the burden of building and operating the runtime. Reach for it when the hard part is running an agent reliably at scale rather than getting one to work at all.
Frequently asked
They are the same idea seen from two sides. An AI agent is the behaviour, a model that plans a step, calls a tool, reads the result, and decides what to do next. A managed agent is that same behaviour running on a runtime the platform owns and operates. The distinction is not what the agent does but who runs it underneath. With a self-hosted agent, you stand up the servers, keep long tasks alive, wire up each tool, store state, and handle scaling and restarts yourself. With a managed agent, the provider takes that operational layer, and you configure the agent and call it through an API. The reasoning and the agent loop are unchanged; the machinery beneath them changes hands.
No. The platform manages the runtime, not the decisions about what the agent is allowed to do. You still choose which tools the agent can reach, how broad that access is, which actions need a human approval step, and how much the agent may do unattended. Those are the same trust concerns that sit in any agent's harness, and they do not move to the provider just because the provider runs the process. Over-broad tool access still widens the blast radius of a mistake, and connecting to remote tools through MCP still means deciding what data flows where. A managed agent lets you skip building the infrastructure; it does not let you skip designing the guardrails.
It makes sense when the hard part of your problem is operations, not getting the agent to work at all. If your agent has to keep long tasks running for minutes or hours, survive restarts, reach many remote tools, and serve a lot of users at once, that operational layer is real work, and a managed offering lets you skip building it. It fits teams that want to move quickly and are comfortable with the provider's shape for defining and running agents. Running your own makes more sense when you need tight control over the runtime, have unusual requirements the platform does not support, or want to avoid depending on one provider. The choice mirrors any managed-versus-self-hosted decision, weighed for agents.