Claude Managed Agents: the make/buy dilemma isn't about cost (and your CFO is looking at it wrong)

When Anthropic launched Claude Managed Agents on April 8, the immediate reaction in the tech press was predictable: one-stop shop, but watch out for the lock-in. Two weeks later, the conversation has moved little. The classic pattern: some celebrate it, others warn, nobody puts numbers on it.

We've built the cost model, we've run the empirical bake-off (200 executions between April 14 and 17) and the conclusion isn't the one even we expected.

Managed Agents isn't expensive. For 3 of the 5 workload archetypes we've modeled, MCA matches or wins on monthly TCO against an in-house stack — including amortization of the engineering setup. In the other two it loses by less than 7%. The press is right to flag the lock-in. But the decision isn't "expensive vs. cheap". It's something else, and more important.

This post is what a CTO should ask before signing off on adoption. With numbers, not opinion.

1. What MCA does well

Crediting the product's value before criticizing the trade-off. Without this, the analysis is a hit-piece and loses authority.

• Managed sandbox: production-grade code and tool-call isolation without having to set up Firecracker or Daytona yourself.
• Long stateful sessions: the classic problem of enterprise agents (recovery after failure, continuity through timeouts) solved out of the box.
• Scoped permissions: a native RBAC model per tool, with policy inheritance at the organization level.
• Integrated tracing: observability without configuring OTel+Langfuse+Grafana from scratch.
• Tool execution: remote execution with managed retries and backoff.

For a team that wants agents in production in two weeks and not in two quarters, MCA is a real proposition. It's not smoke.

The cost model we've built confirms it: productive onboarding in ~1 week × 1 senior versus ~4 weeks × 1 senior to stand up an equivalent stack. At Spanish fully-loaded senior engineering rates (≈€1,500/week), the in-house setup costs approximately €6,000 one-time. The MCA setup, approximately €1,500.

Difference: €4,500 less cash out in the first month. On a team pressured by quarters, that's not irrelevant.

So far, the part where we grant Anthropic the point.

2. The data point that changes the conversation

We've modeled 5 enterprise workload archetypes with explicit assumptions. The auditable xlsx is published here so any CTO can adjust it to their case by changing the yellow inputs. For each workload: monthly MCA cost vs monthly in-house stack cost, both including amortization of the initial setup over 24 months.

First surprise. MCA wins or ties in 3 of the 5 modeled workloads and, when it loses, it does so by small margins (<7%). On the autonomous 24/7 monitor it wins handily (−37.6%): the fixed cost of running an in-house stack all day for just 5 agents doesn't amortize at such a small volume. On document extraction it wins −3.3%, on dev copilot it's a technical tie (+0.4%), and only on chatbot and nightly batch does self-hosted come out ahead — by 6.2% and 2.9% respectively. In absolute terms, the maximum monthly difference in the workloads where MCA loses doesn't reach €500.

Why? Because in a real enterprise agent deployment, the model cost (tokens) dominates the TCO. And tokens are paid the same from inside MCA as from outside — Anthropic doesn't discount for using its orchestration, nor does it subsidize the agent-hour fee with more expensive tokens. MCA's $0.08/hour fee represents between 6% and 14% of the total cost for high-concurrency workloads, and up to 88% for always-on low-concurrency workloads. In absolute terms, these are modest figures against the token bill.

If the story were only "MCA is expensive because of the fee", we'd end here: the post would be "it depends on the usage pattern, at the margin". But the story is another one.

3. The cost no one looks at: the exit cost

MCA's setup saving isn't free. It's paid for in exit cost.

When you adopt MCA, your code isn't portable without friction. The orchestration uses Anthropic conventions, the tracing lives in Anthropic's format, the tool contracts follow its SDK, and your billing/metering is instrumented with MCA signals. If in 18 months you decide you want to run multi-model, that OpenAI or Mistral releases a model that serves your case better, that your internal audit requires standard OpenTelemetry telemetry for compliance, or simply that Anthropic raises prices — migrating out has a quantifiable cost.

We've modeled that cost for three workload archetypes. Each component is a line of real engineering work, not a buffer.

For a customer-facing workload, migrating out of MCA represents a full quarter of a senior engineer. Around €16,500 in personnel costs, plus the operational risk of the cutover. And this assuming you already have in-house the knowledge to build the alternative — if you don't, you have to add another €6,000 to stand up the equivalent stack.

The question changes shape. It's not "is MCA expensive?" — it isn't. The real question is:

What probability do I assign, over the next 24 months, to wanting to migrate out of MCA? If it's greater than X%, the exit cost dominates my decision.

Where X is, depending on the workload, between 20% and 40%.

