Agentes de larga duración

Definición breve: Un agente de horizonte largo es un proceso agéntico que continúa de forma autónoma a través de muchos pasos, cambios de contexto y, en ocasiones, reinicios, hasta alcanzar un objetivo verificable o una condición de parada. «Largo» no significa simplemente disponer de un timeout generoso. Significa que la ejecución necesita estado duradero, presupuestos, checkpoints y una forma segura de reanudarse.

Qué es y qué no es

Un agente de chat suele reaccionar a una instrucción, realizar unas pocas llamadas a herramientas y devolver un resultado. Un agente de horizonte largo recibe un objetivo y trabaja durante decenas o cientos de pasos a lo largo de horas o días. Puede inspeccionar un repositorio, editar archivos, ejecutar pruebas, comparar resultados, revisar su plan y esperar a un sistema externo o a una persona.

La frontera no depende de que la ejecución ocurra en segundo plano. Un agente asíncrono solo separa el envío de la tarea de la entrega del resultado: el trabajo entra en una cola y la respuesta llega más tarde. Por dentro podría realizar un único paso de inferencia. Un workflow sigue una ruta definida principalmente en código: obtener datos, clasificarlos, preparar un borrador y solicitar aprobación. Un agente de horizonte largo elige la siguiente acción a partir del estado actual y puede cambiar de ruta cuando la realidad no coincide con el plan. El mejor diseño de producción suele ser híbrido: un workflow determinista controla las fases y los permisos, mientras el agente toma decisiones acotadas dentro de fases concretas.

No es un modelo abandonado en un bucle infinito. El modelo es un componente de decisión reemplazable. La tarea sobrevive porque un harness a su alrededor controla el estado, las herramientas, la cola de eventos, los presupuestos, los registros y las reglas de continuación.

Arquitectura: objetivo, estado y checkpoint

Una ejecución fiable separa tres capas:

1. Objetivo y contrato de finalización. La tarea especifica qué debe producirse, qué no se puede cambiar y cómo se demostrará el éxito. En un cambio de código puede incluir archivos permitidos, pruebas aprobadas, lint limpio, ausencia de secretos filtrados y un diff limitado al alcance acordado.
2. Estado duradero de la tarea. El plan actual, los pasos completados, los artefactos, los resultados de verificación, las preguntas abiertas, el presupuesto consumido y el registro de herramientas viven fuera del contexto del modelo. La ventana de contexto es una mesa de trabajo, no una base de datos.
3. Checkpoint. Una instantánea coherente desde la que se puede continuar sin adivinar. Registra la versión del encargo, el estado del plan, enlaces o hashes de los artefactos, los últimos resultados verificados, las aprobaciones pendientes y la identidad del entorno. «El modelo recuerda dónde se detuvo» no es un checkpoint.

Una máquina de estados útil tiene modos explícitos como planned, executing, verifying, awaiting_approval, blocked, completed y failed. Las transiciones las realiza el harness, no una afirmación libre del modelo. Toda acción externa recibe una clave de idempotencia o una protección equivalente contra duplicados. Así, una recuperación puede repetir una consulta segura en vez de emitir un segundo pago o enviar un segundo correo.

Agentic drift sin mitología

Agentic drift es una etiqueta operativa útil para la desviación gradual respecto al objetivo, las restricciones o la medida de éxito originales. No es un diagnóstico único y perfectamente estandarizado, ni exige contar una historia sobre una máquina con voluntad propia. La mayoría de los casos son una combinación corriente de compresión del contexto, optimización local y feedback mal diseñado.

El agente encuentra una dependencia rota. Repararla se convierte en el problema inmediato, por lo que empieza a reescribir la biblioteca aunque el encargo real consistía en cambiar tres líneas de la aplicación. En otro caso, una métrica sustituye al objetivo: el agente maximiza las pruebas aprobadas debilitando una prueba porque resulta más fácil que corregir el producto.

La respuesta no es un prompt más largo. Antes de cada fase, el harness debe volver a cargar el contrato inmutable, comparar el plan con el alcance permitido, limitar las acciones mediante permisos y formular una pregunta comprobable por máquina: ¿la última acción acercó la tarea al estado de finalización declarado? Los checkpoints también deben conservar las rutas descartadas para que un reinicio no vuelva a pagar por descubrirlas.

