Agentes de larga ejecución: qué cambia cuando un agente funciona durante días

• Surge un nuevo paradigma en el que los agentes de IA operan de forma autónoma durante días o semanas, no en una sola sesión de chat, sino atravesando múltiples ventanas de contexto y sandboxes, recuperándose de fallas y reanudando desde puntos de interrupción
• Los agentes existentes chocan con limitaciones estructurales de una sola sesión, como el agotamiento de la ventana de contexto, el exceso de confianza en su propia evaluación y la reintroducción de cambios previos
• Grandes empresas como Anthropic, Google y Cursor están convergiendo hacia una arquitectura de bucle del modelo, sandbox de ejecución y separación de logs de sesión
• Los retos clave de los agentes de larga ejecución son la gestión de estado persistente, la autoverificación y la compresión de contexto, y se presentan cinco patrones de diseño para resolverlos
• Más que el modelo en sí, la principal área de inversión que genera diferencias reales de productividad es la capa de estado, sesión y handoff estructurado que lo envuelve

---

Los tres significados de “larga ejecución”

• Long-horizon reasoning: la capacidad de planificar y ejecutar a través de muchas etapas dependientes; es sobre todo un problema de calidad del modelo. Según la métrica time horizon de METR, el tiempo de trabajo que los modelos frontier pueden completar con 50% de confiabilidad se ha duplicado aproximadamente cada 7 meses desde 2019; si la tendencia continúa, podrían completar tareas de escala diaria en 2028 y anual en 2034
• Long-running execution: una estructura en la que el proceso del agente corre durante horas o días y el modelo puede ser invocado miles de veces; es principalmente un problema de diseño del harness
• Persistent agency: una forma en la que el agente mantiene su identidad más allá de una sola tarea, acumula memoria y aprende preferencias del usuario. El Memory Bank de Google es un caso representativo
• En producción real, los tres suelen combinarse, pero los problemas de ingeniería y sus soluciones difieren en cada caso

Por qué importan los agentes de larga ejecución

• Un agente que corre 10 minutos sirve para responder preguntas o corregir bugs pequeños, pero un agente que corre 10 horas puede desarrollar una funcionalidad completa, completar una migración acumulada durante 6 trimestres o hacer investigación al nivel de un analista junior
• En el anuncio de Claude Sonnet, Anthropic mostró un caso de más de 30 horas de programación autónoma según sus pruebas internas, generando en una sola ejecución una app estilo Slack de 11,000 líneas
• En Project Vend, una instancia de Claude operó durante un mes un negocio real de máquinas expendedoras en una oficina, encargándose de inventario, precios y comunicación con proveedores. La primera etapa produjo fallas significativas, y la segunda mejoró mucho
  • El punto clave no era la rentabilidad, sino observar los problemas de consistencia que aparecen cuando un agente mantiene su identidad durante semanas, no por turnos

Las tres paredes con las que chocan todos los agentes de larga ejecución

• Contexto finito: incluso una ventana de 1M tokens termina agotándose, y antes de llenarse por completo ya aparece context rot (deterioro gradual del desempeño del modelo). Una ejecución de 24 horas no encaja en ningún roadmap actual de ventanas de contexto
• Ausencia de estado persistente: una sesión nueva empieza en blanco. Anthropic lo compara con “un ingeniero que entra a su turno sin saber absolutamente nada de lo que pasó en el turno anterior”
• Ausencia de autoverificación: cuando el modelo evalúa su propio trabajo, aparece de forma consistente un sesgo positivo. Ante la pregunta “¿ya terminaste?”, responde “sí” más seguido de lo real y, sin una señal de verificación separada, puede entregar un resultado con plena confianza cuando en realidad está apenas al 30%

El bucle Ralph: una implementación simple de agentes de larga ejecución para uso práctico

• El bucle Ralph (técnica Ralph Wiggum) es un patrón práctico de agentes de larga ejecución popularizado por Geoffrey Huntley y Ryan Carson, cuya implementación de referencia es un solo script de bash
• Secuencia de funcionamiento: seleccionar una tarea incompleta (prd.json) → construir el prompt con tarea, contexto y memo → invocar al agente → correr pruebas → agregar el resultado a progress.txt → actualizar la lista de tareas → repetir
• Principio central: el agente en sí tiene amnesia, pero el sistema de archivos conserva la memoria. prd.json funciona como plan, progress.txt como libreta de laboratorio y AGENTS.md como manual vivo de reglas
• Compound Product de Ryan Carson encadena varios bucles en forma de bucle de análisis (leer reportes diarios) → bucle de planificación (generar PRD) → bucle de ejecución (escribir código), lo que equivale a una versión open source de la estructura triple planner-generator-evaluator a la que Anthropic llegó por su cuenta
• Con solo scripts de bash y archivos JSON, es posible montar de un día para otro un agente de larga ejecución que funcione durante la noche. Lo que Google y Anthropic han productizado es convertir este patrón en algo recuperable, seguro y observable

