Managed agents vs self-hosted, when each makes sense
Anthropic put Memory for Managed Agents into public beta in April 2026. When do you take that, when do you self-host?
Since April 23, 2026, "Memory for Managed Agents" at Anthropic is in public beta. That's Anthropic's direct move to a hosted platform for agent workers, with session, harness and sandbox virtualization as decoupled services. Until now you had to host that yourself: own postgres, own memory server, own container runner. Now it's available as-a-service.
That raises a question you'll have to answer as an operator at some point: hosted or self-hosted?
In this lesson you'll learn when each makes sense, what the actual trade-offs are, and how to document a decision you can still understand two years from now.
What Anthropic's Managed Agents actually is
Three decoupled services:
- Session service. Conversation state and memory, persistent across sessions. What would be a postgres table on your side runs here on Anthropic infrastructure.
- Harness service. What runs the agent: making tools available, connecting MCP servers, checking permissions.
- Sandbox service. Code execution in an isolated environment. Instead of you building docker containers and daemons, you send bash code to the sandbox and get the result back.
Plus a token vault for secrets. Meaning: you no longer have to manage API keys in containers or build vault lookups. You give Anthropic your secrets once, the sandbox service gets them at runtime.
Pricing: in beta it's part of Max Plan, later probably per-sandbox-hour. Exact terms aren't public yet.
When hosted (Managed Agents) makes sense
When you're the builder, not the devops person. You're building a tool, you don't want to manage a postgres cluster on the side. Hosted takes the infra questions off your plate.
When you're validating a prototype. Faster start, less setup. If the prototype fails, you haven't built up infrastructure you now have to tear down.
When your use case has no hard data sovereignty requirement. B2C tools, marketing automation, personal assistants. Data is allowed in US cloud, no compliance blocker.
When latency is primary and you don't want to optimize yourself. Anthropic has edge locations worldwide; self-hosting in Frankfurt means 200ms round-trip if a user accesses from Australia.
When you have few custom MCP servers. Hosted supports the standard MCPs out of the box (GitHub, Slack, Notion etc.). Your own internal MCP works too, but then you also need a public URL plus auth.
When self-hosted makes sense
When data sovereignty is a hard requirement. EU data residency for GDPR-sensitive data, German Bundesnetzagentur audits, healthcare, legal mandates. Anthropic-hosted is US cloud, that's not legally feasible for many SMEs.
When your use cases are very custom. You need ten of your own MCP servers all going against your internal APIs, with auth patterns hosted doesn't know. Self-hosted gives you the freedom to define everything yourself.
When you want to keep cost control. At large volumes a self-operated postgres can be significantly cheaper than per-session pricing of a managed service. But: you pay for that with devops time.
When you have air-gap requirements. Some enterprise setups don't allow cloud calls from production systems. Self-hosted is the only option.
When you want deep customization. Own memory strategies, own decay functions, own embedding models. That doesn't go in hosted, or only in a limited way.
The hybrid variant (often the right answer)
In practice the answer is rarely "all hosted" or "all self-hosted", but hybrid:
- Hosted for standard use cases. Day-to-day, marketing, generic assistants. Fast iteration, no infra maintenance.
- Self-hosted for sensitive use cases. Customer data, financial reports, legal content. EU servers, own memory database, own container runner.
For StudioMeyer we do exactly that: SaaS memory server (memory.studiomeyer.io) is hosted, but our internal agents (Academy Fleet, MCP SaaS Fleet) run on our own container setup with our own postgres, because internal data and customer data come together there.
Decision framework
If you're not sure, walk through these five questions:
- Data sovereignty: Must the data stay in EU/Germany? If yes → self-hosted or EU-hosted provider.
- Compliance: GDPR-sensitive, health/legal/finance, BaFin-relevant? If yes → self-hosted or enterprise plan with DPA.
- Custom MCPs: Do you have more than two of your own MCP servers running internally? If yes → self-hosted is simpler.
- Devops capacity: Do you have someone who maintains a postgres cluster and tests disaster recovery? If no → hosted.
- Volume + cost control: More than 1000 sessions/day? If yes → self-hosted gets cheaper above a threshold.
If you say "yes" to 2 or 3 of these → self-hosted or hybrid. Otherwise → start hosted, migrate later if needed.
Migration path
Important: you can migrate from hosted to self-hosted, but it's work. Anthropic Managed Agents stores memory in their format, you have to export it and convert it to your own format. Plan at least a week if you take this seriously.
The other way (self-hosted to hosted) tends to be easier because Anthropic offers import tools. But that isn't zero effort either.
What you have now
A clear picture of what hosted vs self-hosted means, when each makes sense, and a decision framework for your own architecture. Important: this isn't a religious question but a use-case-driven decision that can change over time.
Plus: 80 percent of StudioMeyer customers run hybrid. Hosted when fast, self-hosted when sensitive. That 80 percent solution is usually the right one.
Next steps
Capstone Level 5 is your test case. Build a multi-agent setup for a use case of your choice, document whether you take hosted or self-hosted and why. If you write that down instead of just thinking it, you have a decision basis for later refactoring.