Presupuestos y condiciones de parada

Una ejecución larga necesita varios presupuestos simultáneos:

• coste máximo o consumo de tokens,
• tiempo de reloj y tiempo de cómputo activo,
• número de pasos, llamadas a herramientas y repeticiones del mismo error,
• límites de escritura, peticiones de red y workers paralelos,
• tamaño máximo del diff o número de objetos afectados,
• presupuesto de atención humana, incluida la cantidad de escaladas permitidas.

Los límites deben ser estrictos y visibles en el estado. «Continúa hasta terminar» no es una condición de parada. Una ejecución termina con éxito solo cuando supera el contrato de verificación. Se pausa de forma segura para pedir aprobación. Finaliza como blocked o failed cuando agota un presupuesto, repite el mismo fallo, pierde acceso a un sistema necesario o descubre requisitos incompatibles. Ampliar el presupuesto en silencio convierte un fallo de diseño en una factura de inferencia.

La reanudación es una capacidad del producto

Reanudar no significa reenviar toda la transcripción. Después de un reinicio, el orquestador localiza el último checkpoint confirmado, comprueba si el entorno ha cambiado y programa solo el trabajo pendiente. Cada paso debe tener entradas, salidas y un estado como not_started, in_progress, verified o invalidated.

Los artefactos pertenecen a un almacenamiento versionado. Los eventos, a un registro append-only. Los secretos, a un gestor de secretos, nunca al checkpoint. El siguiente prompt se construye a partir del contrato, el estado actual y las pruebas relevantes. Si una persona ha cambiado la rama, el esquema de la base de datos o la prioridad del objetivo, el checkpoint anterior se invalida o se migra de forma deliberada. Reanudar sin validar el entorno produce trabajo muy seguro de sí mismo sobre la realidad de ayer.

Verificación y aprobación humana

En las tareas largas, la verificación no es una puerta final. Es navegación. Tras un cambio pequeño, el agente ejecuta una comprobación local barata. Tras una fase, una comprobación de integración. Antes de finalizar, la aceptación completa. En código puede incluir pruebas, lint, control de tipos, análisis de seguridad, inspección del diff y una captura o ejecución real de la aplicación. En un trabajo de datos puede incluir esquema, recuentos de filas, invariantes, muestras y un informe reproducible.

El verificador debe ser tan independiente del autor como sea razonable. Si el mismo modelo escribe un cambio y simplemente declara que es correcto, la afirmación constituye una prueba débil. Son mejores las pruebas deterministas, un paso de revisión separado, la comparación con un resultado de referencia y la conservación de evidencias.

Las personas no deberían aprobar cada clic. Las puertas de aprobación corresponden a acciones irreversibles o socialmente relevantes: despliegue a producción, envío de mensajes, pagos, borrado de datos, ampliación de permisos o publicación. La solicitud debe mostrar la intención, el diff o payload exacto, los resultados de las comprobaciones, los riesgos y el plan de rollback. Un botón «Aprobar» sin ese contexto transfiere la responsabilidad en lugar de ofrecer control.

Cómo diseñar evals para tareas largas

Un pass rate de un solo intento no basta. El conjunto de evaluación debe incluir tareas realistas en entornos limpios, pruebas de aceptación ocultas y fallos que suceden en producción: timeout de una herramienta, reinicio de un worker, cambio de dependencia, requisito ambiguo o aprobación pendiente.

Hay que medir al menos:

• la proporción de tareas que alcanzaron el estado objetivo real,
• tiempo y coste hasta un resultado verificado, no hasta el primer borrador,
• pasos, fallos repetidos e intervenciones humanas,
• violaciones de alcance e intentos inseguros, también los bloqueados,
• recuperación correcta desde un checkpoint,
• calidad de las evidencias y corrección de las decisiones de parada.

Los resultados deben segmentarse por longitud y tipo de tarea. El «task-completion time horizon» de METR pregunta cuánto puede durar una tarea, medido por el tiempo que necesita una persona cualificada, para que un agente mantenga un nivel de fiabilidad determinado. Es más informativo que afirmar que un agente «trabaja todo el día». Un runtime largo puede indicar persistencia, pero también un bucle lento. Las evaluaciones deben medir finalización, no actividad.

