Un agente que lo hace todo no hace nada bien

Tu agente no termina de ser lo bastante bueno, así que haces lo obvio: le das más. Otra herramienta para lo que no pudo hacer. Unas líneas más en el prompt para cubrir el caso que falló. Más contexto para que tenga todo lo que pudiera necesitar. Cada agregado es razonable. Cada uno empeora un poco al agente.

Este es el resultado contraintuitivo que me tomó un tiempo creer, y no es cuestión de gustos — está medido. El camino hacia un agente capaz va en la dirección opuesta al instinto: no más, sino menos.

Más lo empeora, y aquí está la prueba

Un modelo de lenguaje tiene un presupuesto fijo de atención. Todo lo que pones en su ventana de contexto — cada descripción de herramienta, cada instrucción, cada documento recuperado — compite por ese mismo presupuesto. Pasado cierto punto, agregar información no le da al modelo más con qué trabajar; diluye lo que ya estaba ahí.

La investigación al respecto es contundente. Los modelos de contexto largo sufren un efecto bien documentado de "lost in the middle" (perdido en el medio): las instrucciones enterradas en medio de un prompt largo se siguen peor que esas mismas instrucciones en uno corto. Un análisis encontró que la precisión caía de 92% a 63% puramente por sobrecarga de contexto — mismo modelo, misma tarea, solo demasiado en la ventana. Las herramientas se comportan igual: amontona veinte herramientas en un solo agente y empieza a llamar a la equivocada la mitad de las veces, olvidando la instrucción que estaba al inicio de su contexto para cuando está metido a fondo en una tarea, y convirtiendo una mala llamada en una cascada de tres más.

Este es el patrón god-agent (agente-dios), y tiene una firma: deslumbra en la demo y se desmorona en producción. En la demo corres la única ruta que ensayaste. En producción los flujos reales, largos y ramificados, chocan contra la pared de la dilución cada vez.

La solución tiene cuarenta años

La cura no es un prompt ingenioso ni un modelo más grande. Es el Principio de Responsabilidad Única (Single Responsibility Principle), la misma regla que ya aplicamos a funciones y clases: un agente, un trabajo. Dale a cada agente una única responsabilidad bien definida, las tres o cuatro herramientas que ese trabajo realmente necesita, y solo el contexto relevante para él. Ahora nada compite por el presupuesto de atención, porque no hay nada de más en la ventana. Cada agente es excelente en su única cosa precisamente porque no intenta ser bueno en otras nueve.

Los números se mueven con fuerza en esta dirección. La evaluación de Chroma encontró una gran brecha de precisión entre un prompt enfocado de ~300 tokens y uno inflado de ~113K tokens; se ha medido que los agentes genéricos de un-solo-propósito-estirado-a-todo tienen éxito solo alrededor del 58% de las veces, cayendo aún más a medida que la tarea se dispersa. Acota el alcance y el mismo modelo subyacente se vuelve dramáticamente más confiable, porque dejaste de hacerlo elegir.

Ya aprendimos esta lección, con el código

Aquí está la parte que debería hacer asentir a cualquier ingeniero. No escribimos una función de diez mil líneas con doscientas ramas y la llamamos poderosa — la llamamos inmantenible, y la partimos en funciones pequeñas que cada una hace una sola cosa. No construimos una clase que lo hace todo; la descomponemos. Un god-agent es justo ese antipatrón con una gabardina puesta: un único componente al que se le pide sostener cada preocupación a la vez, fallando por la misma razón por la que falla la función gigante — demasiado en un solo lugar, sin separación, cada parte interfiriendo con todas las demás.

Así que el movimiento es el movimiento que ya conocemos. La descomposición no es una nueva "técnica de agentes". Es el mismo instinto que produjo la responsabilidad única, las unidades pequeñas y los límites limpios, aplicado a un nuevo tipo de componente. La razón por la que funciona es concreta, no estética: un agente enfocado tiene un contexto sin diluir, así que se mantiene en la tarea — del mismo modo que una función enfocada es una que realmente puedes leer.

Y los efectos secundarios son exactamente los que quieres. Un agente de un solo trabajo es testeable — puedes escribir una eval para "¿hace su única cosa?", algo que simplemente no puedes hacer con un agente-que-lo-hace-todo de veinte herramientas. Es más barato, porque un trabajo acotado y bien definido a menudo corre bien en un modelo más chico. Y es depurable, porque cuando algo se rompe sabes qué agente era dueño de esa responsabilidad.

La trampa honesta

Partir un agente en diez no hace desaparecer el problema — lo cambia por otro distinto. Ahora tienes diez agentes enfocados que hay que coordinar: algo tiene que enrutar el trabajo, pasar resultados entre ellos y decidir qué corre cuándo. Esa capa de coordinación — la orquestación — es ingeniería de verdad, y es un post aparte.

Pero fíjate qué clase de canje hiciste. Cambiaste "mi agente olvidó sus instrucciones y llamó a la herramienta equivocada" — una falla dentro de una caja negra que no puedes arreglar — por "necesito coordinar componentes" — un problema de ingeniería corriente con respuestas de ingeniería corrientes. Uno de esos es tratable. El otro es solo el god-agent empeorando a medida que le agregas más.

El impulso de hacer que un agente lo haga todo es el impulso de saltarse la descomposición, y falla para los agentes por la misma razón por la que siempre falló para el código. Haz cada agente lo bastante pequeño como para ser excelente. Una cosa, bien hecha, le gana a diez cosas hechas al 58%.