Cuando el agente falla: corregir, cambiar de enfoque o rendirse

Para principios de mayo el sistema ya sabía detectar que un trabajo estaba mal. Lo que hacía a continuación era, básicamente, nada: frenaba la cadena y me esperaba.

Eso convierte al orquestador en una herramienta que solo funciona mientras estás mirando. Podía dejarlo corriendo diez minutos, no una tarde. Y el problema no era técnico: era que no había decidido qué debía pasar después de un veredicto negativo.

El 5 de mayo me senté a resolver eso, y es el día en que el proyecto dejó de ser un lanzador con controles y pasó a tener una arquitectura propia.

Separar al que hace del que evalúa

El primer cambio fue estructural: separar explícitamente dos roles. Uno genera el trabajo, otro lo evalúa. No es una sutileza organizativa — cambia qué información viaja entre los pasos.

Mientras el evaluador devuelve "aprobado" o "rechazado", lo único que podés hacer con un rechazo es volver a intentar a ciegas. Si en cambio devuelve retroalimentación estructurada, el sistema puede decidir qué hacer con ella.

La evaluación pasó a ser multidimensional. En vez de un veredicto único, cuatro ejes: corrección, seguridad, experiencia de usuario y completitud. Cada uno con su puntaje. Y algo que resultó más útil de lo que esperaba: detección de regresiones respecto de intentos anteriores, para distinguir el caso "sigue mal" del caso "está peor que antes", que son problemas distintos.

Tres caminos, no uno

Con esa información encima, el sistema elige entre tres salidas. Esta es la parte que creo que falta en la mayoría de los orquestadores, donde el manejo de fallas se reduce a reintentar.

• Corregir: el trabajo está encaminado pero incompleto o con defectos puntuales. Se vuelve al mismo implementador con la retroalimentación específica de qué arreglar.
• Cambiar de enfoque: el trabajo está mal encarado. No alcanza con corregir sobre lo hecho, porque el punto de partida es el problema. Se devuelve la tarea un paso más arriba en la cadena.
• Rendirse: después de tres intentos, el sistema deja de insistir.

Rendirse no es fallar en silencio, que sería lo peor de los dos mundos. Escribe un reporte estructurado del incidente: qué se intentó, con qué retroalimentación, en qué dimensiones falló cada vez. Ese reporte queda guardado y es material para revisar después.

De hecho, mirando la pila de esos reportes acumulados fue como se me ocurrió la idea más ambiciosa del proyecto, que es el tema de la próxima entrega y que salió bastante peor de lo que esperaba.

El error que tardé un mes en ver

Hay un detalle de esta implementación que estuvo mal durante un mes entero y que ilustra bien lo fácil que es desperdiciar contexto sin darse cuenta.

Cuando el sistema decidía corregir, relanzaba al implementador. Pero al hacerlo descartaba la sesión anterior. El agente volvía a empezar de cero: sin memoria de qué archivos había tocado, qué caminos había descartado ni por qué había tomado las decisiones que tomó. Lo único que recibía era un texto con la retroalimentación del evaluador.

Dicho de otra forma: le pedía que corrigiera un trabajo del que no se acordaba.

La corrección, cuando finalmente la vi, fue de una línea: conservar la sesión cuando la decisión es corregir, y descartarla solamente cuando se cambia de enfoque, que es el único caso donde el olvido es deliberado —ahí querés que el modelo arranque sin el sesgo del intento fallido—.

Lo que hace segura esa decisión es un límite que ya existía: como la rendición corta al tercer intento, una corrección con la sesión viva puede ocurrir dos veces como máximo. El contexto no crece indefinidamente, tiene un techo estructural.

Distinguir los fallos que no son del agente

Otra cosa que aprendí operando esto: no todos los fallos son culpa del que trabaja.

Cuando la API del proveedor devolvía un error de red, el sistema lo contaba como un intento fallido. El agente no había hecho nada mal — ni siquiera había llegado a empezar— pero se le consumía uno de sus tres intentos. Con dos cortes de red seguidos, una tarea perfectamente sana llegaba a la rendición sin que nadie hubiera evaluado nada.

Hoy esos errores no consumen intento y se reintenta con espera creciente. Penalizar al modelo por una caída de infraestructura es, sencillamente, medir mal.

El cuarto camino

En agosto agregué una salida más, para un caso que no había previsto: el cambio de enfoque imposible.

A veces el evaluador determina que el trabajo está mal encarado, pero devolverlo un paso arriba no tiene sentido porque ese paso anterior no existe o ya se agotó. Antes eso caía directo en rendición. Ahora, en vez de abandonar, el sistema vuelve a explorar el terreno: relanza el reconocimiento del código para reconstruir el contexto y reintenta desde ahí.

Es un ejemplo de algo que se repite en todo el proyecto: las políticas de fracaso no se diseñan bien de entrada. Se descubren operando, cuando aparece el caso que no encaja en ninguna de las salidas que habías previsto.

Lo que se gana con esto

Un sistema con agentes necesita una política de fracaso tan explícita como su camino feliz. Y esa política tiene que distinguir tres cosas que a primera vista se parecen: el trabajo que está cerca y merece otra pasada, el que está mal encarado y necesita volver atrás, y el que hay que dejar en manos de una persona.

Reintentar sin esa distinción es tirar dinero: repetís el mismo error con la misma información y esperás un resultado distinto. Y no distinguir la rendición del resto es peor todavía, porque perdés el único caso que realmente merecía tu atención.

Con las tres salidas implementadas, el sistema empezó a resolver solo la mayoría de sus propios tropiezos. Y quedaron, como sedimento, los reportes de los que no pudo resolver.

Esa pila de reportes fue el punto de partida de lo que viene: pedirle al sistema que se mejore a sí mismo.