Should you choose a self-hosted AI agent or a managed service?
Choose a self-hosted AI agent when your business needs deep control over data, integrations, and runtime behavior, and someone can own the system after launch. Choose a managed service when you need a working business outcome without becoming responsible for deployment, monitoring, upgrades, recovery, and every integration failure.
What does self-hosted actually mean?
Self-hosted means your business controls the environment where the agent runs. That may be your own server, cloud account, database, secrets, model connections, logs, and deployment process. It does not automatically mean every model runs on your hardware. A self-hosted agent can still call an external model API while keeping its workflow, state, tools, and operational records inside infrastructure you control.
A managed service shifts some or all of that operating responsibility to a provider. The provider may deploy the agent in its environment, your environment, or a hybrid setup. The useful distinction is not whose logo appears on the software. It is who receives the alert, investigates the failure, restores the task, updates the integration, and proves the system is healthy afterward.
That distinction matters because an agent is not just a chat interface. Anthropic defines workflows as systems where models and tools follow predefined code paths, while agents dynamically direct their own processes and tool use. The more discretion the system has, the more important ownership of permissions, state, evaluation, and recovery becomes.
The decision is control versus operating responsibility
Self-hosting gives you more control, but control is not the same as ownership in practice. You only own a system if you can inspect it, change it, recover it, and keep it useful when a dependency changes. A repository and a server bill do not provide those capabilities by themselves.
Managed service is often described as giving up control for convenience. That is too crude. A good managed arrangement can run inside infrastructure you own, preserve exportable workflow definitions, expose logs and evaluation results, and require approval before sensitive actions. A bad arrangement can hide the process behind a dashboard and leave you unable to move your data or reproduce a decision.
So the real comparison has two axes. The first is operational responsibility: who runs and repairs the system? The second is asset control: who controls the business rules, data, credentials, evaluation cases, and exit path? You can outsource the first without surrendering the second. That is usually the better target for a small business.
When does self-hosting win?
Self-hosting wins when the workflow creates a real reason to control the runtime. Sensitive data may need to remain inside a defined environment. The agent may require custom connections that a generic platform cannot support. Your team may need exact logs, model choice, approval rules, retention settings, or the ability to change providers without rebuilding the entire process.
It also wins when you already have someone who can operate it. That person does not need to be a large engineering team, but the responsibility must be named. They need access to deployments, logs, backups, credentials, integrations, and test cases. They need enough context to tell whether a failed task came from the model, the tool, the data, the network, or a changed business rule.
Self-hosting is a poor choice when it is selected mainly to avoid a monthly service fee. The visible infrastructure charge is only one cost. Patching, monitoring, incidents, dependency changes, model updates, security review, and failed-task cleanup still exist. If nobody has time or authority to do that work, the business has not removed the cost. It has made the cost unpredictable.
When does a managed service win?
A managed service wins when the business wants the workflow to work but does not want to build an internal agent operations function. This is common when the target process is valuable, bounded, and connected to real systems, yet the company has no technical owner for deployments and incidents.
The strongest managed offer is not a rented chatbot. It includes process discovery, implementation, permissions, representative tests, deployment, monitoring, change handling, and a clear response when the system fails. Anthropic's work on managed agents separates sessions, the agent harness, and the execution sandbox so each component can change without disturbing the others. That design principle matters beyond one vendor: managed systems should isolate replaceable components rather than trap the whole workflow inside one opaque product.
Managed service is also the safer first move when the workflow is still being learned. A provider can help bound the task, expose exceptions, and determine whether an agent is even necessary. Anthropic recommends using the simplest solution that works because agentic systems often trade additional latency and cost for better task performance. Sometimes the correct result of discovery is ordinary automation with one model-assisted decision, not an autonomous agent.
How should you compare the two options?
Start with the workflow, not the hosting model. Name the trigger, inputs, decisions, systems touched, external actions, exceptions, owner, and definition of done. Then compare who handles each responsibility.
For data and access, ask where business data is stored, which providers receive it, how long logs remain, and who controls credentials. For execution, ask how the agent avoids duplicate actions, what requires human approval, and what happens when a tool is unavailable. For quality, ask for representative evaluation cases and the acceptance threshold before permissions expand.
For operations, ask who monitors failed runs, who responds outside normal hours if that matters, how upgrades are tested, and how recovery is verified. For ownership, ask whether you can export the workflow definitions, instructions, evaluation cases, logs, and operational data in a usable form. For exit, ask what continues working if the provider relationship ends.
NIST's AI Risk Management Framework emphasizes governing, mapping, measuring, and managing AI risk across the system lifecycle. That is a useful buying lens. A vendor that discusses the model but cannot explain responsibility, measurement, incident handling, and change control is selling a component, not an operated system.
What should a managed provider let you keep?
Keep control of your business knowledge, source data, credentials, approval policy, and customer records. You should also receive enough evidence to understand what the agent did: task history, tool actions, relevant inputs, outputs, errors, and evaluation results. The provider may own reusable platform code. It should not make your operating process impossible to inspect or migrate.
Require a written responsibility boundary. It should identify what the provider monitors, what your team must maintain, which changes are included, how incidents are classified, and what happens when an external integration changes. The boundary should also state who can authorize new tools, broader permissions, or autonomous external actions.
Do not accept vague claims that the system is private, secure, or compliant. The FTC has warned AI companies to honor their privacy and confidentiality commitments. Ask for the actual data flow, retention rules, subprocessors, access controls, and deletion process that apply to your deployment. Marketing language is not an operating control.
A practical decision rule for a small business
Choose self-hosted when three conditions are true: the workflow creates a concrete need for runtime control, the system can be operated by a named person, and the expected value justifies ongoing maintenance. If one condition is missing, self-hosting may give you infrastructure without reliable execution.
Choose managed when the outcome matters more than the infrastructure, the workflow needs custom implementation, and you want one accountable party for operation. But keep ownership requirements in the contract. Managed should mean someone else operates the system with evidence, not that your business becomes dependent on a black box.
If you are unsure, run a bounded pilot in an environment that can later move. Use one workflow, limited permissions, representative cases, explicit approval points, and an exportable record of the design. The pilot should answer whether the process works, what it costs to operate, and which responsibilities your team is actually willing to own.
Limitations
There is no universally better deployment model. Regulated work, contractual data restrictions, existing cloud commitments, internal skills, uptime requirements, and integration depth can change the answer. A managed service can still be deployed in customer-controlled infrastructure, and a self-hosted system can still depend on external models and tools.
This comparison also does not prove that your workflow needs an agent. A deterministic integration, rules engine, or model-assisted workflow may be cheaper and easier to audit. Decide the work first. The hosting choice comes after the process, permissions, evidence, and owner are clear.
Map the responsibility before choosing the server
Bring one workflow, the systems it touches, the decisions it makes, and the failures you cannot accept. We can map what should stay deterministic, where a model helps, which actions need approval, and whether your team should operate the result or use a managed setup.