Claude Managed Agents: el dilema make/buy no es de coste (y tu CFO lo está mirando mal)

Cuando Anthropic lanzó Claude Managed Agents el 8 de abril, la reacción inmediata en la prensa técnica fue previsible: one-stop shop, pero ojo con el lock-in. Dos semanas después, la conversación se ha movido poco. El patrón clásico: unos lo celebran, otros advierten, nadie pone números.

Hemos construido el modelo de coste, hemos ejecutado el bake-off empírico (200 ejecuciones entre el 14 y el 17 de abril) y la conclusión no es la que ni nosotros esperábamos.

Managed Agents no es caro. Para 3 de los 5 arquetipos de workload que hemos modelado, MCA iguala o gana en TCO mensual frente a un stack propio — incluyendo amortización del setup de ingeniería. En los otros dos pierde por menos del 7%. La prensa tiene razón en señalar el lock-in. Pero la decisión no es "caro vs. barato". Es algo distinto, y más importante.

Este post es lo que un CTO debería preguntar antes de firmar la adopción. Con números, no con opinión.

1. Lo que MCA hace bien

Acreditar el valor del producto antes de criticar el trade-off. Sin esto, el análisis es un hit-piece y pierde autoridad.

• Sandbox gestionado: aislamiento de código y llamadas a herramientas de nivel producción sin tener que montar Firecracker o Daytona tú mismo.
• Sesiones largas con estado: el problema clásico de los agentes empresariales (recuperación tras fallo, continuidad ante timeouts) resuelto de serie.
• Permisos scoped: modelo RBAC nativo por tool, con herencia de políticas a nivel organización.
• Tracing integrado: observabilidad sin configurar OTel+Langfuse+Grafana desde cero.
• Tool execution: ejecución remota con reintentos y backoff gestionados.

Para un equipo que quiere agentes en producción en dos semanas y no en dos trimestres, MCA es una propuesta real. No es humo.

El modelo de coste que hemos construido lo confirma: onboarding productivo en ~1 semana × 1 senior frente a ~4 semanas × 1 senior para levantar un stack equivalente. A tarifas españolas de ingeniería senior fully-loaded (≈1.500 €/semana), el setup propio cuesta aproximadamente 6.000 € one-time. El setup de MCA, aproximadamente 1.500 €.

Diferencia: 4.500 € menos cash out el primer mes. En un equipo presionado por trimestres, no es irrelevante.

Hasta aquí la parte donde damos la razón a Anthropic.

2. El dato que cambia la conversación

Hemos modelado 5 arquetipos de workload enterprise con assumptions explícitas. El xlsx auditable está publicado aquí para que cualquier CTO pueda ajustarlo a su caso cambiando los inputs amarillos. Para cada workload: coste mensual MCA vs coste mensual stack propio, ambos incluyendo amortización del setup inicial a 24 meses.

Primera sorpresa. MCA gana o empata en 3 de los 5 workloads modelados y, cuando pierde, lo hace por márgenes pequeños (<7%). En monitor autónomo 24/7 gana por goleada (−37,6%): el coste fijo de tener un stack propio funcionando todo el día para solo 5 agentes no se amortiza con un volumen tan pequeño. En extracción documental gana −3,3%, en copiloto dev queda empate técnico (+0,4%), y solo en chatbot y batch nocturno self-hosted sale por delante — por 6,2% y 2,9% respectivamente. En valor absoluto, la diferencia máxima mensual en los workloads donde MCA pierde no llega a los 500 €.

¿Por qué? Porque en un despliegue real de agentes enterprise, el coste de modelo (tokens) domina el TCO. Y los tokens se pagan igual desde dentro de MCA que desde fuera — Anthropic no descuenta por usar su orquestación, y tampoco subvenciona el fee de agent-hour con tokens más caros. El fee de $0,08/hora de MCA representa entre el 6% y el 14% del coste total para workloads de alta concurrencia, y hasta un 88% para workloads siempre activos de baja concurrencia. En términos absolutos, se trata de cifras modestas frente a la factura de tokens.

Si la historia fuera solo "MCA es caro por el fee", aquí terminamos: el post sería "depende del patrón de uso, en el margen". Pero la historia es otra.

3. El coste que nadie mira: el exit cost

El ahorro de setup de MCA no es gratis. Se paga en coste de salida.

Cuando adoptas MCA, tu código no es portable sin fricción. La orquestación usa convenciones de Anthropic, el tracing vive en el formato de Anthropic, los tool contracts siguen su SDK, y tu facturación/metering está instrumentada con las señales de MCA. Si en 18 meses decides que quieres operar multi-modelo, que OpenAI o Mistral sacan un modelo que sirve mejor para tu caso, que tu auditoría interna exige telemetría estándar OpenTelemetry para cumplimiento, o simplemente que Anthropic sube precios — migrar fuera tiene un coste cuantificable.

Hemos modelado ese coste para tres arquetipos de workload. Cada componente es una línea de trabajo de ingeniería real, no un buffer.

Para un workload cara al cliente, migrar fuera de MCA representa un trimestre completo de un ingeniero senior. Alrededor de 16.500 € en costes de personal, más el riesgo operacional del cutover. Y esto asumiendo que ya tienes en tu casa el conocimiento para construir la alternativa — si no lo tienes, hay que sumarle otros 6.000 € de levantamiento del stack equivalente.

La pregunta cambia de forma. No es "¿es MCA caro?" — no lo es. La pregunta real es:

¿Qué probabilidad asigno en los próximos 24 meses a querer migrar fuera de MCA? Si es mayor que X%, el exit cost domina mi decisión.

Donde X es, según workload, entre el 20% y el 40%.

