Idea en 30 segundos
Agent Everywhere es un anti-patrón donde se añade lógica de agente a cada tarea, incluso donde basta una llamada API simple o un workflow determinista.
Como resultado, el sistema se vuelve más complejo, más caro y menos predecible. Tareas que podrían ejecutarse con precisión y rapidez se delegan al LLM con toda su inestabilidad.
Regla simple: si una tarea puede describirse como una secuencia clara de pasos, el agente sobra.
Ejemplo del anti-patrón
El equipo quiere crear un agente que responda consultas de usuarios sobre estado de pedidos.
En lugar de un workflow simple, el equipo añade un agente.
response = agent.run(
"User: Where is my order #18273?"
)
En este esquema, el agente decide por sí mismo:
- qué herramienta llamar
- cómo interpretar el resultado
- cómo construir la respuesta final
Pero esta tarea es totalmente determinista y no necesita lógica de agente. Un workflow simple es suficiente:
order = get_order(order_id)
return f"Your order is currently {order.status}"
En este caso, el agente solo añade:
- complejidad innecesaria
- costos adicionales
- riesgo de errores
Por qué aparece y qué sale mal
Este anti-patrón aparece con frecuencia en etapas tempranas de desarrollo de sistemas de agentes. El equipo ve que un agente puede resolver tareas complejas y empieza a usarlo para todo.
Causas típicas:
- deseo de hacer el sistema "más inteligente"
- copiar arquitecturas de demos o blogs
- falta de separación clara entre workflow y agentes
- intentar resolver todas las tareas vía LLM
Esto lleva a problemas:
- complejidad innecesaria - tareas simples pasan por ciclo de reasoning
- mayor costo - se llama al LLM donde no hace falta
- inestabilidad - el agente puede elegir herramienta incorrecta o interpretar mal el resultado
- menor velocidad - operaciones deterministas se vuelven más lentas
Como resultado, tareas simples y deterministas pasan por ciclo de reasoning del LLM, lo que añade latency, costo e inestabilidad sin beneficio real.
Enfoque correcto
Conviene usar agente solo donde la tarea realmente requiere reasoning, selección de herramientas o manejo de incertidumbre.
Si la tarea tiene workflow determinista, conviene implementarla como código normal o workflow, no como agente.
Una arquitectura correcta suele verse así:
- workflow gestiona operaciones deterministas
- agente se usa solo para decisiones complejas
order = get_order(order_id)
if order.requires_review:
result = agent.run(order_context)
else:
result = format_order_status(order)
En este esquema, el agente se usa solo donde realmente hace falta.
Prueba rápida
Si estas preguntas se responden con "sí", el agente sobra:
- ¿La tarea puede describirse como 3-5 pasos claros?
- ¿Existe un único resultado correcto?
- ¿No se necesita planificación ni reasoning?
Cómo se diferencia de otros anti-patterns
Overengineering Agents vs Agent Everywhere Problem
| Overengineering Agents | Agent Everywhere Problem |
|---|---|
| Problema principal: capas arquitectónicas y componentes innecesarios. | Problema principal: el agente se usa incluso para tareas deterministas. |
| Cuándo aparece: cuando el sistema se complica con capas extra sin métricas de beneficio. | Cuándo aparece: cuando incluso workflows básicos se pasan al modo agente. |
Multi-Agent Overkill vs Agent Everywhere Problem
| Multi-Agent Overkill | Agent Everywhere Problem |
|---|---|
| Problema principal: exceso de agentes y coordinación compleja entre ellos. | Problema principal: incluso una tarea simple dispara un agente sin necesidad. |
| Cuándo aparece: cuando una solicitud pasa por demasiados handoffs entre roles. | Cuándo aparece: cuando escenarios deterministas lanzan reasoning de LLM en lugar de código. |
Single-Step Agents vs Agent Everywhere Problem
| Single-Step Agents | Agent Everywhere Problem |
|---|---|
| Problema principal: el agente se ejecuta en una sola model call sin loop, recovery ni stop reasons. | Problema principal: el agente se aplica donde no hace falta en absoluto. |
| Cuándo aparece: cuando tareas con tools o side effects (cambios de estado) se ejecutan en una sola llamada. | Cuándo aparece: cuando escenarios simples deterministas no se separan en un workflow normal. |
Autoevaluación: ¿tienes este anti-patrón?
Revisión rápida del anti-pattern Agent Everywhere.
Marca los puntos para tu sistema y revisa el estado abajo.
Revisa tu sistema:
Progreso: 0/3
⚠ Hay señales de este anti-patrón
Intenta mover los pasos simples a un workflow y dejar el agente solo para decisiones complejas.
FAQ
Q: ¿Esto significa que no hay que usar agentes en absoluto?
A: No. Los agentes son útiles para tareas con incertidumbre - por ejemplo búsqueda de información, análisis de datos, planificación o trabajo con varias herramientas. El problema aparece cuando se usan agentes para operaciones deterministas simples.
Q: ¿Cómo saber que una tarea no necesita agente?
A: Si el resultado siempre está definido por reglas claras o por una llamada API, normalmente el agente no hace falta.
Q: ¿Se puede combinar workflow y agentes?
A: Sí, es uno de los mejores enfoques. workflow maneja partes deterministas del sistema, y el agente se usa solo para tareas complejas o abiertas.
Qué sigue
Para entender mejor cómo evitar el anti-pattern Agent Everywhere en producción:
- Multi-Agent Overkill - cuando el sistema agrega demasiados agentes sin un rol claro para cada uno.
- Too Many Tools - cómo el exceso de herramientas vuelve inestable la elección de acciones.
- ReAct Agent - patrón base donde el agente se usa solo donde de verdad hace falta reasoning.
- Routing Agent - cómo dejar tareas simples en workflow y enrutar tareas complejas al camino de agente.
- Agent Runtime - dónde separar técnicamente workflow determinista y lógica de execution del agente.