Cómo ejecutar infraestructura agéntica en producción

La infraestructura de AI agéntica es la capa de ejecución, orquestación, datos, seguridad y observabilidad que se necesita para ejecutar agentes de AI de forma confiable en producción. A diferencia de las aplicaciones tradicionales basadas en solicitudes, los agentes necesitan estado persistente, ejecución durable, acceso controlado a herramientas, límites de costo de inferencia y tracing por paso.

Este post cubre el lado de la ejecución del stack. Para el modelo completo de capas y el vocabulario, empieza por Understanding Agentic AI Infrastructure.

¿Qué infraestructura necesitan los agentes de AI en producción?

Tres propiedades cambian cuando un agente sale del prototipo.

Las sesiones reemplazan a las solicitudes. Un objetivo del usuario se convierte en una cadena de llamadas a modelos, llamadas a herramientas y decisiones. La unidad de trabajo se mide en pasos, no en milisegundos.

La memoria de trabajo se vuelve infraestructura. El agente necesita su objetivo, su historial de pasos y sus resultados intermedios disponibles a lo largo de esos pasos. En una notebook, eso vive en una variable de Python. En producción, necesita un lugar durable.

El volumen de inferencia se genera, no se recibe. Una solicitud entrante puede producir treinta llamadas al modelo. La planificación de capacidad basada en tasa de solicitudes deja de predecir algo útil.

Todo lo que sigue se desprende de esos tres puntos. Este post cubre las capas que deciden si un agente sobrevive a su primer mal día: ejecución, inferencia y observabilidad.

Por qué el serverless tradicional no alcanza para agentes de AI de larga duración

El cómputo con alcance de solicitud parte de tres supuestos que las sesiones de agentes rompen: el trabajo termina rápido, el trabajo es stateless y el trabajo produce una respuesta.

La investigación sobre serverless con estado formaliza la misma limitación: los modelos convencionales de function-as-a-service no persisten el progreso de ejecución entre invocaciones (Burckhardt et al., OOPSLA 2021).

La ejecución durable agrega workflows, persistencia de estado y mecanismos de recuperación, de modo que un proceso puede pausar, reanudar y sobrevivir a fallas de infraestructura. Estas capacidades se vuelven esenciales cuando un agente opera a lo largo de varios pasos en lugar de completar su trabajo dentro de una sola solicitud.

Las fallas concretas siguen un patrón:

• Timeout a mitad del loop. El límite de la función expira en el paso nueve. Los pasos uno a ocho ya tuvieron efectos colaterales. No hay registro de dónde reanudar.
• Pérdida de la memoria de trabajo en el retry. El retry arranca desde el objetivo original sin memoria de lo que ya intentó, así que repite las mismas llamadas a herramientas y el mismo gasto.
• Ningún punto de pausa para aprobación. Un agente que debe esperar a una persona no tiene dónde estacionarse. Los equipos lo sortean con polling, que quema inferencia en verificaciones que no cambian nada.

La concurrencia lo empeora. La gestión de estado suele ser lo primero que se degrada a medida que crece la escala, y los logs de comunicación entre agentes frecuentemente no existen, lo que hace que los incidentes multiagente sean los más difíciles de reconstruir.

Cómo funciona la ejecución durable en infraestructura agéntica

El patrón que resuelve esto separa el loop de los pasos.

El controlador del loop es dueño de la sesión: cuál es el objetivo, qué paso viene después, qué ya ocurrió y cuánto presupuesto queda. No guarda lógica de negocio ni hace razonamiento.

Los pasos son ejecuciones stateless comunes. Un paso recibe entrada explícita, llama a un modelo o a una herramienta, devuelve un resultado y termina. No sabe nada de la sesión.

Entre cada paso, el controlador escribe un checkpoint. Un checkpoint guarda el objetivo, el historial ordenado de pasos con sus resultados, el gasto acumulado de tokens y la próxima acción planificada. La recuperación se convierte en una lectura: carga el último checkpoint y reanuda desde el siguiente paso.

Esto da tres propiedades:

• Reanudabilidad: una sesión caída reinicia en el paso nueve, no en el paso uno.
• Pausabilidad: esperar una aprobación humana es un checkpoint que no avanza, así que nada consume cómputo mientras espera.
• Idempotencia: dale a cada llamada a herramienta con efecto colateral una clave derivada del ID de sesión y del índice del paso, y un paso reejecutado reutiliza el resultado original en lugar de crear un segundo registro o enviar un segundo pago.

Guarda los checkpoints en un key-value store de baja latencia, no en una base de datos relacional. El patrón de acceso es una lectura y una escritura por paso, con clave en el ID de sesión, y la escritura está en el camino crítico de cada paso que da el agente.

Aislar el código que escribe el agente

