Idea en 30 segundos
Tool Calling for Everything es un anti-patrón donde el agente convierte casi cada solicitud en tool-call por defecto.
Como resultado, incluso escenarios simples pasan por pasos innecesarios, aumentan latency y cost, y el sistema se vuelve más frágil por su dependencia de llamadas externas.
Regla simple: llama una herramienta solo cuando la tarea no puede resolverse de forma estable sin datos externos o acción externa.
Ejemplo del anti-patrón
El equipo construye un agente de soporte para preguntas sobre pedidos, devoluciones y policies del servicio.
Incluso para una pregunta policy simple, el agente primero llama tools.
response = agent.run(
"User: ¿Cuál es el plazo para devolver un producto?"
)
En este esquema, una respuesta típica pasa por una cadena de herramientas innecesaria:
tool_result = run_tool("get_return_policy")
answer = agent.summarize(tool_result)
return answer
Para este caso basta un workflow corto sin tool-call:
policy = RETURN_POLICY_BY_REGION[region]
return format_return_policy(policy)
En este caso, el tool-calling excesivo añade:
- llamadas externas innecesarias
- mayor costo por solicitud
- puntos adicionales de fallo
Por qué aparece y qué sale mal
Este anti-patrón aparece con frecuencia cuando el equipo construye una arquitectura "tool-first" y no deja una ruta simple sin herramientas.
Causas típicas:
- no existe una ruta
no_toolexplícita para casos deterministas - se aplica una sola plantilla de ejecución a todos los tipos de solicitudes
- miedo a responder sin verificación externa incluso donde los datos ya son deterministas
- falta de métricas que muestren el valor de cada tool-call
Esto produce problemas:
- mayor latency - cada tool-call añade un paso de red y cómputo
- mayor cost - crece la cantidad de llamadas LLM/tool en una solicitud típica
- fragilidad de escenarios - incluso un caso simple depende de un servicio externo
- riesgo de efectos secundarios (cambios de estado) - una llamada innecesaria puede volver a actualizar estado o duplicar una acción externa
- debug difícil - cuesta más explicar por qué una solicitud simple entró en tool-path
A diferencia de Too Many Tools, aquí el problema principal no es elegir entre muchas herramientas, sino la decisión de hacer tool-call donde no hace falta.
Señales típicas de producción de que el tool-calling ya es excesivo:
- la mayoría de solicitudes FAQ o policy pasan por tool-call aunque la respuesta sea determinista
tool_call_ratepara rutas FAQ o policy se mantiene alto (por ejemplo, 80%+)cost per requestsube ysuccess ratecasi no cambia- la caída de una herramienta rompe un escenario que podía funcionar localmente
- el equipo no puede explicar claramente cuándo tool-call es obligatorio y cuándo no
Es importante que cada tool-call suele implicar un prompt nuevo y una nueva LLM inference. Cuando hay muchas llamadas innecesarias, crece la cantidad de pasos sin aumentar el resultado útil.
Sin trace ni visualización de ejecución, es difícil ver qué porcentaje de solicitudes simples pasa realmente por ruta no_tool y cuál sigue entrando en tool-calls innecesarias.
Enfoque correcto
Empieza con una ruta sin herramientas como opción por defecto. Agrega tool-call solo cuando realmente se necesiten datos externos, verificación de estado actual o ejecutar una acción externa.
Marco práctico:
- para cada tipo de solicitud, define:
no_toolotool_required - primero intenta resolver la solicitud sin tool-call
- mantén respuestas deterministas en workflow o código
- para ruta con tools, define allowlist estrecha y trigger claro
- agrega un tool-call nuevo solo por una razón medible (por ejemplo, mejora de success rate sin crecimiento fuerte de latency y cost per request)
def answer_support_question(user_message: str, order_id: str, region: str) -> str:
route = classify_intent(user_message) # simple classifier or rules
if route == "return_policy":
return format_return_policy(local_return_policy(region)) # static config or local rules
if route == "order_status":
data = run_tool("get_order_status", order_id)
return format_order_status(data)
return agent.run(
user_message=user_message,
allowed_tools=["search_help_center"],
)
En este esquema, el tool-call se vuelve dirigido: las herramientas se llaman donde realmente hacen falta, no por defecto.
Prueba rápida
Si estas preguntas se responden con "sí", tienes riesgo tool-calling-for-everything:
- ¿Una solicitud FAQ o policy simple dispara regularmente al menos un tool-call?
- ¿La falla de una herramienta rompe a veces un escenario que podría funcionar sin llamada externa?
- ¿En un caso típico, la cantidad de pasos tool/LLM es mayor de lo necesario (donde 0-1 llamadas serían suficientes)?
Cómo se diferencia de otros anti-patterns
Too Many Tools vs Tool Calling for Everything
| Too Many Tools | Tool Calling for Everything |
|---|---|
| Problema principal: un agente tiene un conjunto excesivo de herramientas y elige entre ellas de forma inestable. | Problema principal: se llama herramienta casi siempre, incluso cuando no hace falta. |
| Cuándo aparece: cuando en una ruta hay demasiadas tools similares sin allowlist clara. | Cuándo aparece: cuando casos deterministas se envían por defecto a tool-call en lugar de workflow. |
En resumen: Too Many Tools trata de selección inestable entre muchas tools, mientras que Tool Calling for Everything trata del hecho de llamar tools de forma innecesaria.
Agent Everywhere Problem vs Tool Calling for Everything
| Agent Everywhere Problem | Tool Calling for Everything |
|---|---|
| Problema principal: se usa agente incluso donde workflow o código bastan. | Problema principal: incluso dentro del camino agente, las tools se llaman sin necesidad explícita. |
| Cuándo aparece: cuando tareas simples disparan reasoning LLM de inmediato. | Cuándo aparece: cuando casi cada solicitud recibe al menos un tool-call "por si acaso". |
En resumen: Agent Everywhere Problem trata de reasoning agente innecesario, mientras que Tool Calling for Everything trata de llamadas externas innecesarias incluso dentro del camino agente.
Giant System Prompt vs Tool Calling for Everything
| Giant System Prompt | Tool Calling for Everything |
|---|---|
| Problema principal: system prompt monolítico con instrucciones en conflicto. | Problema principal: patrón excesivo de llamadas a herramientas en escenarios simples. |
| Cuándo aparece: cuando la mayor parte de lógica y reglas se mantiene en un solo prompt. | Cuándo aparece: cuando la arquitectura no tiene regla explícita de "cuándo se puede sin tools". |
Dónde se confunden: cuando la regla always call tool está escondida dentro de un prompt grande. | Dónde se confunden: cuando esa regla no se extrae a una ruta explícita tool_required. |
En resumen: estos anti-patterns se cruzan cuando always call tool queda oculto en un prompt grande en lugar de una lógica de enrutamiento explícita.
Autoevaluación: ¿tienes este anti-patrón?
Revisión rápida del anti-pattern Tool Calling for Everything.
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 casi no hay que usar tools?
A: No. Las tools son necesarias donde hay que obtener datos externos, verificar estado actual o ejecutar una acción externa. El problema es solo cuando tool-call se vuelve el default para todos los casos.
Q: ¿Cuándo está realmente justificado un tool-call?
A: Cuando sin él no se puede dar un resultado correcto de forma estable en ese escenario sin crecimiento desproporcionado de latency, cost o complejidad de debug.
Q: ¿Cómo reducir tool-calls innecesarios sin gran refactor?
A: Empieza con un paso: agrega una ruta no_tool para el caso determinista más frecuente y fija una regla para cuándo tool-call es obligatorio.
Qué sigue
Anti-patterns relacionados:
- Too Many Tools - cuando hay demasiadas tools en una ruta y la elección de acciones se vuelve inestable.
- Agent Everywhere Problem - cuando se usan agentes incluso para tareas que se resuelven mejor con workflow.
- Giant System Prompt - cuando reglas en un prompt único dificultan un comportamiento estable.
Qué construir en su lugar:
- Allowed Actions - cómo fijar acciones permitidas por escenario en código.
- Routing Agent - cómo separar rutas deterministas y casos complejos.
- Tool Execution Layer - dónde controlar centralmente tool-calls, policies y límites.