¿Cuándo debería detenerse un agente?

Agentes y límites — 09

Cuando un agente no consigue terminar una tarea, la primera idea puede ser darle un poco más de tiempo. Una llamada más a una herramienta, otro intento, un modelo más potente…

A veces continuar ayuda. Otras veces rodeamos la misma incertidumbre de más procesamiento. El sistema sigue moviéndose, pero no sabemos si se acerca a resolver la tarea.

Al trabajar en a2, detenerse se convierte por eso en una pregunta de diseño propia:

¿Qué razones deberíamos tener para dar el siguiente paso?

La respuesta cambia según el cumplimiento de la tarea, los recursos utilizados, las pruebas disponibles y la autoridad del agente.

¿Producir una respuesta termina el trabajo?

Pensemos en una tarea hipotética de correspondencia de datos. Hay que combinar los registros de dos archivos, separar los que no coinciden y conservar los conflictos.

Cuando el agente produce una salida, que el archivo sea legible permite superar una primera comprobación. Que contenga los campos en el formato esperado es otra. Pero si se han unido los registros equivocados, la tarea sigue sin estar bien resuelta.

Por eso a2 separa la validación de la salida de la comparación con un resultado esperado independiente. Si se proporciona una respuesta de referencia, puede comprobarse el resultado contra ella. Una comprobación limitada al formato no demuestra que la tarea sea correcta en su significado.

La decisión de detenerse también debe conservar esta distinción. Una respuesta final del modelo puede señalar el fin de la ejecución. Para aceptar el trabajo debemos saber, además, qué comprobaciones superó.

Evitar que las salidas inválidas se guarden en la memoria como resultados satisfactorios es uno de los mecanismos de a2 para mantener ese límite.

¿Cuándo tiene sentido repetir una acción?

El agente llamó a una habilidad de correspondencia y recibió un error. Propuso volver a llamar a la misma habilidad con las mismas entradas.

¿Qué cambiará en el segundo intento?

Un fallo temporal de conexión puede justificar un reintento. Pero repetir la misma transformación sobre los mismos datos no completa por sí solo una regla de correspondencia que falta.

En la ruta data run de a2, invocar una habilidad con argumentos idénticos está limitado a una vez por defecto. Intentar repetirla detiene la ejecución antes de otra petición al modelo. Las invocaciones fallidas también cuentan para ese límite.

Es posible utilizar la misma habilidad con entradas diferentes. El límite de repeticiones puede aumentarse explícitamente. No es una regla general aplicada a todos los flujos de a2; pertenece a una ruta de ejecución concreta.

Lo que valoro aquí es que repetir no sea un derecho automático. Las razones para otro intento deben hacerse visibles.

Aun así, este mecanismo no mide todo el progreso del agente. Volver al mismo punto con otras palabras o herramientas es un problema más amplio. El límite de repeticiones solo detecta una forma particular de ese problema.

Cuando se alcanza el límite de recursos

Los recursos asignados pueden agotarse aunque la tarea siga sin resolverse.

En a2, el límite de pasos acota el bucle. Cuando se configura un presupuesto de tokens, el agente principal y los agentes secundarios comparten un mismo registro de consumo. Delegar trabajo no reinicia el presupuesto. El consumo previo también se conserva al reanudar desde un punto de control.

El límite de tokens es flexible: una sola respuesta puede superar el presupuesto restante. El mecanismo bloquea las peticiones posteriores una vez registrado el consumo. Por eso no debe presentarse como un tope exacto de gasto.

También está el caso del consumo desconocido. Cuando el proveedor no facilita información de uso o esta es inválida, no se siguen haciendo peticiones bajo un presupuesto configurado.

La razón es sencilla: si no sé cuánto se ha consumido, no puedo calcular con fiabilidad lo que queda.

Una ejecución detenida por su presupuesto no debería considerarse terminada. El motivo de la parada debe conservarse junto a cualquier resultado parcial.

Si no sabemos si una acción ocurrió

A veces detenerse tiene más que ver con la incertidumbre sobre lo sucedido fuera del agente que con los recursos.

Supongamos que se inicia una llamada a una herramienta que modifica un archivo. Después se interrumpe el proceso. No tenemos un registro que confirme que la acción terminó.

Volver a ejecutar la misma llamada puede parecer fácil. Pero la acción podría haber ocurrido la primera vez. Repetirla podría producir una segunda modificación.

El mecanismo de puntos de control de a2 deja una marca de acción pendiente antes de las operaciones con herramientas. Al reanudar desde ese registro, la acción incierta no se repite automáticamente: la ejecución se detiene para revisión.

Esto no garantiza que cada acción ocurra exactamente una vez en toda circunstancia. Limita la continuación automática cuando el estado es incierto.

Hay una distinción parecida en la autorización. Gate puede bloquear una acción que requiere aprobación si esta falta. Bloquear una acción y detener la tarea entera son cosas diferentes. El agente puede avanzar por otra vía permitida, pero no debería usar otra herramienta para eludir una aprobación ausente.

Si no encontramos una vía compatible

Que se solicite una tarea no significa que las habilidades disponibles puedan realizarla.

En la ruta de planificación de a2, el modelo puede devolver un plan vacío si los contratos listados no permiten cumplir el objetivo o la petición es ambigua. No se guarda ningún archivo de plan ejecutable; la ejecución se detiene indicando que no se encontró un plan compatible. La llamada al modelo y los tokens ya consumidos se siguen contabilizando.

También aquí importa el límite: no es un mecanismo que reconozca de forma determinista todas las tareas no compatibles. El modelo puede proponer un plan equivocado; incluso un plan que cumple las restricciones estructurales puede interpretar mal el objetivo.

Por tanto, producir un plan y encontrar una vía adecuada al objetivo requieren comprobaciones distintas.

Decir «no puedo avanzar con las herramientas actuales» resulta útil cuando también muestra qué falta: ¿una regla de correspondencia, los datos necesarios, una habilidad apropiada o autoridad?

¿Qué debería quedar después de detenerse?

Los mecanismos actuales de a2 dividen esta pregunta en partes: límites de pasos, un presupuesto compartido, bloqueo de ciertas repeticiones, revisión de acciones inciertas y validación de la salida.

No demuestran que el agente se detenga en el momento correcto en todas las situaciones. a2 sigue en fase alfa de desarrollo; este artículo tampoco presenta una nueva evaluación de rendimiento.

La pregunta que sigue abierta para mí es qué dejan estas partes en manos del usuario.

¿Dónde se detuvo la ejecución? ¿Qué acción se realizó? ¿Cuál sigue siendo incierta? ¿Qué comprobaciones superó la salida disponible? ¿Qué debe cambiar para continuar?

Si esas preguntas tienen respuesta, el trabajo detenido puede retomarse. Se pueden aportar los datos que faltan, conceder autoridad, corregir una regla o elegir otro método.

Donde un agente se detiene, quiero que quede un rastro lo bastante claro para que una persona pueda continuar.

---

Nota de fuentes — 15 de octubre de 2026: El artículo se basa en el código existente de a2, su README, arquitectura y especificación técnica. Los ejemplos de correspondencia de datos y de modificación de archivo interrumpida son hipotéticos. No se realizó ninguna nueva llamada al modelo ni ejecución de evaluación para este artículo.

Página del proyecto a2 · Una idea se convierte en una herramienta funcional

Artículo anterior de la serie: Construir una serie fotográfica.