By Daniel Goodrich, Local Service Spotlight
A Claude Managed Agent is an AI agent that Anthropic hosts for you, along with the computer it runs on. You give it a job and the tools to do it, it runs the work on its own, then it hands a person the result to approve.
You do not run a server, babysit a browser, or keep a script alive. This guide explains the pieces, how you reach the agent, when a managed agent fits, and how to build one.
The quick answer: use a managed agent when you have a repeatable expert process, the tools it needs live behind an API, and you want it to run on demand or on a schedule with a human review gate. Do not use one when you want a public chatbot anyone can open in a browser. That is not what this is.
Managed agent versus a chatbot
Most things people call an AI agent are a chat window with a clever prompt. You type, it answers, and nothing happens in the real world.
A managed agent is different. It has tools. It can read a database, pull an analytics account, call an API, run code in its own sandbox, and take many steps toward a goal without you prompting each one.
Anthropic runs the agent and the sandbox, so no infrastructure stays alive on your side. It also differs from building your own agent from scratch.
Wire up your own agent and you own the servers, the scaling, the sandbox security, and the plumbing that connects the model to your tools. A managed agent hands all of that to Anthropic. You bring the method and the tools, and they run it.
The pieces, in plain language
A managed agent is made of a few parts. Once you know them, the whole thing is simple.
The agent is the configuration. It holds the model you chose, a system prompt that sets the standing rules, the tools it can call, and the skills it follows. Think of it as the job description plus the rulebook.
The environment is the sandbox the agent works inside. It is a private Linux computer that boots for a single run and shuts down for good when the run ends. You control what it can reach on the network.
Our GA4 agent that reports on local service clients reaches only its own analytics connection and nothing else. That keeps a runaway step from touching anything it should not.
MCP servers are the standard way an agent connects to tools and data. An MCP server exposes a set of actions, and the agent calls them.
For our reporting agent, one MCP server exposes Google Analytics: read a property, run a report, pull a funnel. You attach the servers the job needs and nothing more.
Credential vaults keep secrets out of the agent’s configuration. A vault is a separate, workspace-level store for the tokens and keys the agent needs.
The vault attaches to a run, the agent uses the credential, and the secret never sits in the config. No one types it into a chat. This is the part that keeps a shared agent from leaking its keys.
Skills are the method, written down. A skill is a folder of instructions the agent loads when it needs them.
Our GA4 skill carries the full reporting procedure: how to check the property, how to define a lead for each business model, how to screen spam, how to decompose a swing, and the exact report format. The model provides the intelligence, and the skill provides the discipline. We describe that method in full in our guide to reading a small business’s GA4 correctly.
Sessions are one run of the agent. You create a session against the agent, hand it the environment and any vaults, and send it a task. It works through the steps and streams back what it does, and every report we run is a session.
Deployments run the agent on a schedule or a trigger, with no person starting it. A weekly client report every Monday morning is a deployment. It is automation, not a public front door, and you still retrieve the results through the same channels.
Reach a managed agent through three doors
Knowing which door is which saves a lot of confusion.
The Console is the workspace where a person opens the agent and runs a session by hand. It is the fastest way for a team member to test and use the agent, and it needs no code. They do need an account in your workspace.
The API is the programmatic door. A script, a Slack bot, or a simple web form can create a session and send the agent a task from anywhere, using an API key. This is how you wire the agent into something else.
Deployments are the scheduled door for recurring runs.
There is no fourth door. No public link lets a stranger chat with your agent.
If you want a non-technical person to use the agent without Console access, build a thin interface on the API. We did exactly that.
A teammate types a client and a property into a simple web form, the form calls the agent through the API, and the finished report comes back with a link to a saved copy. We embedded that form on our own site so a reviewer never touches the Console.
The “own front end” door is real, and it is not much work once the agent exists. Console for your team, API for programs, and your own form when you want a clean experience for someone non-technical.
Why this matters for agencies, coaches, and small businesses
The value is scale with a safety gate.
Every agency has a handful of processes that only the senior people do well. A managed agent lets you write that process down once, hand it to a hosted specialist, and run it on demand or on a schedule.
The senior person reviews the draft instead of building it from scratch. You get more of their judgment across more clients without cloning the person.
We run this at Local Service Spotlight for our GA4 reporting, and one recent run for a residential painting client shows why. Website visits were up 55 percent, which looks like great news.
Instead of stopping there, the agent decomposed the jump. It found almost all of it was one social ad channel that produced close to zero real leads, while true leads were actually down 27 percent once bot form-fills were screened out.
That is the kind of finding a rushed weekly report misses. A person reviewed the draft in minutes instead of starting from a blank page. We walk through that entire run, anonymized, in a companion case study.
Coaches and course creators have the same opening. Your method is your product.
A managed agent can run your method for a student, produce a first draft, and let you or the student refine it. The shape is the same: method plus tools plus a review gate.
Decide when to use one, and when not to
Use a managed agent when the work is a defined expert process, the tools live behind an API or an MCP server, and a human should approve the output. Reporting, audits, research sweeps, compliance checks, and recurring data pulls all fit.
Skip it when you want an open-ended public chatbot, when the task has no tools and is pure conversation, or when you have not written down the method yet. The agent runs a process. If the process is fuzzy, the agent will be too, so write the method first.
Build one step by step
The path we followed maps to any process.
Write the method as a skill. This is the real work, and the clearer the procedure, the better the agent.
Host your tools as an MCP server so the agent has a clean way to reach the data and actions it needs. Create the agent, set the model and the standing rules, then attach the MCP server and the skill. Store secrets in a vault so tokens stay out of the config.
Prototype in the Console, run it by hand, watch every step, and fix what the method missed. Then open access: add teammates to the Console, wire the API, build a form, or schedule a deployment.
We documented our own build of a hosted GA4 reporting agent, including the setup bugs that cost us time and the tester form we put in front of it, in the companion meta article so you can skip the same traps. The pattern reuses cleanly, and the second agent is faster than the first.
The shift worth noticing
The interesting change is not that the model got smarter. It is that you can now hand a hosted specialist a written method and a set of tools and have it run the work the same way every time, with a person approving the result.
That moves AI from a chat window you prompt to a worker you supervise.
My own take is that the teams who win with this are not the ones with the fanciest model, they are the ones who bothered to write their process down. If you have a process worth running that way, document it first, then read how BlitzMetrics builds AI agents and the system that documents itself, and message me if you want help turning your process into an agent your team can run.