Managed Agents, LangGraph o tu propio bucle: quién ejecuta tu runtime de agentes en producción
Si estás poniendo agentes de IA en producción en 2026, la pregunta que más tiempo te va a ahorrar responder bien no es "¿LangGraph o CrewAI?". Es una capa más abajo: ¿quién ejecuta el bucle? Es decir, dónde vive el loop que llama al modelo, ejecuta herramientas, guarda estado y se recupera de un fallo. Hay tres respuestas honestas —un runtime gestionado por el proveedor, un runtime que hospedas tú, o un bucle que escribes y operas tú mismo— y la mayoría de equipos elige mal porque compara features en vez de comparar quién carga con la operación.
Respuesta corta, para que puedas seguir leyendo con criterio: si tu caso es Claude-only y quieres tiempo-a-producción por encima de todo, un runtime gestionado te quita meses de fontanería. Si necesitas mezclar proveedores de modelo, controlar el grafo de ejecución o cumplir requisitos de residencia de datos, un runtime self-hosted te da ese control sin reescribir el bucle desde cero. Y si tu agente es simple y el estado cabe en tu backend actual, tu propio bucle sigue siendo una opción perfectamente seria —no un pecado.
Vamos a los tres caminos, con números verificables y, sobre todo, con el "cuándo NO".
La decisión real no es "qué framework"
Un agente en producción necesita resolver cinco cosas aburridas: el bucle (llamar al modelo, parsear la respuesta, ejecutar herramientas, repetir), un sandbox para ejecutar código y herramientas con seguridad, estado durable (sesiones que sobreviven a un reinicio o a una pausa de horas), permisos y credenciales (qué puede tocar el agente y con qué identidad), y observabilidad (trazas de qué hizo y por qué). El framework de orquestación resuelve el primer punto y parte del tercero. Los otros —sandbox, credenciales, trazas, escalado— son infraestructura, y son exactamente donde los proyectos se atascan cuando pasan del prototipo al tráfico real.
Por eso la elección correcta se decide por operación, no por benchmark. Quien va a llevar guardias sobre ese agente a las tres de la mañana debería tener voto en esta decisión.
Camino 1: runtime gestionado (Claude Managed Agents)
Qué es. Claude Managed Agents, en beta pública desde el 8 de abril de 2026, empaqueta el harness de agente de Anthropic con la infraestructura de producción alrededor: ejecución de código en sandbox, sesiones largas que se reanudan limpiamente tras una pausa, checkpointing, un almacén de credenciales, ejecución programada, soporte de MCP e integración de herramientas (búsqueda web, browser). El estado —historial, estado del sandbox, salidas— vive en el servidor. La coordinación multi-agente está en research preview.
Precio. Tarifas de token estándar de la plataforma más 0,08 $ por hora de sesión activa. Es consumo puro: no pagas por infraestructura ociosa, pero una flota de agentes de larga duración suma esas horas-sesión rápido. Modela el coste con tu volumen real antes de comprometerte.
Cuándo sí. Cuando tu trabajo está centrado en Claude, cuando quieres pasar de prototipo a algo desplegado en días y no en meses, y cuando prefieres comprar la gestión de contenedores, sesiones y credenciales antes que construirla. Para un equipo de producto pequeño que quiere un agente fiable sin montar un equipo de plataforma, es la vía más corta.
Cuándo NO. Tres frenos concretos. Primero, lock-in de modelo: el runtime está atado a Claude; si tu arquitectura necesita rutear pasos baratos a otro proveedor o mantener un modelo open-weight self-hosted por coste o soberanía, este camino te lo cierra. Segundo, estás en beta: a fecha de hoy no hay cobertura de Zero Data Retention ni BAA de HIPAA, así que para cargas reguladas de salud o datos especialmente sensibles todavía no es tu sitio. Tercero, control del grafo: si necesitas topologías multi-agente muy específicas o lógica de ejecución a medida, un harness gestionado te da menos hilos que tocar.
Camino 2: runtime self-hosted (LangGraph y similares)
Qué es. LangGraph es hoy el runtime de orquestación con más kilómetros de producción: v1.0 a finales de 2025, v1.2.4 en junio de 2026, y despliegues en Uber, LinkedIn, Klarna, JP Morgan, BlackRock y Cisco. Klarna reportó una reducción del 80% en tiempo de resolución; Uber, un ahorro de ~21.000 horas de desarrollo. Su núcleo es la ejecución durable con checkpointing: guarda estado en cada nodo (con backend Postgres o SQLite), así que un agente puede caerse, reanudar e incluso rebobinar. El sistema de deltas guarda solo lo que cambió, no el estado completo.
Lo que te da que el gestionado no. Es model-agnostic: puedes rutear pasos a modelos baratos de cualquier proveedor, o a un modelo open-weight que hospedas tú. Y controlas el despliegue: Docker para tooling interno de bajo volumen, Kubernetes con autoescalado para cargas paralelas y a ráfagas, o serverless en Cloud Run / Lambda para flujos asíncronos dirigidos por eventos. Self-hostear el runtime es gratis; pagas la infra que consume.
Cuándo sí. Cuando necesitas control explícito del grafo de ejecución, estado durable con checkpoints propios, topologías multi-agente a medida, o la libertad de mezclar proveedores de modelo. Cuando la residencia de datos en la UE o un requisito regulatorio te obliga a que el estado y la inferencia vivan donde tú decides. Si ya operas backend en Go sobre Cloud Run o GKE, este camino encaja con infra que ya sabes explotar.
Cuándo NO. Un runtime self-hosted es un servicio de producción más: tú cargas con el Postgres de checkpoints, el escalado, los parches de seguridad y las guardias. Si tu equipo no tiene músculo de plataforma —o no quiere adquirirlo para un solo agente—, esa operación se convierte en deuda. El framework no elimina el trabajo de infra; decide quién lo hace.
Camino 3: tu propio bucle (Agent SDK o un while honesto)
Qué es. Un bucle que escribes tú: llamada al modelo, parseo, ejecución de herramientas, repetición, sobre tu propio backend. Puedes apoyarte en un SDK de agente (como el Claude Agent SDK) para no reimplementar el manejo de tool-calls, y aun así ser tú quien decide dónde vive el estado y cómo se observa.
Cuándo sí. Cuando el agente es acotado —pocas herramientas, horizonte corto, estado que cabe en tu base de datos actual— y montar (u operar) un runtime completo es sobreingeniería. Un while bien escrito con tu observabilidad de siempre es más fácil de razonar, depurar y auditar que un grafo que casi nadie del equipo entiende del todo. La simplicidad es una feature.
Cuándo NO. En cuanto necesitas sesiones que sobreviven horas, reanudación tras fallo, ejecución en sandbox aislado o coordinación entre varios agentes, estarás reconstruyendo —peor y más despacio— lo que los dos caminos anteriores ya te dan. Reconocer ese punto de inflexión a tiempo es media batalla.
Comparativa rápida
| Criterio | Runtime gestionado (Claude Managed Agents) | Runtime self-hosted (LangGraph) | Tu propio bucle |
|---|---|---|---|
| Quién opera el bucle | El proveedor | Tú (sobre tu infra) | Tú (sobre tu backend) |
| Proveedor de modelo | Claude-only | Model-agnostic | El que integres |
| Estado durable / reanudación | Incluido, server-side | Checkpointing propio (Postgres/SQLite) | Lo montas tú |
| Sandbox de ejecución | Incluido | Tú lo provees | Tú lo provees |
| Residencia de datos UE | Limitada (beta, sin ZDR/HIPAA aún) | Tú decides dónde vive todo | Tú decides |
| Coste | Tokens + 0,08 $/hora-sesión | Infra que consumes | Infra que consumes |
| Time-to-production | El más rápido | Medio | Rápido si el caso es simple |
| Carga operativa | Mínima | Alta | Baja-media |
Cómo lo decidimos nosotros
En Dribba llevamos desde 2011 poniendo software en producción, con equipo 100% senior in-house y más de 300 proyectos en 20+ países; cuando arrancamos la conversación de agentes con un cliente, no empezamos por el framework. Empezamos por cinco preguntas:
- ¿El caso es Claude-only o necesitas varios proveedores? Si de verdad es Claude-only y no lo será por política de coste o soberanía, el runtime gestionado deja de ser una comodidad y pasa a ser la opción por defecto.
- ¿Dónde tiene que vivir el estado? Si hay residencia de datos UE o un requisito regulatorio, self-hosted gana antes de mirar nada más.
- ¿Cuánto dura una sesión y cuánto importa reanudarla? Horizontes largos con reanudación empujan hacia gestionado o LangGraph; horizontes cortos abren la puerta a tu propio bucle.
- ¿Tienes músculo de plataforma para operar un runtime? Si la respuesta es "no, y no queremos contratarlo para esto", pagar 0,08 $/hora-sesión suele salir más barato que una guardia.
- ¿Cómo vas a evaluarlo? Da igual el camino: sin evals de verdad, no "vibes", no sabrás si el cambio de runtime mejoró o empeoró el agente.
Fíjate en que ninguna pregunta es "¿cuál salió mejor en el benchmark?". El benchmark de un modelo no te dice nada sobre quién lleva las guardias de tu runtime.
El error más común
El patrón que más repetimos corrigiendo: elegir el camino por hype —el anuncio más reciente, el framework con más estrellas en GitHub— en vez de por operación. Un runtime gestionado brillante que te ata a un proveedor con el que no querías casarte es una mala decisión aunque la demo fuera impecable. Un LangGraph con checkpointing durable es infraestructura muerta si nadie del equipo va a mantener ese Postgres. Y un bucle propio "para no depender de nadie" es una trampa en cuanto el agente necesita sobrevivir a un reinicio.
La capa de agentes cambia rápido —MCP, protocolos como A2A, nuevos harness cada trimestre— pero la pregunta de fondo es estable: quién carga con la operación decide el camino, no al revés. Elige por eso y podrás cambiar de modelo o de framework más adelante sin rehacer los cimientos.
En resumen
No hay un ganador universal. Runtime gestionado si es Claude-only y quieres velocidad sin equipo de plataforma; self-hosted si necesitas control del grafo, mezcla de proveedores o residencia de datos; tu propio bucle si el caso es simple y honesto. La decisión se toma por operación y por dónde vive el estado, no por el benchmark de turno.
Si estás en ese punto —agente funcionando en un prototipo, dudas sobre cómo llevarlo a producción sin montar un equipo de plataforma entero— es justo el tipo de decisión que resolvemos con equipos que ya operan MCP y agentes en producción. Si quieres una segunda opinión senior sobre tu arquitectura de agentes, hablemos.