La ejecución en sandbox aplica en el momento en que un agente genera código y no solo llama a herramientas predefinidas. Ese código llega no confiable por partida doble: lo escribió el modelo, y una prompt injection pudo haber moldeado lo que el modelo escribió.

Trata un paso de código generado como entrada hostil con privilegios de ejecución. Tres fronteras cargan con la mayor parte del peso:

• Aislamiento de procesos por sesión, para que el código generado por un agente no pueda leer la memoria ni los checkpoints de otra sesión.
• Sin credenciales de ambiente. Pasa el token específico que el paso necesita como entrada explícita. Una variable de entorno heredada por código generado se convierte en lo que el código decida hacer con ella.
• Control de egress. El código generado que puede alcanzar hosts arbitrarios puede exfiltrar lo que se le dio. Restringe los destinos de salida a los que la tarea requiere.

Las mismas fronteras aplican a llamadas a herramientas que ejecutan shell o evalúan expresiones. Cualquier paso que convierte la salida del modelo en ejecución pertenece dentro de ese perímetro.

Cómo controlar los costos de inferencia de agentes de AI

La fuente más común de picos inesperados de costo en producción son los loops de razonamiento sin límite. Nada en el camino de la solicitud limita cuántas veces un agente decide volver a pensar.

Cuatro controles resuelven la mayor parte.

Techos duros de pasos y tokens. Cada sesión recibe un número máximo de pasos y un presupuesto máximo de tokens. Alcanzar cualquiera de los dos termina la sesión y escala el caso. Trátalos como límites, no como metas. Una sesión que los alcanza constantemente señala una tarea que el agente no puede completar.

Terminación por falta de progreso. Registra si cada paso cambió el estado de la sesión. Tres pasos consecutivos que no producen información nueva normalmente significan que el agente está dando vueltas sobre el mismo razonamiento. Deténlo ahí, en lugar de esperar al techo.

Escalonamiento de modelos. El enrutamiento, la clasificación y la extracción rara vez necesitan el modelo más grande disponible. Reserva el modelo caro para los pasos de razonamiento y ejecuta los pasos mecánicos en uno más chico. En una sesión de catorce pasos, esto suele mover la mayoría de las llamadas al tier más barato.

Caché de retrieval. Los agentes vuelven a pedir el mismo contexto repetidamente dentro de una sesión. Cachea los resultados de retrieval por sesión y por consulta, y las llamadas redundantes desaparecen.

La economía merece atención ahora, no después. McKinsey proyecta que los costos de infraestructura de TI se multiplicarán entre dos y tres veces para 2030, con presupuestos todavía restringidos. Una encuesta de PwC refuerza la presión que crea la adopción de agentes: 88% de los ejecutivos dijo que sus organizaciones planeaban aumentar los presupuestos relacionados con AI debido a la AI agéntica, y más de un cuarto esperaba aumentos de 26% o más.

A medida que los agentes convierten un solo objetivo en múltiples llamadas a modelos y herramientas, controlar el volumen de inferencia se vuelve un requisito de infraestructura y no una optimización posterior.

Observabilidad para caminos de razonamiento y llamadas a herramientas

El camino de decisión de un agente no es inspeccionable como una pila de llamadas a funciones. El log muestra la acción; la cadena que la produjo normalmente no queda registrada. Las llamadas a herramientas que no emiten telemetría se vuelven puntos ciegos donde el análisis de causa raíz se detiene.

Resuelve esto en el punto de emisión. Trata la sesión como una traza y cada paso como un span, y registra por span:

• ID de sesión, índice del paso y paso padre
• Nombre del modelo y versión del prompt o del template
• Conteo de tokens de entrada y de salida
• Nombre de la herramienta, un hash de los argumentos y el estado del resultado
• Latencia, separada entre inferencia y ejecución de la herramienta
• El motivo de terminación cuando la sesión finaliza

Los hashes de argumentos, en lugar de los argumentos crudos, mantienen los valores sensibles fuera de la telemetría y aun así permiten detectar un paso que repite una llamada idéntica.

Dos señales derivadas pertenecen a cualquier dashboard. Los pasos por sesión muestran desvío de comportamiento mucho antes que el costo: un agente que promediaba seis pasos la semana pasada y promedia once esta semana cambió, aunque la factura todavía no lo refleje. Los tokens por objetivo completado son la métrica unitaria que importa, porque las sesiones que fallan tarde son las caras.

Exporta estas trazas al mismo flujo que la telemetría de la aplicación. Los incidentes de agentes rara vez se quedan dentro del agente.

Beneficios de colocalizar inferencia, lógica y datos

La latencia dentro de un loop de agente se acumula. Un paso que llama a retrieval y luego a inferencia paga ambos viajes de ida y vuelta, y la sesión paga esa suma una vez por paso. Catorce pasos a 700 ms de overhead combinado de red e inferencia son cerca de diez segundos antes de contar cualquier trabajo real.