Anthropic: del harness a separar Brain/Hands/Session

• Primer enfoque (estructura de harness): un harness de 2 agentes para desarrollo full-stack autónomo. El agente Initializer configura el entorno inicial del proyecto, expande el prompt a feature-list.json y escribe el script de arranque (init.sh). El agente Coding despierta repetidamente, avanza por funcionalidad, corre pruebas, escribe claude-progress.txt y hace commits
  • Regla de test ratchet: “no está permitido borrar ni modificar tests”, para evitar una falla común en la que el agente elimina tests que fallan para hacer que todo pase
  • En la versión ampliada de InfoQ, esto evoluciona a una estructura triple planner, generator, evaluator. Separar generación y evaluación es importante porque el modelo evalúa su propio trabajo con demasiada indulgencia
• Segundo enfoque (separación Brain/Hands/Session): la arquitectura de Claude Managed Agents (lanzado a inicios de abril de 2026)
  • Brain: el modelo y el bucle del harness
  • Hands: el entorno de ejecución temporal aislado donde realmente se ejecutan las herramientas
  • Session: un log de eventos append-only de todos los pensamientos, llamadas a herramientas y observaciones
• El enfoque central de Anthropic: “cada componente del harness codifica supuestos sobre lo que el modelo no puede hacer por sí solo”; si todo está acoplado, hay que cambiar el sistema completo cuando esos supuestos quedan obsoletos, mientras que al separarlos, el harness se vuelve stateless y el sandbox puede tratarse como cattle
• Un contenedor nuevo puede llamar a wake(sessionId) y reconstruir el estado desde el log. El time-to-first-token cayó cerca de 60% en p50 y más de 90% en p95, porque ahora se puede empezar a razonar antes de que el sandbox esté listo
• El concepto de session-event-log es la parte más subestimada. Es la clave para hacer recuperables a los agentes de larga ejecución. Sin eso, una falla del contenedor se convierte directamente en una falla de sesión
• Stack para cómputo científico: CLAUDE.md (plan vivo que el agente aprende y edita), CHANGELOG.md (bitácora de laboratorio portable), tmux + SLURM + git (capa de ejecución y coordinación), bucle Ralph (reconfirmación cuando afirma haber terminado)
  • Caso representativo: Claude Opus construyó durante varios días un solver de Boltzmann que logró un error menor al 1% frente a la implementación de referencia CLASS, comprimiendo meses o años de trabajo de investigación

Cursor: estructura Planner, Worker, Judge

• En la expansión de la programación autónoma de larga duración de Cursor hubo tres iteraciones de diseño
  • Primera (coordinación plana): agentes en igualdad de condiciones escribiendo en archivos compartidos con locks → surgieron cuellos de botella y los agentes empezaron a comportarse de forma demasiado conservadora, generando churning (iterar sin comprometer cambios)
  • Segunda (control de concurrencia optimista): resolvió los cuellos de botella, pero no el problema de coordinación
  • Tercera (producción actual): Planner (explora la base de código y genera tareas, con capacidad de lanzar subplanners de forma recursiva), Worker (ejecución enfocada, tareas independientes sin coordinarse entre sí), Judge (decide si la iteración terminó y si debe reiniciarse)
• Hallazgo clave: “una proporción sorprendentemente grande del comportamiento del sistema depende más del prompt que del harness o del modelo”
• El match entre modelo y rol también es parte de la superficie de diseño: los modelos GPT son mejores que Opus en trabajo autónomo prolongado. Opus tiende a detenerse antes y elegir atajos. Misma tarea, distinto rol, distinto modelo
• Composer 2 (modelo frontier de coding propio) y agentes cloud en background: las tareas largas ya no corren localmente sino en la infraestructura cloud de Anysphere. Refactors de 8 horas y migraciones de toda la base de código siguen ejecutándose aunque cierres la laptop
  • Empieza localmente y, si se estima que tardará más de 30 minutos, cambia al cloud; luego se puede retomar desde móvil
  • Cada agente corre en un git worktree aislado y se fusiona por medio de PRs
• La estructura final se parece a la de Anthropic: separación de roles, persistencia de sesión, un judge junto al worker, y tareas largas en sandboxes cloud con coordinación basada en git

