El panorama de runtimes de agentes en 2026

🗺️ Cinco plataformas, una categoría, apuestas muy distintas

Hace un año, si preguntabas «¿dónde debería correr este agente en producción?», la respuesta era encogerse de hombros. Elegías un framework, lo cableabas a tu servidor web y te encomendabas. No había categoría.

A marzo de 2026 existen cinco plataformas creíbles que se autodenominan runtimes de agentes y que más o menos quieren decir lo mismo con esa etiqueta. Resuelven el mismo problema (ejecutar un agente como un proceso sandboxed, con estado y multi-tenant), y cada una apuesta por una parte distinta del stack.

Este artículo es la comparación que me habría gustado tener cuando empezamos a construir Appstrate. No es un artículo neutral: hacemos una de las cinco. Pero la tabla refleja los trade-offs reales, y somos explícitos sobre dónde gana cada una.

📊 La tabla

	Bedrock AgentCore	Claude Managed Agents	Microsoft Agent Framework	LangGraph Cloud	Appstrate
Vendor	AWS	Anthropic	Microsoft / Azure	LangChain	Open-source
Auto-alojable	❌	❌	Parcialmente (vía Azure)	Parcialmente (vía LangGraph OSS)	✅
Licencia	Propietaria	Propietaria	Propietaria	MIT (OSS core) + cloud cerrado	Apache 2.0
BYOM	Modelos Bedrock + endpoint externo	Solo Claude (+ partners limitados)	Azure OpenAI-first + pesos abiertos	Cualquiera (es tu grafo)	Cualquiera (provider-neutral)
Sandboxing	Firecracker microVM	Sandbox propietario	Azure Container Apps	Tu infra	Docker + sidecar (Firecracker en roadmap)
Primitivas multi-tenant	Cuentas AWS / IAM	Workspaces Anthropic	Entra / Azure AD	Limitadas	Orgs + apps + end-users + impersonación
Credential broker	Mediado por IAM	Parcial	Respaldado por Key Vault	DIY	Sidecar, allowlists por provider
Scheduling	EventBridge	Limitado	Azure Logic Apps / Functions	DIY	Basado en BullMQ, first-class
Webhooks	EventBridge	Limitados	Event Grid	DIY	First-class, spec Standard Webhooks
API headless	✅	✅	✅	✅	✅ (191 endpoints)
API versionada	Por fecha	Por feature	Por fecha	Semver en el SDK	Por fecha (Appstrate-Version)
Mejor para	Equipos AWS-native	Equipos pure-Claude	Empresas Azure-native	Equipos con grafos complejos	Todos los demás

🧠 Un párrafo por jugador

Cada una de estas plataformas es una pieza seria de ingeniería. Lo que las distingue es la apuesta que hicieron sobre quién es su usuario.

AWS Bedrock AgentCore: la apuesta cloud-native

Bedrock AgentCore es el más rico en infra de los cinco. Firecracker microVMs, acceso a herramientas mediado por IAM, EventBridge para webhooks, CloudWatch para logs, KMS para las claves. Si tu stack ya está entero en AWS, AgentCore encaja y hereda los patrones operacionales que tu equipo ya domina. El reverso es el que uno espera: corres en AWS, pagas precios AWS, quedas atado a primitivas AWS, y cada historia cross-region es una historia cross-region de AWS. Perfecto para AWS shops. Inviable para los casos borde de residencia de datos y para los equipos cuyo review de seguridad considera el lock-in en un cloud como un riesgo.

Anthropic Claude Managed Agents: la apuesta model-native

Claude Managed es el camino más corto de un prompt a un agente funcionando, siempre que ese prompt sea para Claude. El runtime está afinado al tool-calling de Claude, al thinking de Claude, al computer-use de Claude, al caching de Claude. Para un equipo que ya decidió que Claude es el modelo correcto y solo quiere enviar, Claude Managed ahorra muchísimo cableado. Para un equipo que quiera evaluar otro modelo en serio, cubrirse frente a cambios de pricing o correr un fallback local, estás en la plataforma equivocada por diseño.

Microsoft Agent Framework: la apuesta enterprise-native

Lo más interesante de MSAF es que es parcialmente auto-alojable a través de sus componentes OSS, lo que lo vuelve el único runtime gestionado con una historia coherente para Azure Stack y nubes soberanas. Si tu procurement ya pasa por Microsoft Enterprise Agreements, acá hay un camino sólido. El trade-off: la experiencia completa es Azure-first, Entra-first, y el mejor tooling asume que eres una .NET shop. Si lo eres, es una opción muy limpia. Si no, quedas de segunda clase.

LangGraph Cloud: la apuesta graph-native

LangGraph Cloud es la única plataforma de las cinco cuya abstracción principal es el grafo del agente, no el agente como caja negra. Si tus agentes tienen máquinas de estado explícitas y complejas (orquestación multi-agente, human-in-the-loop, procesos long-running con checkpoints), el modelo de LangGraph es el más cercano a cómo ya piensas. El trade-off: la infraestructura que rodea al grafo corre por tu cuenta. Despliegue, multi-tenant, scheduling, auditoría. LangGraph Cloud gestiona el orquestador, no la plataforma que lo envuelve. Excelente si lo que quieres es un orquestador bien diseñado. No un reemplazo de plataforma.

Appstrate: la apuesta open-source