Y aquí viene la parte incómoda: la probabilidad de querer migrar en 24 meses no es baja. Pasan cosas como (a) que el modelo líder cambie, (b) que auditoría/legal cambie los requisitos, (c) que te fusiones con una empresa que ya tiene stack, (d) que Anthropic suba precios, (e) que un nuevo framework open source saque 2x rendimiento.

Quien adopta MCA está, sin verbalizarlo, apostando contra todas esas cosas juntas. A un CFO le suelen pedir que se piense mucho antes de hacer ese tipo de apuestas.

4. Las 4 preguntas del make-or-buy

Con los números delante, el framework de decisión se vuelve limpio. Las cuatro preguntas que el CTO debería contestar antes de firmar:

Dos o más "no" en estas cuatro preguntas y MCA tiene sentido. Dos o más "sí" y la economía del exit cost entra en juego.

Lectura relacionada: en SDD + Agentic Orchestration desarrollamos la arquitectura que separa la capa de política (SDD) de la capa de ejecución (MCA, LangGraph o despliegue propio), precisamente para que el exit cost no te ate.

5. La opción híbrida — la más realista

La mayoría de los CTOs con los que conversamos no están eligiendo todo-MCA o nada-MCA. Están haciendo híbrido sin verbalizarlo:

• MCA para el 20% de workloads exploratorios, no críticos, sin PII — pilotos, prototipos, automatizaciones internas bajas.
• Stack propio para el 80% crítico — workloads cara al cliente, con datos regulados, con concurrencia alta, o donde el equipo quiere mantener multi-modelo.

Reglas de enrutamiento que hemos visto funcionar:

Esta es, de hecho, la conclusión más útil del análisis: no hay una decisión única. Hay una política de enrutamiento que hay que escribir explícitamente antes de que alguien del equipo tome la decisión implícitamente por ti.

6. Bake-off empírico: los números

El modelo de TCO responde al "cuánto cuesta". La siguiente pregunta legítima del CTO es: "¿rinde igual?". Para contestarla hemos ejecutado un bake-off empírico entre el 14 y el 17 de abril: MCA vs stack propio (LangGraph + Temporal + Daytona + OpenTelemetry/Langfuse) sobre la misma tarea — extracción estructurada de datos de 20 PDFs heterogéneos enterprise (8 facturas, 6 contratos, 6 fichas técnicas), 5 corridas por documento, 200 ejecuciones totales. Mismo modelo (Claude Sonnet 4.6), mismas 4 tools (read_pdf, ocr_pdf, validate_schema, write_postgres), mismo sistema prompt palabra por palabra.

Criterio de equivalencia: un observador externo no debería poder distinguir inputs/outputs entre ambas implementaciones. Solo cambia la capa de orquestación.

Lectura honesta de los datos. MCA es un 14% más caro por 100 documentos ejecutados — pero estamos hablando de 0,17 € más por cada 100 docs. Para este workload, la diferencia es inmaterial frente a la factura mensual de tokens. La latencia p95 es 31% menor en MCA (menos cold starts de sandbox), que sí importa en experiencia de usuario cuando el agente es cara al cliente. La reliability converge casi idéntica — ambas implementaciones cruzan el 93% en pass@5, lo que confirma que la capa de orquestación no es el cuello de botella de calidad; lo es el modelo y la spec del tool calling.

El dato más relevante es el último: 168 horas en el stack propio vs 42 horas en MCA para llegar a un agente equivalente funcionando en staging. Cuatro veces más esfuerzo en ingeniería. Para el equipo que arranca en frío, el ahorro de setup no es marginal — es la diferencia entre entregar en dos semanas o en dos meses.

Qué falló en el stack propio: 9 horas perdidas en un race condition del cutover entre Daytona y Temporal cuando el sandbox caducaba antes del checkpoint. Se resolvió con un heartbeat explícito en el workflow. En MCA la misma situación la gestiona el servicio sin intervención — uno de los costes ocultos que no se ve hasta producción.

Qué falló en MCA: 2 documentos generaron context overflow en sesiones largas que la capa de resumen no comprimió lo suficiente. El stack propio, con Langfuse como trace, permitió inspeccionar el log completo y ajustar la estrategia de contexto en 30 minutos. En MCA tuvimos que trabajar con el tracing de Anthropic — menos granular para debugging avanzado y requirió dos iteraciones. La observabilidad es un trade-off real, no imaginado.

Lectura operativa. Si tu workload se parece a extracción documental (1-3 min por ejecución, sesiones medias, volumen medio), los resultados empíricos confirman el modelo: MCA es prácticamente equivalente en coste marginal y rendimiento, y sustancialmente más barato en esfuerzo de ingeniería. El exit cost sigue siendo el factor dominante a 24 meses — pero no porque MCA rinda peor: porque adoptarlo te ata a una capa cuya migración cuesta trimestres, aunque hoy te funcione.

Compromiso editorial cumplido: los resultados favorecen parcialmente a MCA (latencia, esfuerzo) y parcialmente al stack propio (coste marginal, observabilidad). Se publican como son. Anthropic no ha visto este post antes de publicación; el dataset está anonimizado y el código de ambas implementaciones es MIT — cualquiera puede replicar el análisis.

7. Recomendación operativa

Si vas a decidir sobre MCA este trimestre, estos son los tres pasos que recomendamos, en orden:

Cierre

Managed Agents es una buena solución a un problema real. Su precio mensual es razonable. Su ahorro de setup es real. Pero la discusión pública se ha quedado en caro vs. barato — y el factor que más pesa en la decisión, cuando haces el modelo, es el exit cost: un coste silencioso que nadie está midiendo y que decide make vs buy con más peso que el fee mensual.

En onext pensamos que el rol de un IA partner en 2026 no es vender la solución de un proveedor. Es ayudar a su cliente a ver el dato completo antes de firmar.