Google: agentes de larga ejecución en Agent Platform

• En Cloud Next '26, Vertex AI se integró como Gemini Enterprise Agent Platform, convirtiendo a los agentes de larga ejecución en un producto formal con SLA definido
• Agent Runtime: soporta “ejecución autónoma durante días”, con cold start subsegundo y aprovisionamiento de sandboxes on demand. Un caso de uso de ejemplo es una secuencia de prospección comercial que dura una semana
• Agent Sessions: persistencia del historial de conversación y eventos. Es posible mapear un ID de sesión personalizado a un registro de CRM o BD para guardar el estado del agente junto con el estado del negocio
• Agent Memory Bank: capa de memoria de largo plazo en GA (lanzamiento general) a la fecha de Next '26. Curaduría de memoria desde las sesiones, con scope por ID de usuario y API de búsqueda. En el caso de Payhawk, un agente basado en Memory Bank redujo en más de 50% el tiempo de envío de gastos
• Agent Sandbox (ejecución de código reforzada), Agent-to-Agent Orchestration, Agent Registry, Agent Identity, Agent Gateway, Agent Observability, Agent Simulation y más cubren casi todas las preocupaciones necesarias para operar en producción. Incluye identidades cifradas y logs de auditoría requeridos en entornos empresariales
• A nivel arquitectónico, es la misma separación brain/hands/session de Anthropic, pero productizada a escala de plataforma, junto con ADK (kit de desarrollo code-first) y Agent Studio (herramienta visual). Lo que hace 3 años había que construir a mano ahora es una cuestión de elegir “qué versión de la separación brain/hands/session vas a tomar prestada”

Cinco patrones para agentes de larga ejecución en producción

• Checkpoint-and-resume: la falla multidiaria más común es la pérdida de contexto. Si después de procesar 200 documentos hay un error en el 201, sin checkpoint hay que reiniciar desde cero. Hay que tratar al agente como un proceso server de larga duración: guardar estado intermedio en disco, checkpoint cada N unidades de trabajo y recuperación ante fallas. Lo clave es decidir el granulado correcto del checkpoint: ni en cada paso ni solo al final
• Delegated approval (human-in-the-loop): en implementaciones tradicionales se serializa el estado a JSON → webhook → espera de respuesta, pero el estado se vuelve stale y las notificaciones se pierden. En un runtime de larga ejecución, el agente puede pausarse conservando toda la cadena de razonamiento, memoria de trabajo, historial de herramientas y acciones pendientes. Durante la revisión humana, el consumo de cómputo es cero, y la reanudación ocurre con latencia subsegundo. Mission Control de Google sirve como bandeja de entrada para esto
• Memory-layered context: un agente que corre 7 días necesita algo más que estado de sesión. Memory Bank (memoria curada de largo plazo) + Memory Profiles (consulta de baja latencia). El modo de falla en producción es memory drift: el agente aprende atajos procedimentales a partir de interacciones no estructuradas y los aplica en exceso. Hay que gobernar la memoria como si fuera un microservicio. Agent Identity (permisos de lectura/escritura), Agent Registry (seguimiento de versiones del agente), Agent Gateway (aplicación de políticas)
• Ambient processing: agentes que no conversan con humanos, sino que reaccionan a eventos de streams Pub/Sub o tablas de BigQuery (moderación de contenido, detección de anomalías, clasificación de bandejas de entrada). Si la política se define en Gateway y no se codifica en el agente, se puede aplicar un cambio de política a cientos de agentes sin redespliegue
• Fleet orchestration: en sistemas reales no suele haber un solo agente, sino un coordinador que delega subtareas a especialistas (Lead Researcher Agent, Scoring Agent, Outreach Agent). Cada especialista tiene su propia Identity (por ejemplo, el Outreach Agent no puede acceder a datos financieros usados por Scoring), sus propias políticas y su propia entrada en Registry. ADK lo maneja de forma declarativa con workflows basados en grafos
• Estos patrones pueden combinarse. Ejemplo de sistema de compliance: checkpointing para procesamiento documental + aprobación delegada en gates de revisión + capas de memoria entre sesiones + orquestación de flota para coordinar especialistas

Cómo construirlo en la práctica

