Idea en 30 segundos
Overengineering Agents es un anti-patrón donde para una tarea simple se construye una arquitectura de agentes demasiado compleja: muchas capas, roles, routers y checks sin beneficio real.
Como resultado, el sistema se vuelve más caro, más lento y más difícil de mantener. El equipo invierte más tiempo en mantener arquitectura que en aportar valor al usuario.
Regla simple: si una tarea puede resolverse de forma estable con un workflow o con un agente, no construyas un sistema multicapa.
Ejemplo del anti-patrón
El equipo quiere responder preguntas típicas sobre devoluciones.
En lugar de un escenario simple, construye una cascada de varios agentes y capas intermedias.
response = gateway_agent.run(
"User: ¿Cómo devuelvo un producto del pedido #7342?"
)
En la práctica, una solicitud simple pasa por esta cadena:
plan = planner_agent.run(user_message)
routed = router_agent.run(plan)
draft = faq_agent.run(routed)
checked = policy_agent.run(draft)
final = critic_agent.run(checked)
return final
Para este caso basta un workflow corto:
policy = get_return_policy(order_id)
return format_return_answer(policy)
En este caso, la arquitectura sobrecargada solo añade:
- capas innecesarias entre solicitud y respuesta
- más puntos de fallo
- mayor costo por ejecución
Por qué aparece y qué sale mal
Este anti-patrón aparece con frecuencia cuando el equipo intenta crear una "solución enterprise" desde el inicio, incluso para escenarios básicos.
Causas típicas:
- miedo a que una arquitectura simple "no escale"
- copiar esquemas complejos de otros casos sin validar la tarea propia
- deseo de añadir un componente "por si acaso"
- ausencia de métricas que demuestren el valor de cada capa
Esto produce problemas:
- mayor latency - la respuesta pasa por etapas innecesarias
- debug complejo - el error puede ocultarse en cualquier capa
- mayor costo - más llamadas LLM y pasos técnicos intermedios
- contexto inflado - los agentes se pasan historial y resultados intermedios
- menor confiabilidad - más componentes = más fallos potenciales
Señales típicas de producción de que el sistema ya está sobre-ingenierizado:
- cambiar una regla de policy requiere editar varias capas
- el equipo no puede mostrar rápido dónde se toma la decisión final
- una solicitud típica de usuario dispara 4-6 pasos LLM/tool donde 1-2 serían suficientes
- quitar una capa intermedia rompe incluso un escenario básico
Como resultado, el equipo ya no puede explicar rápido qué capa realmente hace falta, y cualquier cambio en un escenario simple toca varios componentes a la vez. Cuando el sistema se vuelve complejo, sin trace ni visualización de ejecución, el debugging se vuelve muy difícil. Por eso los sistemas de producción suelen tener una capa específica de observabilidad para runs de agentes.
Enfoque correcto
Empieza con la ruta más simple que cubra de forma estable la mayoría de solicitudes actuales. Añade capas nuevas solo cuando exista un fallo medible, un riesgo o una limitación del diseño actual.
Marco práctico:
- workflow para escenarios deterministas
- un agente para casos complejos o no estándar
- nueva capa solo cuando haya una razón medible (por ejemplo, mejora de success rate o reducción de errores sin aumento fuerte de latency y cost per request)
def answer_return_question(order_id: str, user_message: str) -> str:
policy = get_return_policy(order_id)
if policy.is_standard_case:
return format_return_answer(policy)
return agent.run(
f"Explica este caso no estándar de devolución: {policy.context}"
)
En este esquema, el sistema se mantiene simple y el agente se activa solo donde realmente hace falta.
Prueba rápida
Si estas preguntas se responden con "sí", tienes riesgo de overengineering:
- ¿Tienes 4+ capas y no puedes mostrar una métrica de utilidad por cada una?
- ¿Un fallo simple exige pasar por muchos componentes para depurar?
- ¿La mayoría de solicitudes pasan hoy por cascadas de pasos de agente extra aunque podrían resolverse de forma más simple?
Cómo se diferencia de otros anti-patterns
Multi-Agent Overkill vs Overengineering Agents
| Multi-Agent Overkill | Overengineering Agents |
|---|---|
| Problema principal: exceso de agentes y coordinación compleja entre ellos. | Problema principal: capas y componentes arquitectónicos innecesarios sin beneficio medible. |
| Cuándo aparece: cuando una solicitud pasa por demasiados handoffs entre roles. | Cuándo aparece: cuando se agregan capas planner, router y gateway a un escenario básico como prevención. |
Giant System Prompt vs Overengineering Agents
| Giant System Prompt | Overengineering Agents |
|---|---|
| Problema principal: un system prompt monolítico con instrucciones en conflicto. | Problema principal: complejidad estructural de arquitectura, no solo a nivel de prompt. |
| Cuándo aparece: cuando nuevas reglas se agregan continuamente al mismo prompt grande. | Cuándo aparece: cuando se añade una nueva capa en lugar de simplificar y revisar métricas. |
Agent Everywhere Problem vs Overengineering Agents
| Agent Everywhere Problem | Overengineering Agents |
|---|---|
| Problema principal: el agente se usa incluso para tareas deterministas. | Problema principal: el sistema tiene demasiadas capas incluso donde bastaría un workflow simple. |
| Cuándo aparece: cuando escenarios simples se enrutan por defecto al camino de agente. | Cuándo aparece: cuando una solicitud simple atraviesa etapas de orquestación innecesarias. |
Autoevaluación: ¿tienes este anti-patrón?
Revisión rápida del anti-pattern Overengineering Agents.
Marca los puntos para tu sistema y revisa el estado abajo.
Revisa tu sistema:
Progreso: 0/8
⚠ 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 una arquitectura compleja siempre es mala?
A: No. La complejidad está justificada cuando resuelve un problema real y eso se ve en métricas. El problema es la complejidad innecesaria sin valor.
Q: ¿Cuándo añadir un agente nuevo o una capa nueva?
A: Cuando exista una señal concreta: incidentes, errores de calidad, violación de límites o una nueva clase de tareas que el diseño actual no pueda cubrir sin crecimiento desproporcionado de latency, cost o complejidad de debugging.
Q: ¿Hay que quitar todas las capas de inmediato?
A: No. Mejor de forma gradual: quitar componentes sin efecto medible y verificar métricas después de cada simplificación.
Qué sigue
Anti-patterns relacionados:
- Agent Everywhere Problem - cuando se añade agente incluso donde basta un workflow normal.
- Multi-Agent Overkill - cuando el sistema tiene demasiados agentes sin separación clara de roles.
- Too Many Tools - cómo el exceso de herramientas vuelve inestable el comportamiento del agente.
Qué construir en su lugar:
- Hybrid Workflow + Agent - forma práctica de combinar workflow simple con ruta de agente.
- Production-Ready Agent - principios base para mantener la arquitectura controlable en entornos reales.