El 90% de los AI Agents que Ves en GitHub Ejecutan Tool Calls Como si Fuera 1999
En secuencia. Uno detrás de otro. Esperando a que cada llamada termine para empezar la siguiente.
*Y funcionan. Pero funcionan mal, lento, y con un coste de contexto que se come tu presupuesto de tokens. *
El 90% de las implementaciones tratan el agent loop como una lista de tareas secuencial.
El problema es que deberían tratarlo como un grafo de dependencias.
No es teoría. Es la diferencia entre un agente que tarda 45 segundos en dar una respuesta vs uno que tarda 8. Es la diferencia entre un contexto de 12.000 tokens vs uno de 4.000. Es la diferencia entre un agente que entra en bucle infinito y uno que termina limpiamente.
La comunidad cree que el problema de los AI Agents es el modelo. Mejor LLM → mejor agente.
O la conexión a herramientas. MCP, function calling, APIs.
*La realidad: ambos problemas están resueltos. El cuello de botella real es la orquestación. *
Cómo decides qué tool call ejecutar cuándo, en qué orden, y en paralelo.
---
El Patrón Que Llevamos Décadas Resolviendo (y Que Hemos Olvidado)
La ironía es que esto no es nuevo en computación.
El patrón de 3 fases que te voy a enseñar — Análisis → DAG → Ejecución topológica — es el mismo que usan los build systems como Make, Bazel o Turborepo.
Llevamos décadas resolviendo el problema de paralelizar tareas con dependencias.
*Y al llegar a los AI Agents, lo hemos olvidado. *
Un agent loop secuencial es equivalente a compilar un proyecto con un solo core en 2026.
Tiene sentido cuando tienes 2-3 herramientas secuenciales. Pero cuando tu agente ejecuta 5+ tool calls por turno con múltiples herramientas independientes, el loop plano se convierte en tu cuello de botella más caro.
---
Los 3 Problemas del Loop Secuencial Plano
Antes de ver la solución, entendamos qué se rompe cuando ejecutas tool calls en secuencia plana.
1. Latencia desperdiciada
Tienes 5 tool calls. Las primeras 3 son independientes entre sí: buscar tendencias en Google Trends, analizar competidores en Crunchbase, extraer reviews de Trustpilot. Ninguna necesita el resultado de la otra.
Con un loop secuencial: llamada 1 → esperar → llamada 2 → esperar → llamada 3 → esperar.
*Has perdido 2/3 del tiempo en espera que podrías haber paralelizado. *
2. Pérdida de contexto entre llamadas
Cada tool call devuelve datos que se inyectan en el prompt del LLM en la siguiente iteración.
Con 5-10 tool calls secuenciales, el contexto se duplica o triplica con datos intermedios que ya no necesitas. El LLM tiene que procesar información irrelevante, aumenta el coste de tokens, y la calidad de las respuestas se degrada.
El problema más silencioso de los agents secuenciales no es la velocidad. Es la degradación del contexto.
3. Bucles infinitos
Cuando un agente ejecuta tool calls en un loop plano y una llamada devuelve un resultado inesperado, el LLM no tiene suficiente información para decidir si debe parar o seguir.
No es culpa del LLM. Es culpa de la orquestación.
Con un grafo de dependencias, tienes un estado explícito del progreso: sabes qué nodos se completaron, cuáles fallaron, y cuáles están pendientes. Puedes detectar bucles (mismo nodo ejecutándose repetidamente) y aplicar políticas de terminación claras.
---
❌/✅ El Anti-Patrón vs El Patrón Real
❌ Lo que el 90% hace: Loop secuencial plano
Este código funciona. Para 2-3 tool calls secuenciales, es suficiente.
*Pero en cuanto llegas a 5+ llamadas, el coste de contexto explota y la latencia se triplica. *
✅ Lo que deberías hacer: Grafo de dependencias con ejecución topológica
---
El Framework de 3 Fases para Orquestación de Tool Calls
Llamémoslo como es: El Patrón de Orquestación en 3 Fases. No es complejo. Es estructurado. Y cada fase resuelve un problema concreto del loop secuencial.
Fase 1: Análisis de dependencias
Cuando el LLM devuelve múltiples tool calls, no las ejecutes inmediatamente.
Primero, analiza los parámetros de entrada de cada una para identificar dependencias de datos entre ellas.
Pregunta clave: ¿La tool B necesita el output de la tool A para ejecutarse?
En la práctica, esta fase suele ser más sencilla: el propio LLM puede etiquetar las dependencias si se lo pides explícitamente en el system prompt. Pero tener el análisis programático como respaldo evita que el LLM se equivoque.
Fase 2: Construcción del DAG
Genera un grafo dirigido acíclico donde los nodos son tool calls y las aristas son dependencias.
Identifica los nodos sin dependencias (fuentes) como candidatos a ejecución paralela inmediata.
El check de ciclos es importante. El LLM puede generar tool calls que se refieran unas a otras creando un bucle. Detectarlo en la Fase 2 evita que el agente se cuelgue.
Fase 3: Ejecución con planificación topológica
Ejecuta los nodos fuente en paralelo, recolecta resultados, desbloquea nodos dependientes, y repite hasta completar el grafo.
*Cada iteración del bucle principal ejecuta UN NIVEL completo del grafo, no UNA tool call. *
---
Manejador de Errores Inteligente: Propagar Solo lo Necesario
El beneficio más infravalorado del grafo de dependencias es el manejo de errores.
En un loop secuencial, si la tool call #3 falla, tienes dos opciones: reintentar todo desde el principio o ignorar el error y seguir. Ambas son malas.
Con un grafo de dependencias, puedes propagar el fallo solo a los nodos dependientes:
Esto significa que si una tool falla, solo se detienen las que necesitaban su resultado. El resto del grafo sigue ejecutándose. El agente puede tomar decisiones parciales con los datos que sí consiguió.
---
Caso Real: Agente de Investigación de Mercado en 12 Segundos
Trabajo con un agente que investiga mercados. Necesita:
- Buscar tendencias en Google Trends
- Analizar 5 competidores en Crunchbase
- Extraer reviews de Trustpilot
- Sintetizar un informe
Con ejecución secuencial:
- 8-12 llamadas secuenciales
- ~45 segundos de latencia total
- Contexto masivo con datos intermedios de cada paso
Con grafo de dependencias:
- Fase 1: Ejecuta (1) y (2) en paralelo — 3 source calls simultáneas
- Fase 2: Ejecuta (3) y (4) con datos de fase 1
- Total: ~12 segundos
- Contexto: 40% menos tokens porque solo pasas datos relevantes entre niveles
*La diferencia no es incremental. Es estructural. *
---
Cuándo Usar Cada Patrón (Sé Honesto)
No te voy a vender que el grafo de dependencias es siempre la solución.
Usa loop secuencial plano si:
- Tu agente ejecuta 2-3 tool calls por turno
- Todas las herramientas son estrictamente secuenciales (cada una necesita el resultado de la anterior)
- El tiempo de respuesta no es crítico
Usa el Patrón de Orquestación en 3 Fases si:
- Tu agente ejecuta 5+ tool calls por turno
- Tienes herramientas independientes que se pueden paralelizar
- La latencia importa (UX en tiempo real, asistentes conversacionales, automatización)
- El coste de contexto empieza a dispararse
El umbral está claro: 5 tool calls. Por debajo, el overhead del grafo no compensa. Por encima, el loop secuencial te está costando tiempo, tokens, y calidad.
---
¿Y MCP? No Resuelve Esto
MCP resuelve el problema de "cómo conecto mi agente a 20 APIs diferentes". Es un problema de protocolo.
Pero una vez que tienes 20 herramientas conectadas, el problema pasa a ser "en qué orden las llamo y cuáles puedo llamar simultáneamente".
*MCP no toca ese problema. La orquestación es el layer que falta entre MCP y el agent loop. *
Si solo implementas MCP y dejas el agent loop secuencial, tienes herramientas ilimitadas conectadas a un pipeline que las ejecuta una a una. Como tener 20 carriles en una autopista que se reduce a un solo carril en cada peaje.
---
Lo Que Te Llevas
El 90% de los AI Agents en GitHub ejecutan tool calls secuenciales. Y funcionan. Pero funcionan mal, lento, y caros.
El salto de calidad real no está en el modelo. No está en MCP. Está en cómo orquestas las llamadas.
Tres fases: analiza dependencias, construye el DAG, ejecuta por niveles topológicos. Cada fase resuelve un problema concreto del loop secuencial.
La herramienta para construir el agente es secundaria. La arquitectura de orquestación es primaria.
*El mejor modelo con mala orquestación pierde siempre contra un modelo decente con buena orquestación. *
La próxima vez que construyas un AI Agent, no empieces por el LLM. Empieza por el grafo.
Artículos relacionados
- Cómo Construir AI Agents Multi-Agente en 2026: El Framework de Orquestación que el 90% Ignora
- AI Agents en Producción: Cómo Construir Sistemas que Realmente Toman Decisiones
- Por Qué El 90% de los AI Agents Se Rompen en Producción y Cómo Arreglarlo
- Multi-Agent Coordination en 2026: Por Qué 3 Agentes Mal Coordinados Son Peores Que 1 Agente Bien Hecho
- Tool Orchestration en AI Agents: El Patrón de 3 Fases que Secuencia y Paraleliza Tool Calls sin Romper el Loop
---
¿Quieres recibir contenido como este cada semana? Suscríbete a mi newsletter
