Cruzar la production gap: cinco patrones para agentes de IA que sobreviven al lunes por la mañana
Los flujos con agentes long-running duran días, atraviesan pods, esperan a humanos y se auditan. Repasamos los cinco patrones — y la capa de interoperabilidad — que aplicamos cuando los ingeniamos para clientes.
TL;DR
Los flujos que de verdad importan a nuestros clientes — procesar miles de siniestros, lanzar una secuencia comercial de una semana, cerrar el trimestre financiero, vigilar un topic de Kafka en busca de anomalías — no caben en un solo turno de conversación. Duran días. Atraviesan pods. Esperan a humanos. Sobreviven a caídas. Se auditan.
Un loop de agente al estilo REPL con un vector store atornillado al lado no sobrevive al lunes por la mañana. Cinco patrones y una capa de interoperabilidad sí. Checkpoint-and-resume, aprobaciones delegadas, contexto en capas de memoria con gobernanza, procesamiento ambient y orquestación de flotas — más A2A para agente↔agente y MCP para agente↔herramienta/datos. Así diseñamos agentes long-running cuando los construimos para clientes.
¿Cuál es la unidad de trabajo ininterrumpida más larga que tu agente necesita ejecutar? Minutos — probablemente no necesitas agentes long-running. Horas o días — estos patrones son el punto de partida, y las capas de gobernanza e interoperabilidad pasan a ser estructurales, no opcionales.
La production gap es real
La mayoría de los agentes que se enseñan como demo se rompen el momento en que el trigger deja de ser «un humano escribió en un chat». Cuando apuntas ese mismo loop a una cola de 10.000 facturas, a un onboarding multi-día o a una reconciliación nocturna, cuatro cosas se rompen casi al instante: el estado se pierde cuando se cae un pod, el cómputo queda secuestrado esperando a un humano, la memoria deriva entre ejecuciones, y cada tool call se convierte en un sitio por el que pueden fugarse datos. Esos son los modos de fallo contra los que diseñamos desde el día uno.
Patrón 1 — Checkpoint-and-Resume: estado que sobrevive al pod
«Trata a tu agente como un proceso de servidor long-running, no como un request handler.»
La solución es conceptualmente simple y arquitectónicamente importante: checkpointea el progreso, gestiona fallos parciales, garantiza idempotencia. La granularidad importa — checkpointear cada documento es desperdicio, checkpointear sólo al final es arriesgado. Para un batch de 10.000 documentos, hacerlo cada 50 suele ser el equilibrio correcto.
Cómo lo construimos. Nuestro stack por defecto usa un supervisor LangGraph contra un checkpointer Redis-backed, con el estado del grafo persistido en cada frontera de superstep. Encima de eso ponemos un delta log por nodo — indexado por thread, turno y nodo — para que cada mutación del estado sea atribuible al nodo que la produjo. Cuando se cae un executor a mitad de ejecución, el siguiente pod arranca desde el último checkpoint sin fallo visible y sin pérdida de trabajo.
Patrón 2 — Aprobación delegada: cero cómputo mientras esperas
Un flujo real espera — a una firma, a un underwriter, a un review de seguridad, a que el cliente se despierte en otra zona horaria. El patrón: pausa in situ con el estado de ejecución intacto, libera cómputo, reanuda con un evento.
La mayoría de implementaciones de «human-in-the-loop» se reducen a: serializar el estado a JSON, mandar un webhook, rezar para que alguien lo mire. Las notificaciones compiten con decenas de otras alertas. Cuando el humano responde, el agente tiene que deserializar, reconstruir contexto y rezar para que nada haya cambiado.
Cómo lo construimos. Cualquier herramienta que
devuelva {"status": "pending_approval"} o
{"user_input_required": true} es interceptada por
un nodo HITL gate. El estado del grafo se congela, se persiste en
Redis, y el worker pod coge inmediatamente otras tareas. Horas o
días después, un mensaje de aprobación llega al stream y el grafo
se reanuda desde el mismo checkpoint — misma conversación, mismo
plan, mismos resultados intermedios. El cómputo es
realmente cero mientras está en pausa.
Así es como un agente de «procesa todas las reclamaciones que llegaron durante la noche» puede tener 1.200 aprobaciones pausadas durante el fin de semana sin coste, y reanudar el instante en que un humano da click.
A partir de cierta escala — veinte agentes long-running concurrentes por operador — los canales de Slack y los hilos de email fallan. Necesitas una cola estructurada con tres carriles: Necesita tu input, Errores, Completados. Esa superficie la diseñamos en cada engagement long-running.
Patrón 3 — Contexto en capas de memoria (y por qué hay que gobernarlo)
Este es el patrón que más equipos infravaloran. Dos memorias, no una: la memoria de trabajo es rápida y limitada al turno actual; la memoria a largo plazo acumula hechos entre sesiones. Ambas tienen que coexistir. En el momento en que dejas que los agentes escriban en un store de memoria compartida sin control, tienes un problema de gobernanza.
El riesgo tiene nombre: memory drift. Un agente aprende de un puñado de interacciones atípicas que un atajo de procedimiento es aceptable, y empieza a aplicarlo por todas partes. Multiplica eso entre varios agentes leyendo y escribiendo en pools compartidos y tienes leakage entre flujos difícil de detectar y aún más difícil de explicarle a compliance.
La respuesta arquitectónica son tres piezas: identidad de agente criptográfica, un registry centralizado de agentes y enforcement de políticas en la frontera de cada escritura de memoria. La memoria de trabajo es un canal de mensajes podado al turno actual. La memoria a largo plazo vive en un vector store organizado en tres tiers — episódica, semántica, procedimental — con una pasada de consolidación dirigida por LLM al final de sesión y un hook de política en cada escritura que corre detección de PII y reglas de denegación por org antes del commit.
Acompañamos eso con la misma postura del lado de tool calls: cada
petición a través de nuestra capa MCP lleva un JWT de corta
duración, cada llamada SQL corre con row-level security fijado al
tenant (SET LOCAL app.current_org_id), y cualquier
ejecución de código no confiable aterriza dentro de un sandbox
gVisor. La exfiltración cross-tenant queda
bloqueada estructuralmente, no sólo desincentivada.
Patrón 4 — Procesamiento ambient: activado por eventos, no por prompts
La forma de un agente cambia cuando el trigger deja de ser «un usuario escribió algo» y pasa a ser «se disparó un webhook», «apareció una fila en BigQuery», «llegó un ticket de soporte» o «una métrica cruzó un umbral». Estos agentes están ociosos la mayoría del tiempo, son multi-stream y long-lived.
La regla arquitectónica que los hace sostenibles es externalizar la política. No hardcodees presupuestos de retry, reglas de routing, ni defaults de HITL en el código del agente. Mantenlos en una capa que el agente lee en runtime. Actualizas una vez y toda la flota adopta las nuevas reglas inmediatamente — sin redeploy por agente.
Patrón 5 — Orquestación de flota: un coordinador y sus especialistas
Un agente coordinador descompone el trabajo — research, scoring, secuenciación, outreach, follow-up — y delega cada pieza a un especialista que corre en su propio timeline, con su identidad propia y sus permisos de herramientas propios. El coordinador mantiene el estado global y maneja los handoffs. Crucial: cada especialista es desplegable de forma independiente, así que un mal release en uno nunca cascada al resto.
Nuestra topología de referencia es un supervisor que rutea entre un roster de especialistas (chat, SQL, Python, ML, platform, data, scraping, pipeline, integraciones). La topología del grafo es explícita y graph-defined, no prompt-defined — el LLM no puede saltarse la estructura por atajo. Encima de eso corremos detección de convergencia para romper loops de agente automáticamente: si el mismo hash de herramienta se dispara tres veces o un turno excede 25 tool calls, conmutamos a degradación elegante en lugar de quemar un presupuesto ilimitado.
Bonus — A2A + MCP: la capa de interoperabilidad
La mayoría de las organizaciones no construyen cada agente desde cero. El verdadero apalancamiento son agentes construidos por equipos distintos — a veces empresas distintas — descubriéndose y colaborando entre sí. Dos protocolos abiertos sostienen ese peso:
- A2A estandariza la comunicación agente↔agente. Cada agente A2A-compatible publica una card en una URL well-known describiendo sus capacidades, auth y rate limits. Un registry central se convierte en el service mesh del ecosistema de agentes.
- MCP estandariza la comunicación agente↔herramienta/datos. Un conector de Stripe se ve igual para un agente que un conector de BigQuery — el protocolo es la interfaz, el backend es intercambiable.
Toda nuestra ruta de ejecución de herramientas es MCP. Los agentes especialistas llaman a un servidor MCP, que valida un JWT por request, aplica RLS y sandboxea la ejecución de código. Los servidores MCP instalados por el cliente se registran dinámicamente — tu equipo despliega una herramienta, el supervisor recoge la capacidad al cargar, y el agente tiene una skill nueva sin que nadie despliegue código de framework.
El lado consumidor — descubrir y llamar a agentes A2A externos — es donde este stack deja de ser puramente interno. Una capa de gobernanza bien definida ahí controla qué datos salen de la frontera y qué respuestas estamos dispuestos a accionar. Esa capa es el mismo plano de política runtime del que depende el procesamiento ambient (Patrón 4): un único sitio donde codificas «qué está permitido», leído por cada agente.
Cómo elegir
Los patrones componen. Un sistema de compliance usa checkpoint-and-resume para procesar documentos, aprobación delegada para los review gates, contexto en capas con gobernanza para conocimiento cross-session, procesamiento ambient para triggers entrantes y orquestación de flota para coordinar especialistas. Elige patrones por el modo de fallo que previenen, no por su novedad.
Hazte primero la pregunta diagnóstica: ¿cuál es la unidad de trabajo ininterrumpida más larga que tu agente necesita ejecutar? Si son minutos, ahórrate la ingeniería. Si son horas o días, los cinco patrones más la capa de interoperabilidad pasan a ser estructurales — y el coste de saltarse cualquiera aparece en producción en semanas.
Los equipos que hoy lanzan agentes aislados y sin estado estarán refactorizando en doce meses. Los que construyen con persistencia, gobernanza e interoperabilidad en mente acumulan ventaja cada día.
Esa es la barra a la que construimos en cada engagement. Si tienes delante un flujo que necesita correr durante días, atravesar pods, esperar a humanos y sobrevivir al lunes por la mañana — deberíamos hablar.
Crédito
El framing de la «production gap» y la enumeración de los cinco patrones están adaptados de The Production Gap: 5 Patterns for Building Long-Running AI Agents de Addy Osmani y Shubham Saboo en Turing Post. Las decisiones de arquitectura, las elecciones a nivel de fichero y los tradeoffs de este post son los que tomamos cuando construimos sistemas con agentes para clientes.