Los runtimes de agentes han convergido en la misma arquitectura y casi el mismo precio, así que la pregunta interesante ya no es cuál comprar. Es qué hace cumplir —de verdad, de forma determinista— el que ya tienes, y dónde empieza exactamente lo que te toca construir a ti.
El fallo es una decisión de presupuesto
Empecemos por dos números que no deberían poder convivir.
En Terminal-Bench 2.0, el benchmark de agentes trabajando en un terminal, los mejores sistemas rondan hoy el 84,7% de tareas resueltas. Impresionante. Ahora estira ese mismo tipo de trabajo hasta los 85 minutos y unos 231 episodios por tarea —eso mide Long-Horizon-Terminal-Bench, publicado en julio de 2026— y el mejor modelo se queda en el 15,2%. La media de los quince modelos evaluados: 4,3%.
Lo interesante no es la caída. Es la autopsia. De las ejecuciones que no llegaron a resolverse, el 79% son timeouts: el agente seguía trabajando cuando se le acabó el presupuesto. Un 19% son abandonos tempranos —el agente se rinde con la tarea incompleta— y solo un 3% son errores del arnés de pruebas.
Léelo otra vez: casi nada de eso es el modelo equivocándose. Es terminación, presupuesto y estado. Y esas tres cosas no viven en el modelo; viven en la capa de debajo.
Sobre esa capa ya hay una posición publicada que comparto: los runtimes de agentes se han convertido en una commodity, y la restricción real de los programas de agentes se ha movido al gobierno —los seis pilares de los que hablaremos al final—. Las dos cosas son ciertas y no se contradicen. El runtime es un sustrato. Este artículo va de qué hace cumplir ese sustrato exactamente, y dónde se detiene.
La commodity, dicha una vez
No voy a re-litigar la tesis; basta un párrafo. El runtime de agentes de Gemini Enterprise (Google), Bedrock AgentCore (AWS) y la infraestructura de agentes de Cloudflare han convergido en la misma forma —aislamiento por sesión, escala a cero, facturación por CPU activa— y en casi el mismo precio: 0,085 dólares por vCPU-hora en Google y 0,0895 en AWS, con la espera de entrada/salida sin facturar en ambos. Tres hyperscalers a menos de un cuatro por ciento de distancia en precio y sin diferenciarse en arquitectura: eso es una commodity.
La señal corroborante llega desde el otro lado: OpenAI anunció el 3 de junio de 2026 que retira Agent Builder y su plataforma de Evals (solo lectura desde el 31 de octubre de 2026, cierre el 30 de noviembre), dejando intactos la Responses API y el Agents SDK. La rotación está en la capa empaquetada de encima; el sustrato, mientras tanto, se consolida.
Pero una commodity no es lo mismo que un problema resuelto. La electricidad también es una commodity y aun así conviene saber dónde están los fusibles. Tienes que saber sobre qué estás de pie.
Siete primitivos, y dónde se acaba cada uno
Aquí va el corazón del artículo. Para cada primitivo del runtime, el mismo compás de tres tiempos: el mecanismo, qué hace cumplir de forma determinista, y qué no hace cumplir —y qué pilar de gobierno recoge ese resto. La distancia entre las dos últimas columnas es, exactamente, el territorio del gobierno de agentes.
1. Ejecución durable: el diario
El mecanismo: el runtime anota el resultado de cada paso en un diario y, tras un fallo, reproduce los resultados anotados en lugar de rehacer el trabajo. La regla de Temporal es que todo lo no determinista vive en Activities, que se ejecutan fuera de la ruta de replay.
Hace cumplir: que el trabajo sobreviva a caídas, despliegues y límites de tasa, y —detalle nada menor— que una llamada al LLM no se pague dos veces en silencio. Una llamada al modelo es un efecto secundario no determinista con precio; reproducirla es a la vez incorrecto y caro.
No hace cumplir: quién autorizó la ejecución. El diario es la materia prima de la atribución (pilar 1), pero un diario no es una cadena de delegación: los logs te dicen qué pasó, no quién responde por ello. ¿Y quién es dueño de eso hoy en tu organización?
2. Sesiones e hibernación: el suelo del coste
Dos formas dominan. El actor direccionable con su almacenamiento pegado —los Durable Objects de Cloudflare, donde la direccionabilidad es el enrutado persistente— y el registro más microVM: en AgentCore, una microVM por identificador de sesión, con timeout de inactividad de 900 segundos por defecto y una vida máxima dura de 8 horas. Un objeto hibernado no factura duración.
Hace cumplir: que un agente ocioso cueste casi nada. Eso es lo que hace asumibles las ejecuciones largas y las que esperan a un humano.
No hace cumplir: el gasto por responsable. El runtime mide por sesión, para su propia factura. Los recursos acotados (pilar 4) necesitan la cuenta acumulada por humano responsable: los doce agentes concurrentes de una misma persona son un solo presupuesto, y eso el runtime ni lo sabe ni le importa.
3. Aislamiento y egress: el único sitio donde se contiene una inyección
Hay cuatro niveles de aislamiento con diferencias de orden de magnitud: microVMs tipo Firecracker (~125 ms de arranque, ~3 MB de sobrecoste por máquina), kernels en espacio de usuario como gVisor, contenedores, y aislados V8 que arrancan en pocos milisegundos.
Pero el control específico de agentes no es el aislamiento: es el egress, la salida. El sandbox-runtime de Anthropic lo describe con precisión de ingeniería: lista de permitidos con denegación por defecto, HTTP a través de un proxy que valida dominios, el resto del TCP por SOCKS5, vallado a nivel de kernel para los procesos que ignoran las variables de proxy, e inyección de credenciales para que el secreto jamás entre en la ventana de contexto.
Hace cumplir: a dónde pueden ir los bytes, de forma determinista, crea lo que crea el modelo.
No hace cumplir: qué significan esos bytes. Esta es la costura exacta con la conservación de la procedencia (pilar 3): el runtime puede bloquear un destino; no puede saber que el resumen que sale deriva del data room de la operación de M&A.
Y una cura de humildad: la allowlist vale lo que valga el acuerdo entre sus parsers. El sandbox de red de Claude Code fue burlado con un byte nulo en el hostname SOCKS5: el filtro de políticas leía attacker-host.com\x00.google.com como un sufijo permitido mientras el resolutor del sistema truncaba en el byte nulo. Unas 130 versiones a lo largo de cinco meses y medio con la puerta entreabierta.
4. Gestión de contexto: la truncación invisible
La compactación y la edición de contexto ya son primitivos de servidor con umbrales publicados: la edición de contexto se dispara por defecto a los 100.000 tokens de entrada; la compactación, a los 150.000. Viven en el runtime y no en tu aplicación por pura economía de la caché de prompts: escribir en caché cuesta 1,25× o 2× la entrada base, leer cuesta 0,1×, y cada edición de contexto invalida el prefijo cacheado. Recortar tiene precio, así que el recorte se coordina donde está la caché.
Hace cumplir: que las ejecuciones no mueran por agotamiento de contexto y que la factura de tokens se mantenga cuerda. Las reducciones publicadas son serias: 84% de tokens en una evaluación de búsqueda web de 100 turnos con edición de contexto, y de 150.000 a 2.000 tokens —un 98,7%— sustituyendo idas y venidas de herramientas por ejecución de código.
No hace cumplir: un registro auditable de qué se tiró. La truncación silenciosa es estructuralmente inobservable desde el lado del cliente de la API. Y ese es un problema del bucle de evaluación cerrado (pilar 5): no puedes evaluar una salida cuya entrada no puedes reconstruir.
5. Humano en el bucle: el primitivo del pilar 6 que ya existe
Este merece espacio extra, porque es la aportación más útil del artículo.
Una aprobación humana es el mismo primitivo que la recuperación ante fallos, apuntado a una persona: suspender una computación en vuelo de forma durable e indefinida, y reanudarla con una entrada nueva. El interrupt() de LangGraph persiste vía checkpointer y espera indefinidamente; step.waitForEvent() y step.sleep() de Cloudflare Workflows llegan a 365 días; los Updates de Temporal son la forma correcta de una aprobación que debe ser confirmada. Y la parte decisiva: una ejecución esperando no cuesta casi nada. Cloudflare excluye explícitamente las instancias en espera de sus límites de concurrencia, y las sesiones hibernadas no facturan.
Aquí toca matizar en público un argumento que suele darse por bueno: que la aprobación síncrona es tan cara que los equipos acaban desactivándola —cierto— y que la revisión asíncrona no existe como producto —solo a medias—. El mecanismo es una commodity; el envoltorio de gobierno no lo es. Cualquier runtime serio puede mantener una ejecución suspendida 48 horas por un coste próximo a cero. Lo que ninguno trae de serie es la escalera de niveles de autonomía, la promoción con evidencia de evaluación y la degradación unilateral instantánea. La autonomía ganada (pilar 6) sale más barata de adoptar de lo que parece: la pieza cara ya está en tu factura.
Dos trampas de corrección que te morderán en una auditoría. Una: en LangGraph, al reanudar, el nodo entero se re-ejecuta desde el principio, no desde la línea de la interrupción, así que los efectos secundarios previos a la pausa corren dos veces salvo que sean idempotentes; además los valores de reanudación se emparejan por índice. Y otra, esta a favor: bifurcar un checkpoint pasado crea una rama nueva mientras el historial original queda intacto. Así se hace revisión contrafactual sin destruir evidencia.
6. Techos de presupuesto: consultivo contra ejecutable
La otra subsección de alto valor. Existen tres techos independientes: de pasos (límites de recursión, max_turns), de tokens y de tiempo/reintentos. Pero la distinción que importa no es cuál, sino si se hace cumplir.
Los task budgets de Anthropic inyectan una cuenta atrás del lado del servidor para que el modelo termine con elegancia en lugar de cortarse a mitad de acción. Y la propia documentación es explícita: el presupuesto es consultivo, no ejecutable; el techo duro sigue siendo max_tokens.
Esto es una prueba de fuente primaria de algo que conviene grabarse: un presupuesto que el modelo conoce es una sugerencia, y bajo inyección de prompt una sugerencia no es nada. Los techos que sí se ejecutan son los toscos —max_tokens, topes de pasos, timeouts— y son por llamada o por ejecución, no por responsable, y no se atenúan al delegar. Un agente sin techo ejecutable es una factura sin límite con una excusa plausible.
7. Sub-agentes: la frontera que nadie vigila
Orquestar varios agentes compra tiempo de reloj y holgura de contexto a cambio de unas 15 veces los tokens de una interacción de chat (frente a 4 veces de un agente solo), así que exige justificación caso a caso. Pero el punto arquitectónico es otro: el resultado de un sub-agente es entrada no confiable para el orquestador. Un canal de inyección de prompt dentro de tu propio sistema, a un salto de tus controles. Algunos arneses ya escanean la salida de los sub-agentes en busca de patrones con forma de instrucción antes de que el padre la lea.
Hace cumplir: aislamiento de proceso y almacenamiento entre sub-agentes.
No hace cumplir: la atenuación de autoridad cadena abajo. La delegación recursiva es donde los pilares 1, 2 y 4 fallan a la vez, y ningún runtime lo resuelve, porque ningún protocolo en vía de estandarización sabe decir todavía «este sub-agente puede gastar X, hasta Y, en nombre de Z».
Lo que ningún runtime puede hacer, compres el que compres
Tres límites estructurales, dichos una vez y sin anestesia.
Hace cumplir en el perímetro de los bytes, no en la semántica del significado. Puede bloquear un destino; no puede saber que la salida cruzó una frontera de sensibilidad. El historial de incidentes es un registro de procedencia: EchoLeak (CVE-2025-32711, junio de 2025) y GeminiJack (Noma Security, diciembre de 2025) movieron contenido a través de una frontera de sensibilidad dentro de una ventana de contexto y lo sacaron por un canal de salida sin restricciones. Ninguno de los dos se arregla con una allowlist mejor.
No puede expresar delegación. El on-behalf-of de OAuth cubre un salto. La delegación entre organizaciones existe solo como declaración de problema en el IETF. Y el borrador de tokens atenuantes para agentes —el mecanismo que necesitarías para «gasta como mucho X, hasta Y, en nombre de Z»— es un Internet-Draft individual en su revisión -01, no adoptado por el grupo de trabajo de OAuth. Ningún runtime puede hacer cumplir lo que ningún protocolo sabe decir.
Las defensas en la capa del modelo no convergen. El análisis de NIST CAISI sobre una competición pública de red-teaming (~400 participantes, más de 250.000 intentos de ataque, publicado en marzo de 2026) encontró al menos un ataque exitoso contra los trece modelos frontera evaluados, con tasas de éxito entre el 0,5% y el 8,5%. Los vendedores de guardarraíles presumen de parar el ~95% de los ataques; como escribe Simon Willison, «in web application security 95% is very much a failing grade» —en seguridad de aplicaciones web, un 95% es un suspenso claro—. Un filtro probabilístico delante de una capacidad determinista no es una frontera.
Y aquí, el traspaso que da sentido a todo lo anterior:
Todo lo de arriba se puede comprar, y la mayoría ya lo tienes. Lo que no se puede comprar es la capa que dice qué humano responde por esta ejecución, qué tenía permitido hacer este agente, qué leyó antes de escribir, cuánto podía gastar sumando todos los saltos, si alguien lo ha evaluado últimamente y si se ha ganado el derecho a actuar sin revisión. Esos son los seis pilares del gobierno de agentes —atribución, capacidad mínima, conservación de la procedencia, recursos acotados, bucle de evaluación cerrado y autonomía ganada— y se apoyan exactamente sobre el sustrato que acabamos de recorrer.
Qué preguntar antes de firmar
Estas son preguntas de compra de runtime; las de autoevaluación de gobierno son otra lista y otro día. Llévalas a la reunión:
- Enséñame el registro de eventos y el replay. ¿Qué operaciones se tratan como efectos secundarios y cuáles se re-ejecutan?
- ¿Facturáis CPU activa o tiempo de reloj, y cuánto cuesta por hora una sesión viva pero ociosa? Con tarifas publicadas, la aritmética de flota es brutal: un sandbox por defecto mantenido abierto ronda los 0,166 dólares/hora; un actor fijado en memoria, unos 0,0056; uno hibernado, cero. En 10.000 sesiones concurrentes son ~1.660 dólares/hora contra ~56 contra nada.
- ¿Qué cuesta una ejecución esperando 48 horas una aprobación humana? ¿Puedo bifurcar una ejecución terminada para inspeccionar qué habría pasado?
- Nombradme el nivel de aislamiento. ¿Dónde se aplica la allowlist de salida: en el proxy, en el kernel o en el prompt?
- ¿Qué límites son ejecutables y cuáles consultivos: presupuesto de tokens, techo de pasos, timeout duro? ¿Dónde está el punto de medición que el agente no puede esquivar?
- Cuando la compactación tira contexto, ¿qué queda escrito sobre lo que se tiró?
- ¿Qué cruza la frontera de los sub-agentes, y su salida se trata como entrada no confiable?
Y la regla de diseño que vale más que todo lo demás junto: mantén la sesión y el sandbox separados. La sesión es barata, hiberna y vive mucho; el sandbox es caro y debe crearse perezosamente, con snapshot, y derribarse entre llamadas a herramientas. La mayoría de los sustos de factura en flotas de agentes son este único error.
El hueco no se cierra con un modelo mejor
Volvamos al principio. La brecha entre el 85% y el 15% no la cierra un modelo mejor: los mismos modelos producen ambos números. Se cierra cuando alguien es dueño del presupuesto, de la frontera, de la evidencia y de la puerta. El runtime que ya tienes te da los puntos de enforcement para los dos primeros, material parcial para el tercero y el primitivo de suspensión para el cuarto. El resto es gobierno. Y el gobierno es, precisamente, la parte que no se convierte en commodity.
Ideas por encima de código; evidencia por encima de humo.
Deja una respuesta