And here comes the uncomfortable part: the probability of wanting to migrate in 24 months isn't low. Things happen like (a) the leading model changing, (b) audit/legal changing the requirements, (c) you merging with a company that already has a stack, (d) Anthropic raising prices, (e) a new open-source framework delivering 2x performance.

Whoever adopts MCA is, without verbalizing it, betting against all those things put together. A CFO is usually asked to think hard before making that kind of bet.

4. The 4 make-or-buy questions

With the numbers in front of you, the decision framework becomes clean. The four questions the CTO should answer before signing:

Two or more "no" answers to these four questions and MCA makes sense. Two or more "yes" and the economics of the exit cost come into play.

Related reading: in SDD + Agentic Orchestration we develop the architecture that separates the policy layer (SDD) from the execution layer (MCA, LangGraph or in-house deployment), precisely so the exit cost doesn't tie you down.

5. The hybrid option — the most realistic

Most of the CTOs we talk to aren't choosing all-MCA or no-MCA. They're going hybrid without verbalizing it:

• MCA for the 20% of exploratory workloads, non-critical, with no PII — pilots, prototypes, low-stakes internal automations.
• In-house stack for the critical 80% — customer-facing workloads, with regulated data, with high concurrency, or where the team wants to keep multi-model.

Routing rules we've seen work:

This is, in fact, the most useful conclusion of the analysis: there's no single decision. There's a routing policy you have to write explicitly before someone on the team makes the decision implicitly for you.

6. Empirical bake-off: the numbers

The TCO model answers "how much does it cost". The CTO's next legitimate question is: "does it perform the same?". To answer it we ran an empirical bake-off between April 14 and 17: MCA vs in-house stack (LangGraph + Temporal + Daytona + OpenTelemetry/Langfuse) over the same task — structured data extraction from 20 heterogeneous enterprise PDFs (8 invoices, 6 contracts, 6 spec sheets), 5 runs per document, 200 total executions. Same model (Claude Sonnet 4.6), same 4 tools (read_pdf, ocr_pdf, validate_schema, write_postgres), same system prompt word for word.

Equivalence criterion: an external observer shouldn't be able to distinguish inputs/outputs between the two implementations. Only the orchestration layer changes.

An honest read of the data. MCA is 14% more expensive per 100 documents executed — but we're talking about €0.17 more per 100 docs. For this workload, the difference is immaterial against the monthly token bill. Latency p95 is 31% lower on MCA (fewer sandbox cold starts), which does matter for user experience when the agent is customer-facing. Reliability converges almost identically — both implementations cross 93% on pass@5, which confirms that the orchestration layer isn't the quality bottleneck; the model and the tool-calling spec are.

The most relevant data point is the last one: 168 hours on the in-house stack vs 42 hours on MCA to get an equivalent agent running in staging. Four times the engineering effort. For the team starting cold, the setup saving isn't marginal — it's the difference between delivering in two weeks or in two months.

What failed in the in-house stack: 9 hours lost to a race condition in the cutover between Daytona and Temporal when the sandbox expired before the checkpoint. It was resolved with an explicit heartbeat in the workflow. In MCA the same situation is handled by the service without intervention — one of the hidden costs you don't see until production.

What failed in MCA: 2 documents generated context overflow in long sessions that the summarization layer didn't compress enough. The in-house stack, with Langfuse as the trace, allowed inspecting the full log and adjusting the context strategy in 30 minutes. In MCA we had to work with Anthropic's tracing — less granular for advanced debugging and it required two iterations. Observability is a real trade-off, not an imagined one.

Operational reading. If your workload looks like document extraction (1-3 min per execution, medium sessions, medium volume), the empirical results confirm the model: MCA is practically equivalent in marginal cost and performance, and substantially cheaper in engineering effort. The exit cost remains the dominant factor at 24 months — but not because MCA performs worse: because adopting it ties you to a layer whose migration costs quarters, even if it works for you today.

Editorial commitment kept: the results partly favor MCA (latency, effort) and partly the in-house stack (marginal cost, observability). They're published as they are. Anthropic hasn't seen this post before publication; the dataset is anonymized and the code of both implementations is MIT — anyone can replicate the analysis.

7. Operational recommendation

If you're going to decide on MCA this quarter, these are the three steps we recommend, in order:

Closing

Managed Agents is a good solution to a real problem. Its monthly price is reasonable. Its setup saving is real. But the public discussion has stayed at expensive vs. cheap — and the factor that weighs most on the decision, when you build the model, is the exit cost: a silent cost no one is measuring and that decides make vs buy with more weight than the monthly fee.

At onext we think that the role of an AI partner in 2026 isn't to sell a provider's solution. It's to help their client see the complete data before signing.