Recently Anthropic shipped Claude Managed Agents (CMA). It’s a real moment for the space. Notion, Asana, Sentry, and Rakuten were all named in the launch, and all running real work on it. If you’re building anything agentic, you need to understand what CMA is, what it isn’t, and how to decide when to use it versus a runtime like Wippy. These are not the same product, and in most cases they don’t compete directly. But teams evaluating their infrastructure options squint at both and ask the same question, so let’s make it easy.
Key Takeaways
CMA is a managed hosted runtime and fast to start, zero infrastructure ownership, runs on Anthropic’s platform:
• Wippy is a self-hosted runtime you control with model-agnostic, multi-tenant by default, deployable in your own VPC
• CMA becomes a ceiling when compliance requirements, tenant isolation, model optionality, or cost shape at scale enter the conversation
• The decision isn’t about which product is better but it’s about whether your production system requires you to own the runtime
• Teams building products that other organizations depend on almost always need the runtime
Why CMA’s managed rails are the right choice until they aren’t
Strip away the marketing and CMA is a hosted runtime for AI agents on Anthropic’s platform. Anthropic handles the hard operational layer: sandboxed code execution, credential storage, long-running sessions that survive disconnects, multi-agent coordination, tracing, and a console where you can watch your agents think and fail. You bring the prompt, the tools, and the use case. They bring the rails.
The pitch is speed. Prototype to production in days rather than months. Pricing starts around eight cents per runtime hour plus normal token costs, so a 24/7 agent runs roughly sixty dollars a month before the model bill. Notion uses it to delegate slides and spreadsheets inside their workspace. Asana built AI Teammates that pick up tickets in projects. Sentry wired one up that goes from a flagged bug to an open pull request with no human in the middle. Rakuten rolled out specialist agents across product, sales, marketing, finance, and HR in under a week each. That’s impressive. It’s also a clear signal about where CMA lives on the map – and where it stops.
The hotel and the house: why this analogy is more than a metaphor
CMA is a hotel. You check in, the wifi works, and you pay by the night. You don’t think about the plumbing. You don’t think about the boiler. You don’t own the building. If you wanted to repaint a wall, you can’t. When you want to add a new wing, you move hotels.
Wippy is the house. You own it. You can remodel the kitchen, add a second floor, rent out rooms to different tenants, run a business out of the basement, and nobody sends you an eviction notice when your electricity bill gets complicated. You’re responsible for more, but the thing you build on top actually belongs to you.
Both of these are valid. A lot of teams should stay in hotels. A lot of teams need to own the house. The mistake is pretending one is the other, or assuming the hotel will accommodate every kind of tenant indefinitely.
What Wippy actually is when you strip away the marketing
Wippy is an intelligent application runtime and workflow orchestration engine built for agentic and event-driven automation that can run in your local environment or in the cloud. It’s what you run your agents on when you want them to behave like real software instead of a clever demo. Multi-tenant by default, so one deployment can serve many customers or many internal teams with proper isolation between them. Built for long-running workflows, not just one-shot prompts.
Handles concurrency, lifecycle management, failure recovery, permissioning, and deep LLM integration as first-class concerns.
If CMA is a managed service, Wippy is a runtime you self-host, customize, and run anywhere – your VPC, your cloud, your data boundaries, your model choices, your orchestration logic. The distinction matters because in enterprise environments the runtime is never just an implementation detail. It’s a compliance boundary, a cost center, a vendor relationship, and an architectural commitment that shapes everything built on top of it.
Where the overlap ends and the real infrastructure decisions begin
Both products give you a place to run multi-agent pipelines. Both handle tool calls. Both care about tracing and long-running sessions. If you’re building a single-purpose agent on Anthropic and you don’t care where the runtime lives, CMA will probably get you there faster. That’s the honest answer.
Where they stop overlapping is everything enterprises argue about on the second call. The table below classifies the decision dimensions that matter most in practice:
| Dimension | Claude Managed Agents | Wippy |
| Deployment model | Anthropic-hosted | Self-hosted (VPC, cloud, on-prem) |
| Model dependency | Claude (Anthropic) | Model-agnostic |
| Multi-tenancy | Limited | First-class, by design |
| Data residency | Anthropic infrastructure | Your infrastructure |
| Orchestration | Managed primitives | Custom workflow engine |
| Compliance posture | Anthropic’s controls | Your controls |
| Cost shape | Per runtime hour + tokens | Infrastructure + tokens |
| Integration depth | SaaS API surface | Direct system access |
| Runtime ownership | None | Full |
The rows that tend to end the CMA conversation are data residency, multi-tenancy, and integration depth. Not because CMA is poorly built, but because those constraints require infrastructure you control, and managed services are designed around the opposite assumption.
The three places managed infrastructure breaks in production
The compliance ceiling mid-build. The most expensive version of this problem happens when a team builds significant workflow logic on CMA and then hits an enterprise client’s security review. The client requires data residency inside their own VPC. The SOC 2 audit flags the third-party runtime dependency. The legal team won’t approve data flowing through infrastructure the company doesn’t control. By that point, the orchestration logic is tightly coupled to CMA’s primitives, and the migration cost is measured in months, not days. The teams we work with at Spiral Scout who avoided this problem made the runtime decision before the compliance conversation, not after it.
Multi-tenant isolation that managed infrastructure wasn’t designed for. A product company building on CMA for internal use cases is one thing. Extending that same infrastructure to serve twenty enterprise clients – each with their own data boundaries, permission models, and audit requirements – is a different problem entirely. CMA’s primitives don’t provide the tenant-scoped isolation architecture that a product serving multiple organizations requires. This isn’t a bug, it’s a scope decision. Managed services optimize for the single-organization case. If you’re building a product, you are the organization running infrastructure for others, and that requires a fundamentally different runtime model.
Cost structure that works at five agents and breaks at fifty. The per-runtime-hour pricing model is sensible for low-volume experimentation. At fifty always-on workflows running complex orchestration logic, the math changes significantly. More importantly, you’re paying for infrastructure you can’t optimize, can’t inspect below the API surface, and can’t negotiate terms on. The compounding advantage of a runtime you control – where you can optimize scheduling, reduce redundant model calls, and tune concurrency – disappears entirely when the runtime belongs to someone else.
How to know which side of the line you’re on
Pick CMA if you’re moving fast, you’re happy on Anthropic’s platform, you want zero infrastructure ownership, your use case maps cleanly to their primitives, and your customers don’t have strong opinions about where the runtime lives.
Pick Wippy if you’re building a product that other companies will depend on, you need multi-tenant concurrency with proper isolation, you want model and vendor optionality, your workflows touch internal systems that don’t have clean SaaS APIs, you care about owning the orchestration layer, or you need to run the runtime inside your own cloud for compliance or strategic reasons. Also pick Wippy if your plan involves a portfolio of agents that share infrastructure like paying per runtime hour across dozens of always-on workflows gets expensive fast, and you lose the compounding advantage of a runtime you control and can optimize over time.
The ownership question is worth taking seriously. The systems you build on top of a runtime you don’t own are systems you can’t fully control, fully audit, or fully transfer. At small scale and early stage, that tradeoff is often worth making for speed. At production scale, with real clients and real compliance requirements, the tradeoff inverts.
Managed is a feature until it becomes a ceiling
Anthropic shipping CMA is good for the category. It legitimizes the idea that agents need real infrastructure and not just a clever prompt. It raises the floor for everyone and gives a lot of teams a fast, credible path from idea to working agent.
But “managed” is a feature until it becomes a ceiling. The teams we work with at Spiral Scout are usually past the demo phase. They have real systems, real compliance requirements, real customers, and a real need to own what they’re building on. For them, renting the rails doesn’t cut it. They need the runtime and the house, not the hotel.
Wippy is that runtime. Not a competitor to a managed service, but the infrastructure layer for teams who need to own the orchestration, own the data boundaries, and own the thing they’re shipping. The distinction matters more as the system matures. See our case studies for how this plays out in production across legal, supply chain, and enterprise SaaS.
Still deciding whether to own the runtime?
If you’re past the prototype stage and building something that other teams or clients will depend on, the infrastructure decision you make now shapes everything that comes after – your compliance posture, your cost model, your ability to swap models, and your clients’ trust in your data boundaries. A focused AI Readiness Audit will tell you exactly where your current stack creates risk and what the right runtime architecture looks like for your specific situation.