Appstrate es el único de los cinco que es Apache 2.0, auto-alojable por defecto y provider-neutral en cuanto a modelos. Creemos que la categoría runtime de agentes va a evolucionar como evolucionó la nube. Habrá tres o cuatro ganadores propietarios con productos gestionados sólidos, y una o dos alternativas open-source que absorberán la long tail de equipos que necesitan controlar su infraestructura. Industrias reguladas, SaaS builders embebiendo agentes, cargas sensibles al costo, despliegues soberanos, equipos que ya se quemaron una vez con el rug-pull de un vendor. Construimos para esa long tail. La apuesta: que la categoría crezca lo suficiente como para que la long tail sea un negocio real, de la misma forma en que Linux y Postgres terminaron siendo negocios reales.

🎯 Los ejes que realmente deciden

Si estás evaluando los cinco, una lista de pros y contras sirve mucho menos que una decisión tomada sobre un puñado de ejes. Acá va la versión corta.

Estrategia de modelo

Si ya te casaste con una familia de modelos y no ves eso cambiando, elige el runtime afinado a ella: Claude Managed para Claude, AgentCore para las familias de Bedrock, MSAF para Azure OpenAI. Si no te has casado con ninguno, o piensas mantener opciones abiertas, la neutralidad de modelo importa más que la afinación específica. Ahí estamos hablando de LangGraph o Appstrate.

Dónde tienen que vivir los datos

Si tus datos no pueden salir de una región concreta, de ciertos clouds o de tu propio perímetro, la pregunta deja de ser «¿qué runtime?» y pasa a ser «¿qué runtime siquiera me va a dejar correr dentro de ese perímetro?». En ese eje, Appstrate y las partes auto-alojadas de LangGraph / MSAF son el conjunto que queda. Los otros quedan fuera por diseño.

Modelo multi-tenant

Si corres agentes en nombre de tus usuarios (no solo de tu equipo), las primitivas multi-tenant pesan mucho. AWS IAM y Azure Entra son potentes, pero están diseñados para identidad empresarial, no para embeber end-users. End-users al estilo Stripe con impersonación, claves API con scope por aplicación y webhooks pensados para B2B SaaS son requisitos de producto muy específicos, y las cinco no los resuelven igual.

Tolerancia a ops

Si tu equipo tiene cero ancho de banda para ops, auto-alojar es un mal trade, por muchos argumentos OSS que haya. Elige un runtime gestionado, paga el impuesto y envía. Si tu equipo puede correr Postgres / Redis / Docker sobre Kubernetes o una flota de VMs sin despeinarse, el auto-alojamiento desbloquea ganancias de precio, soberanía y flexibilidad que las plataformas gestionadas no pueden igualar.

Comunidad y portabilidad

Las plataformas cerradas tienen excelente soporte de vendor. Lo que no tienen es una segunda implementación a la que puedas migrar sin reescribirlo todo. Código Apache 2.0 con una API interna limpia es otro tipo de seguro. No te protege de caídas, pero sí de que el vendor desaparezca, cambie de licencia o mueva el producto hacia arriba en el mercado.

🧭 Guía corta de decisión

Como la tabla de arriba es demasiado para tener en la cabeza, acá va la versión aún más corta:

• Eres AWS-native, Claude-native o Azure-native y estás a gusto: elige el runtime del vendor que te toca. El impuesto de integración es real, y las plataformas de vendor lo pagan por ti.
• Construyes agentes dentro de un despliegue regulado o soberano: Appstrate o LangGraph auto-alojado. Probablemente Appstrate si además quieres las primitivas multi-tenant.
• Construyes un SaaS que embebe agentes para tus usuarios, con tu marca y tu auth: Appstrate. El modelo end-user + impersonación + webhooks está pensado exactamente para esa forma.
• Corres grafos genuinamente complejos de agentes, con checkpoints human-in-the-loop: LangGraph. La abstracción de grafo es el diferenciador.
• Corres muchos agentes y la factura gestionada se te come el margen: auto-aloja algo. Appstrate es el trade-off más barato entre infra que tienes que correr y plataforma que tienes que construir.

🔓 Por qué apostamos por open-source

Un cierre honesto, ya que somos uno de los cinco.

Cada categoría madura de infraestructura de los últimos veinte años terminó con la misma forma. Líderes propietarios con productos excelentes (VMware, Oracle, Splunk, Datadog). Alternativas open-source que absorbieron la long tail y que, con el tiempo, fueron bajando los márgenes propietarios (KVM, Postgres, OpenTelemetry, Grafana). Las alternativas open-source no ganaron por ser mejores. Ganaron porque le dieron a los equipos un control plane propio en un mundo donde el costo de no tenerlo no paraba de subir.

Los runtimes de agentes son la próxima categoría en esa trayectoria. Y lo que está en juego es alto: estos sistemas custodian las credenciales de tus usuarios, corren sobre sus datos y toman acciones con consecuencias reales. Los equipos ya están sintiendo la necesidad de un control plane que puedan abrir, leer, forkear y correr donde quieran. Esa es la long tail para la que construimos.

Nada de esto significa que las plataformas propietarias vayan a perder. Bedrock, Claude Managed y MSAF van a ser el default para una buena parte del mercado, igual que Oracle sigue siendo el default para una buena parte de las bases de datos. Lo que sí significa es que debería existir una opción open-source creíble para la otra parte. Esa es la categoría que Appstrate intenta ocupar.

📚 Relacionado

Otros artículos

• ¿Qué es una plataforma de runtime de agentes?: la definición de categoría que hay detrás de la tabla de arriba.
• Por qué los agentes personales filtran credenciales: el eje sandboxing, en detalle.
• Tus agentes, tu infraestructura: el argumento a favor del auto-alojamiento.
• Claude Code para equipos: el eje multi-tenant, en detalle.

Documentación de Appstrate

• Compare: la versión en la doc de esta comparación, con más filas.
• Conceptos: la arquitectura completa de Appstrate.
• Quickstart: cinco minutos hasta tu primer run.