¿Qué es una plataforma de runtime de agentes?
En 2026, AWS, Anthropic y Microsoft lanzaron productos con "agent runtime" en el nombre. Lo que significa la categoría en realidad, y por qué les importa a los equipos que construyen encima.
🚨 2026, el año en que "agent runtime" se volvió una categoría
En cuestión de meses, tres de los mayores proveedores de infraestructura del planeta sacaron productos con la misma palabra en el nombre:
- AWS Bedrock AgentCore: «runtime gestionado para agentes autónomos»
- Anthropic Claude Managed Agents: «agentes que corren en nuestra infraestructura»
- Microsoft Agent Framework: «runtime para agentes empresariales en Azure»
Tres proveedores distintos. El mismo vocabulario. Y ninguno se tomó la molestia de definir la categoría.
Mientras tanto, en el terreno, los builders siguen mezclando cinco cosas distintas bajo la etiqueta «plataforma de agentes»: un gateway LLM, una biblioteca de prompts, un framework, un workflow builder y un runtime. En una diapositiva se parecen. No son el mismo producto y no son intercambiables.
Este artículo es la definición que me habría gustado leer antes de ponerme a construir Appstrate. Es la respuesta a una pregunta muy concreta:
Cuando dices "agent runtime platform", ¿de qué hablas exactamente?
🤯 El problema: cinco productos haciéndose pasar por uno
Dejemos los buzzwords a un lado y miremos qué hace cada herramienta:
| Categoría | Qué es | Ejemplo |
|---|---|---|
| Gateway LLM | Un proxy delante de las APIs de modelos. Añade caché, rate-limit, observabilidad. | OpenRouter, LiteLLM, Portkey |
| Biblioteca de prompts | Un almacén versionado de prompts con UI para probarlos. | Humanloop, PromptLayer |
| Framework de agentes | Una biblioteca de código para cablear tool calls dentro de tu proceso. | LangChain, LangGraph, CrewAI, AutoGen |
| Workflow builder | Un grafo visual de pasos deterministas, disparados por eventos. | n8n, Zapier, Make |
| Agent runtime platform | Infraestructura que ejecuta agentes como procesos aislados, con estado y multi-tenant. | Bedrock AgentCore, Claude Managed, Appstrate |
Las cuatro primeras llevan años en el mercado. La quinta es nueva, y es la que la ola de 2026 está llevando al mainstream.
La distinción importa porque los runtimes de agentes resuelven un problema distinto. No te ayudan a escribir el agente: lo ejecutan por ti, de forma segura, a través de usuarios, sesiones y cuentas, con todo lo que un sistema de producción necesita y que un framework se niega a darte. Aislamiento, credenciales, auditoría, estado, scheduling, multi-tenant, rate-limiting, observabilidad.
🧱 La definición
Una agent runtime platform es la infraestructura que ejecuta agentes como procesos sandboxed, con estado y multi-tenant, y los expone a través de una API.
Hay cuatro palabras que cargan con todo el peso de esa frase:
1. Proceso, no prompt
Una llamada a un framework no tiene estado. Le pasas un prompt, recibes tokens, listo.
Un runtime ejecuta un proceso. El agente tiene filesystem, herramientas, memoria, un directorio de trabajo, un exit code, logs. Puede generar un PDF, ejecutar SQL, llamar a una API, reintentar o reanudar. Se parece mucho más a una Cloud Function que a un chat completion.
2. Sandboxed
El proceso corre en un entorno aislado: típicamente un container, una microVM o un V8 isolate. El agente no puede llegar a tu base de datos de producción, a los datos de otros usuarios ni a tus variables de entorno, salvo que el runtime lo permita explícitamente.
Esto es lo más importante que un runtime aporta y que un framework no puede darte. Cuando tu agente es solo una función en tu servidor Node.js, const result = await agent.run(prompt) está a una inyección de prompt de distancia de DROP TABLE users.
3. Con estado
Los agentes no viven el lapso de una sola llamada. Corren a lo largo de sesiones, recuerdan lo que hicieron la vez pasada y retoman donde se quedaron. Un runtime persiste ese estado por ti: como parte del registro del run, como memoria por usuario, como log de auditoría.
4. Multi-tenant
El runtime se diseña desde el día uno alrededor de organizaciones, usuarios, claves API, permisos, cuotas e impersonación. No como un añadido de último minuto. Porque el día que mandas un agente a más de una persona, necesitas todo eso, y enchufar multi-tenancy a posteriori sobre un framework single-tenant es la receta clásica para publicar CVEs.
🏗️ Anatomía de un runtime
Toda agent runtime platform de 2026, propietaria u open-source, tiene las mismas cuatro piezas móviles. Solo cambian los detalles de implementación.
┌─────────────────────────────────────────────────────────────┐
│ Agent Runtime Platform │
│ │
│ ┌──────────────┐ │
│ │ API HTTP/SDK│ POST /runs, GET /runs/:id, webhooks… │
│ └──────┬───────┘ │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ Validación │ Valida el esquema, inyecta contexto, │
│ │ entrada │ resuelve credenciales, aplica cuotas │
│ └──────┬───────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Sandbox (uno por run) │ │
│ │ │ │
│ │ Proceso agente ←→ Filesystem │ │
│ │ ↕ │ │
│ │ Herramientas Memoria │ │
│ │ ↕ ↕ │ │
│ │ Provider LLM Estado del run anterior │ │
│ │ ↕ │ │
│ │ Solicitudes salientes vía credential broker │ │
│ └───────────────────────┬─────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ Validación │ Valida el esquema, │
│ │ salida │ persiste estado, loguea │
│ └──────┬───────┘ │
│ │ │
│ ▼ │
│ Stream SSE + webhook + registro auditoría │
└─────────────────────────────────────────────────────────────┘Validación de entrada. La API acepta la solicitud de run, verifica que el agente existe, valida la entrada contra un JSON schema, resuelve credenciales a partir de las conexiones del usuario que llama, aplica rate limits y rechaza el run si algo no cuadra.
Sandbox. Se levanta un entorno fresco y aislado para el run. El agente tiene su propio filesystem, puede invocar herramientas registradas y habla con uno o varios providers LLM a través de un credential broker. No puede llegar a la red del host, a otros runs ni a credenciales en claro.
Memoria y estado. Entre runs, el runtime persiste dos cosas distintas. El estado es lo que el agente devolvió de forma explícita («47 facturas procesadas, último ID = 983»). La memoria es almacenamiento clave-valor con scope por usuario, aplicación u organización. Ambos se reinyectan en el prompt del run siguiente.
Validación de salida. Antes de marcar el run como terminado, la salida se valida contra el schema declarado. Se registra el evento, se dispara el webhook, se cierra el stream SSE del llamador.
El runtime posee el proceso que envuelve al agente. El autor del agente posee el prompt y las herramientas. Esa es la división.
⚖️ Runtime vs Framework vs Workflow builder
Estos tres son los que más se confunden. La forma más clara de distinguirlos es preguntarse: ¿dónde se ejecuta el código y quién es dueño del proceso?
| Framework (LangChain) | Workflow builder (n8n) | Runtime platform (Appstrate, Bedrock) | |
|---|---|---|---|
| Dónde corre el agente | Dentro del proceso de tu app | En el servidor del builder | En un sandbox aislado que gestiona el runtime |
| Quién gestiona el aislamiento | Tú | No hay aislamiento (proceso compartido) | El runtime (Docker / microVM) |
| Quién gestiona credenciales | Tú | Env vars del servidor | Un credential broker que el agente no puede leer |
| Multi-tenancy | La construyes tú | Workspaces, limitados | First-class: orgs / apps / end-users |
| Estado entre runs | Lo construyes tú | Variables por workflow | Memoria + estado, persistidos y con scope |
| ¿Determinista? | Sí, si lo escribes así | Sí (grafo de pasos) | No, lo decide el LLM |
| Lo que envías | Código | Un grafo JSON | Un agent package (prompt + schema + herramientas) |
Un framework es una caja de herramientas. Un workflow builder es un editor visual de procedimientos. Un runtime es el lugar donde los agentes van a vivir.
Si tu agente tiene que correr para un usuario, una sola vez, en tu laptop, elige un framework. Si tiene que correr los mismos cinco pasos cada martes contra una misma cuenta, elige un workflow builder. Si tiene que correr en nombre de cientos de usuarios, con sus credenciales, en producción, con audit trail y SLA, lo que quieres es un runtime.
🚀 Por qué importa en 2026
Hay tres cosas que convergieron este año y que vuelven inevitable la categoría runtime:
1. Los agentes salieron del prototipo. Claude Code, OpenClaw y Antigravity convirtieron a los agentes de código autónomos en herramienta diaria. Las empresas ahora quieren ese mismo comportamiento para reconciliación de facturas, triage de soporte y ops de marketing, corriendo sobre sus datos y con sus credenciales. Eso es una carga de producción, no un prototipo. Y necesita infraestructura de producción.
2. Los LLMs se volvieron lo bastante capaces como para ser peligrosos. Un agente Claude 4.x con acceso al filesystem y un prompt mal escrito puede borrarte un directorio entero. Un agente GPT-5 con tu token OAuth de Gmail y un correo envenenado en la bandeja puede mandar tus facturas a un competidor. La inyección de prompt dejó de ser teórica, y la única defensa que realmente funciona es ejecutar el agente dentro de un sandbox que no pueda alcanzar aquello a lo que no debería llegar.
3. La IA multi-tenant es más difícil de lo que la gente cree. Cada SaaS builder que intentó dejar que sus usuarios conectaran Gmail y corrieran un agente descubrió lo mismo: almacenar tokens es apenas el 5 % del trabajo. Hace falta aislamiento por usuario, impersonación para soporte, rate limits por org, auditoría para compliance, webhooks para async e idempotencia para reintentos. El runtime es la pieza que empaqueta todo eso para que no lo construyas siete veces.
Se pueden construir las tres cosas a mano, sobre un framework. Lo intentamos. Lleva un año.
🔓 El caso open-source
La versión honesta: AWS Bedrock AgentCore, Claude Managed Agents y Microsoft Agent Framework son productos bien diseñados. También son plataformas cerradas con los trade-offs esperables. Corres en su infraestructura, con sus modelos, en sus regiones y bajo su pricing. Para muchos equipos ese trato está bien. Para un número creciente, no.
Los equipos que no pueden o no quieren usar un runtime gestionado comparten un puñado de restricciones:
- Residencia de datos. UE, salud, banca, defensa. Los datos no salen del edificio.
- Libertad de modelo. BYOM: Claude hoy, Gemini mañana, un modelo local para las cargas sensibles.
- Control de costos. Correr agentes a escala sobre infra gestionada suma un margen encima del margen del LLM encima del margen del compute. A cierto volumen, las cuentas dejan de cerrar.
- Embeber en el propio producto. SaaS builders que quieren enviar agentes a sus propios usuarios, con su marca y su auth, no una consola de Bedrock.
El runtime de agentes open-source es la respuesta a esas restricciones. Misma arquitectura (sandbox, credential broker, multi-tenant, API), con la infraestructura que eliges, los modelos que eliges y una licencia que se puede leer.
Eso es lo que construimos con Appstrate. Instalación en una línea, Apache 2.0 (compatible con MIT), el mismo binario en un laptop o en un datacenter air-gapped, una API de 191 endpoints, con end-users y webhooks incluidos. La doc de arquitectura es la prueba.
📚 Relacionado
Otros artículos
- Por qué los agentes personales filtran credenciales: el lado sandbox de la anatomía.
- Tus agentes, tu infraestructura: el caso a favor de runtimes auto-alojados.
- Claude Code para equipos: qué cambia cuando los agentes son multi-tenant.
- El panorama de runtimes de agentes en 2026: una comparación sin florituras de los cinco jugadores.
Documentación de Appstrate
- Conceptos: la arquitectura de Appstrate al completo.
- Compare: la tabla comparativa, con filas que no entraron aquí.
- Quickstart: tu primer run en cinco minutos.