Idea en 30 segundos
Too Many Tools es un anti-patrón donde un agente recibe demasiadas herramientas sin límites claros por tipo de tarea.
Como resultado, aparece ruido en la selección de acciones: el agente elige con más frecuencia una herramienta no relevante y gasta pasos en volver a elegir. Esto aumenta latency, cost e inestabilidad de la respuesta.
Regla simple: para cada escenario, el agente debe ver solo el conjunto mínimo de herramientas realmente necesarias.
Ejemplo del anti-patrón
El equipo construye un agente de soporte para consultas sobre pedidos, devoluciones y pagos.
En lugar de un conjunto reducido, el equipo da al agente una lista grande de herramientas "para todos los casos".
response = agent.run(
"User: ¿Por qué falla el pago del pedido #8341?"
)
En este esquema, el agente tiene decenas de opciones y puede ir por el camino equivocado:
tools = ["get_payment_status", "get_invoice", "get_order"]
selected_tool = agent.pick_tool(tools)
result = run_tool(selected_tool, order_id)
# el agente puede elegir primero get_invoice,
# no encontrar la causa del fallo,
# y solo después pasar a get_payment_status
Para este caso basta una ruta corta con pocas herramientas:
payment_data = get_payment_status(order_id)
return format_payment_answer(payment_data)
En este caso, el exceso de tools añade:
- ruido en la selección de acciones
- llamadas de herramienta innecesarias
- mayor riesgo de enrutamiento incorrecto
Por qué aparece y qué sale mal
Este anti-patrón aparece con frecuencia cuando un equipo intenta construir desde el inicio un agente "universal" para todas las solicitudes.
Causas típicas:
- se agregan tools nuevos sin retirar los antiguos
- no existe una allowlist por tipo de tarea
- miedo a que "una sola herramienta no alcance"
- copiar toolsets grandes de demos sin validar casos de producción
Esto produce problemas:
- selección inestable - el agente elige una herramienta que encaja formalmente, pero no es la mejor
- mayor latency - los ciclos de selección y llamadas repetidas consumen más tiempo
- mayor cost - pasos tool o LLM innecesarios para una solicitud típica
- contexto inflado - el prompt incluye muchas descripciones de tools y resultados intermedios
- debug difícil - cuesta rastrear por qué el agente eligió ese camino
Señales típicas de producción de que ya hay demasiadas herramientas:
- una solicitud típica de usuario dispara 3-5 llamadas de tool donde 1-2 serían suficientes
- la misma tarea sigue caminos distintos en distintos runs
- el equipo no puede explicar claramente por qué se elige el tool A en lugar del tool B
- agregar un tool nuevo degrada la quality de escenarios existentes
Como resultado, el agente gasta más pasos en elegir acción que en resolver la tarea real. Es importante entender que la selección de herramienta es parte de la inference del LLM. El modelo elige una acción entre las opciones visibles en el prompt. Cuando crece el número de herramientas, también crece la cantidad de rutas posibles y la selección se vuelve menos estable: el modelo elige con más frecuencia una herramienta que encaja formalmente, pero no es la mejor.
Cuando este esquema crece, sin trace ni visualización de ejecución es difícil entender por qué el agente eligió ese camino de herramientas. Por eso los sistemas de producción suelen tener una capa de observabilidad dedicada a los runs de agentes.
Enfoque correcto
Empieza con la ruta más simple que cubra de forma estable la mayoría de solicitudes actuales. Agrega herramientas solo cuando exista un fallo medible, un riesgo o una limitación del diseño actual.
Marco práctico:
- define una allowlist de tools clara para cada tipo de tarea
- mantén un conjunto pequeño de tools en cada ruta
- agrega un tool nuevo solo cuando haya una razón medible (por ejemplo, mejora de success rate o reducción de errores sin un aumento fuerte de latency y cost per request)
def answer_payment_question(order_id: str, user_message: str) -> str:
route = classify_intent(user_message) # clasificador simple o reglas
if route == "payment_status":
allowed_tools = ["get_payment_status"]
data = run_tool("get_payment_status", order_id)
return format_payment_answer(data)
allowed_tools = ["get_payment_status", "get_invoice"]
return agent.run(
user_message=user_message,
allowed_tools=allowed_tools,
)
En este esquema, el agente trabaja con un conjunto de herramientas pequeño y relevante, por lo que la selección de acción se vuelve más estable.
Prueba rápida
Si estas preguntas se responden con "sí", tienes riesgo too-many-tools:
- ¿Una solicitud típica necesita regularmente 3+ llamadas de tool donde deberían bastar 1-2?
- ¿La misma solicitud pasa por rutas de tools distintas en diferentes runs?
- ¿Se agregan tools nuevos más rápido de lo que el equipo puede limitar, eliminar o revisar?
Cómo se diferencia de otros anti-patterns
Tool Calling Everywhere vs Too Many Tools
| Tool Calling Everywhere | Too Many Tools |
|---|---|
| Problema principal: se llaman herramientas incluso donde bastaría reasoning o un workflow simple. | Problema principal: hay demasiadas herramientas y el agente elige entre ellas de forma inestable. |
| Cuándo aparece: cuando casi toda solicitud se convierte automáticamente en llamada de herramienta. | Cuándo aparece: cuando una ruta tiene un conjunto de herramientas sobrecargado sin allowlist clara. |
Multi-Agent Overkill vs Too Many Tools
| Multi-Agent Overkill | Too Many Tools |
|---|---|
| Problema principal: exceso de agentes y coordinación compleja entre roles. | Problema principal: exceso de herramientas dentro de una ruta de agente. |
| Cuándo aparece: cuando una solicitud atraviesa demasiados handoffs entre agentes. | Cuándo aparece: cuando el agente prueba varias tools de forma repetida para encontrar una relevante. |
Giant System Prompt vs Too Many Tools
| Giant System Prompt | Too Many Tools |
|---|---|
| Problema principal: un system prompt grande con instrucciones en conflicto. | Problema principal: el agente ve demasiadas herramientas y comete errores de selección de acción. |
| Cuándo aparece: cuando reglas nuevas se agregan continuamente a un prompt monolítico. | Cuándo aparece: cuando se agregan tools sin revisar herramientas obsoletas o duplicadas. |
Autoevaluación: ¿tienes este anti-patrón?
Revisión rápida del anti-pattern Too Many Tools.
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 muchas herramientas siempre son malas?
A: No. El problema no es la cantidad en sí. El problema es que el agente ve demasiadas opciones no relevantes en un escenario concreto.
Q: ¿Cuándo deberíamos agregar una herramienta nueva?
A: Cuando exista una señal concreta: brechas de cobertura, fallos de quality o límites de la ruta actual que no pueden resolverse con el conjunto actual sin crecimiento desproporcionado de latency, cost o complejidad de debugging.
Q: ¿Cómo reducir el caos de selección de tools sin un gran refactor?
A: Empieza simple: define allowlists por tipo de tarea, fija límites de pasos y elimina tools que casi no se usan o producen resultados duplicados.
Qué sigue
Anti-patterns relacionados:
- Agent Everywhere Problem - cuando se añade un agente incluso para tareas deterministas.
- Overengineering Agents - cuando el sistema suma capas extra sin beneficio medible.
- Multi-Agent Overkill - cuando hay demasiados agentes con límites de rol difusos.
Qué construir en su lugar:
- Allowed Actions - cómo definir límites claros de lo que el agente puede hacer.
- Routing Agent - cómo enrutar tareas y exponer al agente solo herramientas relevantes.
- Tool Execution Layer - dónde controlar llamadas de tools y políticas de acceso en la arquitectura.