# Un agente que lo hace todo no hace nada bien

Cuando un agente no es lo bastante bueno, el instinto es darle más — otra herramienta, más instrucciones, más contexto. Eso lo empeora, y está medido, no es cuestión de gustos. La solución es la regla más vieja de la ingeniería: Responsabilidad Única. Un agente, un trabajo, unas pocas herramientas, un contexto corto. Un god-agent es una función de diez mil líneas con una gabardina puesta — y falla por la misma razón.

- **Author:** Fedor Chishchin
- **Published:** 2026-06-03
- **Tags:** agents, architecture, methodology
- **Source:** https://fedorthinks.com/es/blog/one-agent-that-does-everything

---

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)](https://medium.com/@999daza/why-your-ai-agents-fail-the-context-overload-problem-and-the-slice-framework-that-fixes-it-873653ce0db6):
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](https://medium.com/@999daza/why-your-ai-agents-fail-the-context-overload-problem-and-the-slice-framework-that-fixes-it-873653ce0db6)
— 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](https://dev.to/nebulagg/the-god-agent-mistake-why-one-mega-agent-always-fails-in-production-1fk1),
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)**](https://www.alation.com/blog/general-vs-specialized-enterprise-ai-agents/),
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](https://medium.com/@stawils/more-agents-more-tools-worse-results-the-2026-evidence-for-radical-simplification-7bad6c1858a5);
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](/blog/cheap-code-is-expensive),
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](/blog/evals-or-it-didnt-ship)
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](/blog/cheap-model-most-of-the-work). 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%.