Agente = Modelo + Harness: lo que aprendimos poniendo agentes en producción

Hay una fórmula que circuló mucho este verano y que resume bastante bien nuestra experiencia de los últimos dos años: agente = modelo + harness. El modelo es la parte que no controlás. El harness es todo lo demás: las instrucciones, las herramientas, los límites, las validaciones, la memoria y los mecanismos que detectan cuándo algo salió mal.

Lo interesante del planteo es la inversión de responsabilidades. Durante un tiempo se esperó que el modelo se hiciera cargo de la seguridad, de la precisión al ejecutar, de recordar lo importante y de coordinar tareas largas. La conclusión de la industria fue la contraria: al modelo se lo trata como una calculadora de razonamiento congelada, y todo lo demás lo resuelve la infraestructura que lo rodea.

Qué hay en nuestro harness

Cuando arrancamos con agentes que tocan sistemas reales de clientes, el primer instinto fue escribir mejores prompts. Sirvió poco. Lo que movió la aguja fue construir la estructura alrededor.

Un contrato escrito. Tenemos un archivo de reglas que todo agente lee antes de trabajar sobre el repositorio. No son sugerencias de estilo: son prohibiciones concretas nacidas de errores que ya pagamos. "Nunca sincronices a producción a mano." "Nunca borres registros de verdad, usá borrado lógico." "Nunca arranques procesos por afuera del gestor." Cada línea de ese archivo existe porque algo se rompió una vez.

Herramientas acotadas. Un agente que puede hacer cualquier cosa hace cualquier cosa. Los nuestros tienen un catálogo chico de acciones, cada una con su validación, y cuando necesitan algo que no está en el catálogo tienen que pedirlo.

Verificadores. Después de cada tarea corre una comprobación que no depende del agente: el sitio responde, el test pasa, el archivo existe. Si el agente dice "listo" y el verificador dice que no, gana el verificador.

Un punto de aprobación humana. Las acciones que no se pueden deshacer se detienen y esperan. No porque el agente sea torpe, sino porque el costo de equivocarse es asimétrico.

La parte incómoda

Se dice que la enorme mayoría de los proyectos con agentes no llega nunca a producción. Nuestra lectura, después de haber estado de los dos lados, es que casi siempre fallan en el harness y casi nunca en el modelo. Cambiar de modelo es una tarde. Construir el andamiaje que lo hace confiable es el trabajo.

Eso también es una buena noticia para quien construye: la parte que define la calidad del resultado es justo la parte que sí controlás.

Cómo se ve esto en un cliente

En nuestro webmaster por chat, el cliente pide un cambio en su sitio y el cambio sale publicado en minutos. Detrás de esa simpleza hay un harness bastante aburrido: el pedido se interpreta, se traduce a una tarea concreta, se aplica en un entorno de trabajo separado, se verifica que el sitio siga respondiendo, y recién ahí se publica. Si algo falla en el medio, se revierte y avisa.

El cliente no ve nada de eso. Ve que pidió algo y funcionó. Esa distancia entre lo que el usuario percibe y lo que hay abajo es, más o menos, la definición del oficio.