• Desarrolladores que quieren tareas largas de coding en su propio repo: usar Claude Code, Antigravity, Cursor, Codex, etc. Mantener AGENTS.md como una checklist piloto (corta, solo con puntos obtenidos de fallas reales). Agregar hooks de typecheck y lint, escribir un archivo de plan antes de empezar y, cuando el agente diga que terminó, reconfirmarlo con el bucle Ralph. Para trabajo de varias horas o nocturno, correrlo en un worktree para que siga aunque cierres la laptop, y hacer commits por unidades de trabajo significativas. Es la ruta de mayor palanca para la mayoría de las personas
• Construcción de un producto de agentes hospedados: no construir tu propio runtime si puedes elegir uno managed. Hoy hay tres opciones prácticas: Google Agent Platform (Agent Engine + Memory Bank + Sessions), Claude Managed Agents, o self-hosting sobre ADK, Claude Agent SDK o Codex SDK. Las opciones managed ya traen separación brain/hands/session, observabilidad, identidad y auditoría. El self-hosting da más control y permite usar modelos especiales
• Trabajo autónomo y operativo (monitoreo, research, operaciones): se necesita persistencia estilo Memory Bank. ADK + Memory Bank + Cloud Run + Cloud Scheduler es el stack más limpio para “ejecutar un agente cada N horas, acumular estado y alertar por umbral”

Prácticas clave sin importar la ruta

• Definir por escrito la condición de finalización antes de arrancar el agente: es la palanca más importante en larga ejecución. Escribir criterios de finalización explícitos y testeables en un archivo externo evita que el agente redefina “terminado” mientras trabaja
• Separar evaluador y generador: la autoevaluación es un modo de falla central. Un pipeline planner/worker/judge o una pareja generator/evaluator no es estilo, sino un patrón arquitectónico real. Incluso con el mismo modelo, conviene separarlos por rol y prompt
• Invertir en el log de sesión, no en el prompt: un log de eventos append-only hace que el agente sea recuperable, depurable y auditable. Si no puedes reconstruir desde almacenamiento persistente lo que hizo el agente durante las últimas 24 horas, no tienes más que un script shell de larga duración que llama a un LLM
• Tratar la compresión y el reset de contexto como ciudadanos de primera clase: Anthropic encontró que, en tareas muy largas, la compresión basada solo en resúmenes no bastaba; el harness necesitaba desmontar la sesión por completo y reconstruirla desde archivos de handoff estructurados. En esencia, es lo mismo que hacer onboarding a un nuevo ingeniero

Límites prácticos actuales

• Costo: correr 24 horas con modelos frontier es caro. Sin presupuesto, circuit breakers y hard caps para gasto en herramientas, es fácil quemarse el presupuesto semanal de API en una sola tarde
• Seguridad: un agente de larga ejecución con API keys, acceso cloud y permisos para ejecutar comandos shell tiene una superficie de ataque mucho mayor que una sesión de chat. Por eso importa la separación brain/hands: el código generado por el modelo debe ejecutarse en un sandbox sin acceso a credenciales
• Alignment drift: el agente se desvía al pasar por múltiples ventanas de contexto. El objetivo original se resume, se vuelve a resumir y pierde fidelidad. Los hooks y el judge existen para defenderse de esto, y es la causa más común de que “el agente haga algo que no se le pidió”
• Verificación: auditar 24 horas de actividad autónoma sigue siendo un problema de tiempo humano real. La observabilidad y los outputs estructurados (PR, commits, briefings, test runs) son la forma de volverlo tractable
• Rol humano: definir una tarea con el nivel de precisión necesario para que un agente trabaje un día entero es más difícil que hacer la tarea directamente. La habilidad que más valor gana no es escribir código, sino escribir especificaciones que sobrevivan al contacto con un ejecutor autónomo

Hacia dónde va todo esto

• Google, Anthropic y Cursor están convergiendo hacia la misma estructura: separación entre bucle del modelo, sandbox de ejecución y log de sesión, separación entre planificación, generación y evaluación, compresión, hooks y resets de contexto integrados, y memoria expuesta como servicio managed
• Las diferencias son superficiales: Google Agent Platform es un stack empresarial (con identidad y auditoría integradas), Claude Managed Agents es la “versión hosteada del harness de Anthropic”, y los agentes de background de Cursor son “coding de larga duración llevado del IDE al cloud”
• El problema más difícil del próximo año no estará en las capas individuales, sino en la coordinación sobre ellas: operar múltiples agentes de larga ejecución sobre una base de código compartida, agentes que lean sus propios traces y parcheen su propio harness, y harnesses que ensamblen herramientas y contexto JIT (just-in-time) según la tarea
• El modelo sigue siendo central, pero la brecha entre una ventana de chat y un agente capaz de trabajar toda la noche está sobre todo en estado, sesión y handoffs estructurados, y ahí es donde hoy vale la pena invertir tiempo de aprendizaje

[jjpark78]

Empecé a usar hermes para resolver este problema y no me ha parecido nada mal jaja