Claude Managed Agents: el dilema make/buy no és de cost (i el teu CFO ho està mirant malament)

Quan Anthropic va llançar Claude Managed Agents el 8 d'abril, la reacció immediata a la premsa tècnica va ser previsible: one-stop shop, però compte amb el lock-in. Dues setmanes després, la conversa s'ha mogut poc. El patró clàssic: uns ho celebren, altres adverteixen, ningú posa números.

Hem construït el model de cost, hem executat el bake-off empíric (200 execucions entre el 14 i el 17 d'abril) i la conclusió no és la que ni nosaltres esperàvem.

Managed Agents no és car. Per a 3 dels 5 arquetips de workload que hem modelat, MCA iguala o guanya en TCO mensual davant d'un stack propi — incloent-hi amortització del setup d'enginyeria. En els altres dos perd per menys del 7%. La premsa té raó a assenyalar el lock-in. Però la decisió no és "car vs. barat". És una cosa diferent, i més important.

Aquest post és el que un CTO hauria de preguntar abans de signar l'adopció. Amb números, no amb opinió.

1. El que MCA fa bé

Acreditar el valor del producte abans de criticar el trade-off. Sense això, l'anàlisi és un hit-piece i perd autoritat.

• Sandbox gestionat: aïllament de codi i crides a eines de nivell producció sense haver de muntar Firecracker o Daytona tu mateix.
• Sessions llargues amb estat: el problema clàssic dels agents empresarials (recuperació després de fallada, continuïtat davant timeouts) resolt de sèrie.
• Permisos scoped: model RBAC natiu per tool, amb herència de polítiques a nivell d'organització.
• Tracing integrat: observabilitat sense configurar OTel+Langfuse+Grafana des de zero.
• Tool execution: execució remota amb reintents i backoff gestionats.

Per a un equip que vol agents en producció en dues setmanes i no en dos trimestres, MCA és una proposta real. No és fum.

El model de cost que hem construït ho confirma: onboarding productiu en ~1 setmana × 1 sènior davant de ~4 setmanes × 1 sènior per aixecar un stack equivalent. A tarifes espanyoles d'enginyeria sènior fully-loaded (≈1.500 €/setmana), el setup propi costa aproximadament 6.000 € one-time. El setup de MCA, aproximadament 1.500 €.

Diferència: 4.500 € menys cash out el primer mes. En un equip pressionat per trimestres, no és irrellevant.

Fins aquí la part on donem la raó a Anthropic.

2. La dada que canvia la conversa

Hem modelat 5 arquetips de workload enterprise amb assumptions explícites. El xlsx auditable està publicat aquí perquè qualsevol CTO pugui ajustar-lo al seu cas canviant els inputs grocs. Per a cada workload: cost mensual MCA vs cost mensual stack propi, tots dos incloent-hi amortització del setup inicial a 24 mesos.

Primera sorpresa. MCA guanya o empata en 3 dels 5 workloads modelats i, quan perd, ho fa per marges petits (<7%). En monitor autònom 24/7 guanya per golejada (−37,6%): el cost fix de tenir un stack propi funcionant tot el dia per a només 5 agents no s'amortitza amb un volum tan petit. En extracció documental guanya −3,3%, en copilot dev queda empat tècnic (+0,4%), i només en chatbot i batch nocturn self-hosted surt per davant — per 6,2% i 2,9% respectivament. En valor absolut, la diferència màxima mensual en els workloads on MCA perd no arriba als 500 €.

Per què? Perquè en un desplegament real d'agents enterprise, el cost de model (tokens) domina el TCO. I els tokens es paguen igual des de dins de MCA que des de fora — Anthropic no descompta per fer servir la seva orquestració, i tampoc subvenciona el fee d'agent-hour amb tokens més cars. El fee de $0,08/hora de MCA representa entre el 6% i el 14% del cost total per a workloads d'alta concurrència, i fins a un 88% per a workloads sempre actius de baixa concurrència. En termes absoluts, es tracta de xifres modestes davant de la factura de tokens.

Si la història fos només "MCA és car pel fee", aquí acabem: el post seria "depèn del patró d'ús, al marge". Però la història és una altra.

3. El cost que ningú mira: l'exit cost

L'estalvi de setup de MCA no és gratis. Es paga en cost de sortida.

Quan adoptes MCA, el teu codi no és portable sense fricció. L'orquestració fa servir convencions d'Anthropic, el tracing viu en el format d'Anthropic, els tool contracts segueixen el seu SDK, i la teva facturació/metering està instrumentada amb els senyals de MCA. Si en 18 mesos decideixes que vols operar multi-model, que OpenAI o Mistral treuen un model que serveix millor per al teu cas, que la teva auditoria interna exigeix telemetria estàndard OpenTelemetry per a compliment, o simplement que Anthropic apuja preus — migrar fora té un cost quantificable.

Hem modelat aquest cost per a tres arquetips de workload. Cada component és una línia de treball d'enginyeria real, no un buffer.

Per a un workload cara al client, migrar fora de MCA representa un trimestre complet d'un enginyer sènior. Al voltant de 16.500 € en costos de personal, més el risc operacional del cutover. I això assumint que ja tens a casa el coneixement per construir l'alternativa — si no el tens, cal sumar-li altres 6.000 € d'aixecament del stack equivalent.

La pregunta canvia de forma. No és "és MCA car?" — no ho és. La pregunta real és:

Quina probabilitat assigno en els pròxims 24 mesos a voler migrar fora de MCA? Si és més gran que X%, l'exit cost domina la meva decisió.

On X és, segons workload, entre el 20% i el 40%.

I aquí ve la part incòmoda: la probabilitat de voler migrar en 24 mesos no és baixa. Passen coses com (a) que el model líder canviï, (b) que auditoria/legal canviï els requisits, (c) que et fusionis amb una empresa que ja té stack, (d) que Anthropic apugi preus, (e) que un nou framework open source tregui 2x rendiment.

Qui adopta MCA està, sense verbalitzar-ho, apostant contra totes aquestes coses juntes. A un CFO li solen demanar que s'ho pensi molt abans de fer aquest tipus d'apostes.

4. Les 4 preguntes del make-or-buy

Amb els números al davant, el framework de decisió es torna net. Les quatre preguntes que el CTO hauria de contestar abans de signar:

Dos o més "no" en aquestes quatre preguntes i MCA té sentit. Dos o més "sí" i l'economia de l'exit cost entra en joc.

Lectura relacionada: a SDD + Agentic Orchestration desenvolupem l'arquitectura que separa la capa de política (SDD) de la capa d'execució (MCA, LangGraph o desplegament propi), precisament perquè l'exit cost no t'ati.

5. L'opció híbrida — la més realista

La majoria dels CTOs amb qui conversem no estan triant tot-MCA o res-MCA. Estan fent híbrid sense verbalitzar-ho:

• MCA per al 20% de workloads exploratoris, no crítics, sense PII — pilots, prototips, automatitzacions internes baixes.
• Stack propi per al 80% crític — workloads cara al client, amb dades regulades, amb concurrència alta, o on l'equip vol mantenir multi-model.

Regles d'enrutament que hem vist funcionar:

Aquesta és, de fet, la conclusió més útil de l'anàlisi: no hi ha una decisió única. Hi ha una política d'enrutament que cal escriure explícitament abans que algú de l'equip prengui la decisió implícitament per tu.

6. Bake-off empíric: els números

El model de TCO respon al "quant costa". La següent pregunta legítima del CTO és: "rendeix igual?". Per contestar-la hem executat un bake-off empíric entre el 14 i el 17 d'abril: MCA vs stack propi (LangGraph + Temporal + Daytona + OpenTelemetry/Langfuse) sobre la mateixa tasca — extracció estructurada de dades de 20 PDFs heterogenis enterprise (8 factures, 6 contractes, 6 fitxes tècniques), 5 corregudes per document, 200 execucions totals. Mateix model (Claude Sonnet 4.6), mateixes 4 tools (read_pdf, ocr_pdf, validate_schema, write_postgres), mateix sistema prompt paraula per paraula.

Criteri d'equivalència: un observador extern no hauria de poder distingir inputs/outputs entre totes dues implementacions. Només canvia la capa d'orquestració.

Lectura honesta de les dades. MCA és un 14% més car per 100 documents executats — però estem parlant de 0,17 € més per cada 100 docs. Per a aquest workload, la diferència és immaterial davant de la factura mensual de tokens. La latència p95 és 31% menor en MCA (menys cold starts de sandbox), que sí que importa en experiència d'usuari quan l'agent és cara al client. La reliability convergeix gairebé idèntica — totes dues implementacions creuen el 93% en pass@5, la qual cosa confirma que la capa d'orquestració no és el coll d'ampolla de qualitat; ho és el model i la spec del tool calling.

La dada més rellevant és l'última: 168 hores en el stack propi vs 42 hores en MCA per arribar a un agent equivalent funcionant en staging. Quatre vegades més esforç en enginyeria. Per a l'equip que arrenca en fred, l'estalvi de setup no és marginal — és la diferència entre entregar en dues setmanes o en dos mesos.

Què va fallar en el stack propi: 9 hores perdudes en una race condition del cutover entre Daytona i Temporal quan el sandbox caducava abans del checkpoint. Es va resoldre amb un heartbeat explícit al workflow. En MCA la mateixa situació la gestiona el servei sense intervenció — un dels costos ocults que no es veu fins a producció.

Què va fallar en MCA: 2 documents van generar context overflow en sessions llargues que la capa de resum no va comprimir prou. El stack propi, amb Langfuse com a trace, va permetre inspeccionar el log complet i ajustar l'estratègia de context en 30 minuts. En MCA vam haver de treballar amb el tracing d'Anthropic — menys granular per a debugging avançat i va requerir dues iteracions. L'observabilitat és un trade-off real, no imaginat.

Lectura operativa. Si el teu workload s'assembla a extracció documental (1-3 min per execució, sessions mitjanes, volum mitjà), els resultats empírics confirmen el model: MCA és pràcticament equivalent en cost marginal i rendiment, i substancialment més barat en esforç d'enginyeria. L'exit cost continua sent el factor dominant a 24 mesos — però no perquè MCA rendeixi pitjor: perquè adoptar-lo t'ata a una capa la migració de la qual costa trimestres, encara que avui et funcioni.

Compromís editorial complert: els resultats afavoreixen parcialment MCA (latència, esforç) i parcialment el stack propi (cost marginal, observabilitat). Es publiquen tal com són. Anthropic no ha vist aquest post abans de la publicació; el dataset està anonimitzat i el codi de totes dues implementacions és MIT — qualsevol pot replicar l'anàlisi.

7. Recomanació operativa

Si vas a decidir sobre MCA aquest trimestre, aquests són els tres passos que recomanem, en ordre:

Tancament

Managed Agents és una bona solució a un problema real. El seu preu mensual és raonable. El seu estalvi de setup és real. Però la discussió pública s'ha quedat en car vs. barat — i el factor que més pesa en la decisió, quan fas el model, és l'exit cost: un cost silenciós que ningú està mesurant i que decideix make vs buy amb més pes que el fee mensual.

A onext pensem que el rol d'un IA partner el 2026 no és vendre la solució d'un proveïdor. És ajudar el seu client a veure la dada completa abans de signar.