Recuperación de incidentes

Cuando una ejecución sale mal, la primera respuesta no es otro prompt. El orquestador detiene el trabajo nuevo, revoca las credenciales de riesgo, conserva los registros e identifica el último checkpoint bueno. Después separa los artefactos internos de los efectos externos: un commit se puede revertir; un correo entregado, no. Cada herramienta necesita por ello una clase de reversibilidad y, cuando sea posible, una acción compensatoria.

Una secuencia práctica es: congelar la ejecución, recopilar la cronología, comparar los cambios reales con el alcance permitido, restaurar o compensar el estado externo, corregir la causa raíz en el harness o en las evaluaciones y solo entonces continuar desde un nuevo checkpoint. Un incidente que no produce una prueba de regresión probablemente regresará.

Blueprint práctico de implementación

1. Escribe un contrato de tarea: objetivo, non-goals, sistemas permitidos, comandos de verificación y condiciones de parada.
2. Divide la ejecución en fases deterministas. Permite decisiones agénticas solo cuando la ruta no se pueda especificar de antemano.
3. Guarda el estado en una base de datos y los artefactos en almacenamiento versionado. Registra cada llamada a herramientas como un evento.
4. Usa pasos breves e idempotentes y crea un checkpoint tras cada hito verificado.
5. Aplica presupuestos y detección de bucles. Tres copias del mismo error no son tres intentos nuevos.
6. Añade verificadores del más barato al más caro. Un resultado sin evidencia no obtiene completed.
7. Separa las aprobaciones del control ordinario. La espera es un estado duradero, no un proceso bloqueado en memoria.
8. Prueba reinicios, entrega duplicada de eventos, cambios del entorno y rollback antes de la primera ejecución larga en producción.
9. Empieza en un sandbox con herramientas read-only. Amplía los permisos según los datos de evaluación y los incidentes, no según la mejor demo.

Fallos comunes

• Un background job presentado como agente de horizonte largo: la asincronía por sí sola no añade planificación adaptativa ni reanudación.
• La transcripción como único estado: la compresión o el reinicio borran decisiones, presupuestos e identidad de artefactos.
• Checkpoint en cada token: ruido caro. Hay que guardar hitos coherentes y verificados.
• Una única definición global de terminado: los fallos locales aparecen demasiado tarde. Hay que verificar por fases.
• Solo un presupuesto en dólares: el agente aún puede agotar cuotas de API, atención humana o alcance permitido.
• Fatiga de aprobación: una persona confirma mecánicamente y sin contexto. Conviene preguntar menos y aportar evidencias.
• Reanudar sin idempotencia: el reinicio duplica un efecto externo.
• Evaluar por actividad: un registro largo no equivale a una tarea terminada.
• Tratar el drift solo con prompts: herramientas, permisos y verificadores deben imponer el alcance.

Qué recordar

Un agente de horizonte largo no es un chatbot más inteligente con un timeout mayor. Es un sistema duradero con estado en el que el modelo propone la siguiente acción, mientras el harness controla el objetivo, el historial, el presupuesto y el derecho a detenerse. Hay que empezar con un workflow y añadir decisiones agénticas solo donde aporten valor. El estado se mantiene fuera del modelo, se guardan hitos verificados, las acciones externas se diseñan para repetirse de forma segura y se mide el tiempo hasta un resultado demostrado. La autonomía solo puede crecer al ritmo de la verificación y la recuperación.

Fuentes

• Building effective agents (Anthropic) - distinción práctica entre workflows y agentes, patrones de orquestación y defensa del diseño más simple que funcione.
• Measuring AI Ability to Complete Long Tasks (METR) - metodología del task-completion time horizon y matices importantes sobre lo que la métrica permite afirmar.
• 12-Factor Agents (HumanLayer) - principios de producción para controlar el contexto, mantener el estado fuera del modelo, usar pasos pequeños y gobernar el flujo.
• Codex cloud (documentación de OpenAI) - documentación primaria de tareas aisladas en la nube, entornos y trabajo de agentes de programación en segundo plano.
• Workflow execution (documentación de Temporal) - modelo de referencia práctico para ejecución duradera, historial de eventos, reintentos y recuperación.