Colocalizar la llamada al modelo, la lógica de herramientas y el store de retrieval en la misma plataforma distribuida ataca el multiplicador, no un solo término.

• Menor overhead por paso, que se multiplica a lo largo de la sesión en lugar de sumarse una sola vez.
• Gasto predecible, porque la telemetría de tokens, los presupuestos y la ejecución que los aplica están en un mismo lugar.
• Respuesta a incidentes más rápida, ya que las trazas cubren razonamiento, llamadas a herramientas y resultados sin tener que unir datos entre proveedores.
• Menos saltos entre regiones, lo que elimina una clase de falla parcial en sesiones de múltiples pasos.

Infraestructura agéntica en producción comparada con el serverless tradicional

Son enfoques complementarios, no competidores. La mayoría de los diseños en producción usa orquestación durable para la sesión y ejecución rápida con alcance de solicitud para los pasos individuales dentro de ella. El controlador es de larga duración; los pasos siguen siendo cortos, stateless y baratos.

El error que vale la pena evitar es ejecutar todo el loop dentro de un único proceso de larga duración. Eso reintroduce los problemas que el checkpoint resolvió: una caída pierde la sesión, y nada puede pausar para una aprobación.

Arquitecturas de referencia y casos de uso reales

Tres formas cubren la mayoría de los despliegues en producción.

Asistente sincrónico. Una persona espera la respuesta. La sesión es corta, el presupuesto de pasos es ajustado y la latencia domina cada decisión de diseño. Colocalizar retrieval e inferencia importa más aquí. Limita los pasos de forma agresiva y degrada a una respuesta parcial en lugar de hacer esperar al usuario.

Agente en background. El trabajo se envía y el resultado llega después. Las sesiones duran minutos u horas, el checkpoint carga con el peso y las compuertas de aprobación son prácticas porque nada queda bloqueado esperando una respuesta. La mayoría de los agentes operativos y de procesamiento de datos encaja aquí.

Agente de verificación orientado a eventos. Llega un flujo de ítems, el agente evalúa cada uno contra un modelo y las coincidencias se escalan. El throughput y el costo por ítem dominan; las sesiones son cortas pero continuas. Axur, cliente de Azion, ejecuta este patrón para detección de abuso de marca. Redujo el tiempo entre detección y solicitud de takedown a cinco minutos, automatizando más de 30.000 takedowns por mes y agregando 450 millones de sitios nuevos a verificación cada mes.

Cómo Azion ejecuta infraestructura agéntica en producción

Azion ejecuta cómputo, inferencia y datos en una única plataforma distribuida. Para cargas de trabajo de agentes, eso significa que el overhead por paso descrito arriba no se acumula entre fronteras de servicio.

AI Inference ejecuta LLMs, VLMs, embeddings, reranking y modelos multimodales con escalamiento serverless, así la capacidad de inferencia sigue a la concurrencia de sesiones sin aprovisionar clusters de GPU. La API compatible con OpenAI permite que los frameworks de agentes existentes se conecten cambiando base URL y credenciales, sin reescritura.

Functions ejecuta la lógica de los pasos cerca de la llamada de inferencia, manteniendo bajo el overhead por paso justo donde se multiplica.

KV Store guarda los checkpoints de sesión y la memoria de trabajo, ajustándose al patrón de una lectura y una escritura por paso que crea el checkpointing.

SQL Database aporta búsqueda vectorial para retrieval, así el contexto de RAG viene de la misma plataforma que sirve el modelo.

Object Storage guarda los artefactos más grandes que un agente produce o consume, sin empujarlos a través del checkpoint.

LoRA Fine-Tune adapta un modelo a un dominio sin reentrenamiento completo, lo que reduce la cantidad de pasos que los agentes necesitan para llegar a una respuesta correcta sobre material especializado.

Real-Time Events da visibilidad a nivel de solicitud para investigación, y Data Stream exporta trazas a la herramienta de observabilidad que el equipo ya usa.

Conclusión y próximos pasos para infraestructura agéntica en producción

Ejecutar infraestructura agéntica en producción requiere tres cosas: hacer checkpoint de cada paso, para que una falla cueste un paso y no una sesión; limitar el loop, para que el costo siga siendo una línea previsible; y trazar el razonamiento, para que un agente que se comporta mal deje evidencia.

Los equipos que aciertan en esto dejan de tratar cada agente como un sistema a medida. Los controles viven en la plataforma. Poner el próximo agente en producción se vuelve una cuestión de definir su objetivo, sus herramientas y su presupuesto.

El próximo post de esta serie cubre la seguridad de la infraestructura agéntica: identidad por agente, alcances de menor privilegio y la superficie de ataque de las llamadas a herramientas.

Lee la documentación de AI Inference para ver cómo la inferencia distribuida y el escalamiento serverless encajan en una capa de ejecución de agentes.