Agent chaining y tool use: diseña flujos de agentes que llaman APIs y herramientas

En lo que tardas en abrir un correo, un agente puede planear, elegir la herramienta adecuada, llamar una API y devolverte un resultado accionable. Eso es agent chaining (encadenamiento de agentes) y tool use (uso de herramientas): pasar de “charlar” a ejecutar en serio.

Esta guía te muestra, en lenguaje simple, cómo diseñar un flujo de agentes que llama APIs y servicios de forma segura, rápida y medible.

Al final sabrás exactamente qué piezas necesitas, cómo conectarlas y tendrás una receta lista para producción. Dos preguntas clave que resolveremos:

• ¿Cuándo conviene encadenar agentes y cuándo basta con uno solo?
• ¿Cómo evitar loops infinitos, alucinaciones y costos fuera de control?

---

¿Qué es y por qué importa?

Antes de hablar de arquitectura, aclaremos los conceptos básicos. La idea es directa: que el modelo no solo “hable”, sino que decida qué herramienta usar de manera segura y coordine varios pasos hasta lograr un resultado útil.

Tool use es la capacidad del modelo para decidir cuándo y cómo invocar una herramienta externa (ej.: una API de CRM, una búsqueda en tu índice, una consulta a tu base de datos). En la práctica: defines funciones con nombre, descripción y un esquema de parámetros; el modelo propone argumentos, tu backend valida y ejecuta. Con OpenAI esto se configura vía Tools/Function Calling, lo que habilita llamadas estructuradas y auditables (ver guía).

Agent chaining organiza el trabajo en pasos encadenados o “roles”: planificar qué hacer, ejecutar la herramienta adecuada y verificar resultados antes de responder. Este patrón nace de enfoques como ReAct (razonar y actuar con trazas observables, ReAct, 2022), arquitecturas modulares tipo MRKL (MRKL, 2022) y trabajos como Toolformer (Schick et al., 2023).

¿Por qué importa?

• Porque reduce alucinaciones al “aterrizar” en datos reales.
• Porque hace tu sistema más exacto y medible.
• Porque te da control de costos y latencia: activas solo las herramientas necesarias, limitas pasos y evalúas cada intento.

Además, cada acción deja una traza clara: qué se llamó, con qué argumentos y con qué resultado.

Si quieres más contexto, revisa estas guías sobre prompting razonado: Chain-of-Thought y Ingeniería de prompts avanzada (CoT/ToT/ReAct). Y si buscas la visión aplicada al negocio: Agentes de IA y automatización de flujos.

---

Arquitectura base

Antes de escribir código, necesitamos un mapa claro de cómo se hablarán las piezas. Nuestra arquitectura base es simple pero robusta:

• Orquestador: el centro de control. Recibe la solicitud, guarda el contexto mínimo y decide si preguntar algo más, llamar una herramienta o cerrar la tarea.
• Planificador o router: descompone la tarea, elige la herramienta correcta y propone parámetros. Si falta información, pide aclaraciones.
• Catálogo de herramientas: registro con nombre, descripción de negocio, esquema JSON, timeout y política de reintentos. Garantiza seguridad y consistencia antes de tocar sistemas reales.
• Memoria breve: solo lo imprescindible (ids, resultados clave, preferencias útiles). Sin historiales gigantes.
• Observabilidad: registra qué se llamó, con qué argumentos, cuánto tardó y cuánto costó. Te permite depurar, comparar y presupuestar.

Tres reglas para que nada se descarrile:

1. Contratos estrictos por herramienta (JSON Schema + validación antes de salir a red).
2. Presupuestos de ejecución (máx. de pasos, latencia y costo).
3. Políticas de seguridad (lista blanca de dominios/acciones, filtros de PII, auditoría).

Con esto, tu sistema será útil, seguro y predecible.

---

Fórmula general

Puedes implementarla con SDKs nativos (OpenAI Responses/Tools) o con frameworks como LangChain/LlamaIndex. El stack cambia, la fórmula no.

1. Define el trabajo y mapa de herramientas

   • Problema: “Actualizar dirección de entrega en CRM”.
   • Herramientas mínimas: buscar_pedido(id), actualizar_direccion(pedido_id, nueva_direccion), confirmar_whatsapp(numero, mensaje).
   • Métrica de éxito: confirmación por API + mensaje enviado.

2. Diseña contratos (JSON Schema) y validación

   • Nombre claro, descripción orientada a negocio, campos tipados, enums para estados, regex para formatos.
   • Rechaza payloads inválidos antes de salir a red y registra errores.

3. Orquesta y planifica con límites

   • Paso máximo (ej.: 5).
   • tool_choice: auto pero solo con lista blanca.
   • Verificador que confirme si ya hay respuesta final.
   • “Guardian” anti-loops: misma tool+args → corta en 2 intentos.

4. Ejecuta con resiliencia

   • Timeouts, reintentos exponenciales en errores transitorios, idempotencia (request ids).
   • Sanitiza y trunca respuestas largas; guarda ids, no el texto completo.

5. Compón respuesta y registra evidencias

   • Formatea para el usuario y guarda trazas de uso.

6. Evalúa y mejora

   • Casos dorados y de borde, aserciones automáticas, tests de regresión para prompts.

Checklist express:

• Herramientas con JSON Schema y validación
• Presupuesto de pasos/latencia/costo
• Guardian anti-loops + lista blanca
• Timeouts/reintentos/idempotencia
• Logs de pensamiento-acción y métricas
• Casos de prueba y aserciones

---

Ejemplo 1: OpenAI Tools (TypeScript)

Un ejemplo mínimo con dos herramientas y un planificador implícito. Referencia: OpenAI Tools.

ts

👉 Lo clave aquí: defines funciones con contratos estrictos y dejas que el modelo solo escoja entre las que están en la lista blanca. Nada de improvisaciones.

---

Ejemplo 2: LangChain (Python) con agente y herramientas

Si quieres más control del enrutamiento, LangChain ofrece patrones de agente + herramientas y memoria. Documentación: Agents.

python

👉 Si necesitas aún más flexibilidad, explora alternativas como LlamaIndex Agents. 👉 ¿Prefieres razonamiento-acción explícito? Estudia ReAct.

---

WhatsApp en vivo: de “¿llega mañana?” a confirmación en 10 segundos

Veamos un caso real en WhatsApp. Mensaje corto, cliente apurado, tú quieres resolverlo sin pedirle mil veces lo mismo.

Contexto: retail con CRM + sistema de pedidos. Herramientas registradas: buscar_pedido y actualizar_direccion. Canal de atención: WhatsApp Business.

Mensaje:

“¿Mi pedido 9123 llega mañana? Cambié de dirección”.

Así lo resuelve el flujo:

1. Planner detecta intención + datos → llama buscar_pedido.
2. Si existe el pedido, valida estado y propone cambio con actualizar_direccion.
3. Devuelve un mensaje listo para enviar en WhatsApp con resumen + ticket.

👉 Resultado: confirmas todo en menos de 10 segundos, sin repetir preguntas, con trazabilidad completa en logs. Si quieres llevar esto a producción con plantillas y mensajes optimizados, mira nuestro hub de agentes en WhatsApp.

---

Errores comunes (y cómo evitarlos)

Antes de encender tu flujo, repasemos los tropiezos más frecuentes.

• Error 1: inventar parámetros faltantes. Ejemplo: cliente no da dirección nueva y el agente rellena con un texto genérico. 🔎 Señal: confirmaciones sin datos reales. ✅ Solución: valida campos obligatorios, pregunta lo mínimo necesario y usa enums/regex.

• Error 2: loops por respuestas ambiguas. Ejemplo: buscar_pedido devuelve “not found” y se repite en bucle. 🔎 Señal: logs con intentos idénticos tool+args. ✅ Solución: límite de iteraciones + guardian anti-repetición.

• Error 3: contexto gigante e inútil. Ejemplo: adjuntar JSON entero del pedido en cada turno. 🔎 Señal: tokens caros, latencia alta. ✅ Solución: resume en 1–2 frases y guarda solo ids.

• Error 4: mezclar sandbox y producción. Ejemplo: pruebas modifican pedidos reales. 🔎 Señal: tickets reales en QA. ✅ Solución: separar entornos, usar idempotencia y permisos mínimos.

• Error 5: no medir costo/latencia. Ejemplo: tool tarda 9 s y la experiencia se rompe. 🔎 Señal: usuarios repreguntan porque “se siente lento”. ✅ Solución: instrumenta métricas, fija presupuestos (≤6 s, ≤5 pasos) y corta con handoff humano.

---

Plantilla rápida de herramientas

Tipo de herramienta	Ejemplos	Timeout	Reintentos	Fallback
HTTP REST	CRM, pagos, logística	3–8 s	1–2 (exponencial)	Mensaje a humano + ticket
Búsqueda/Índice	RAG, catálogos	2–4 s	0–1	Query simplificada
DB interna	Lecturas controladas	1–2 s	0	Cache
Utilidades	Fecha/hora, formateo	100–300 ms	0	Valor por defecto

👉 Tip: conecta RAG cuando necesites fuentes citables. Complementa con nuestra guía de prompts y este enfoque de top-k routing para seleccionar herramientas/modelos.

---

Preguntas frecuentes sobre agent chaining y herramientas

1. ¿Cuándo encadenar agentes y cuándo basta con uno?

   • Encadena si hay múltiples pasos dependientes y sistemas.
   • Si es un único llamado simple, usa solo una tool.

2. ¿Cómo evito alucinaciones?

   • Forzando uso de herramientas/datos, validando JSON y usando RAG/APIs como fuentes.

3. ¿Qué modelo usar?

   • Para orquestación: modelos “mini” (latencia/costo).
   • Para visión o extracción: variantes multimodales como GPT-4o.

4. ¿Puedo dejarlo solo en producción?

   • Sí, con límites claros: pasos, lista blanca de tools, auditoría y handoff humano.

5. ¿Qué frameworks recomiendan?

   • SDK nativo de tu proveedor para tool use.
   • Para routers/planes: LangChain o LlamaIndex.

---

Ya tienes sobre la mesa las piezas clave: orquestador, planificador, catálogo de herramientas con contratos estrictos, guardianes anti-loops, métricas de costo/latencia y validación sólida. Con eso puedes construir agentes que no solo conversan, sino que resuelven tareas reales en tu negocio.

El siguiente paso no es teórico: es elegir un flujo de verdad en tu día a día y ponerlo a prueba. Empieza pequeño, mide, itera y escala.

Aquí tienes una hoja de ruta concreta para arrancar:

1. Elige un caso real y sencillo (3–5 pasos máximo). Ejemplo: actualizar dirección en CRM o confirmar fecha de entrega por WhatsApp.

2. Define 2–4 herramientas críticas con contratos JSON Schema y validación estricta. Manténlo mínimo: cada tool tiene un nombre claro, parámetros bien tipados y políticas de tiempo/reintentos.

3. Pon límites desde el inicio: tope de 5 iteraciones, guardian anti-loops y lista blanca de herramientas. Esto mantiene al agente bajo control mientras pruebas.

4. Mide todo: latencia y costo por herramienta. Define un presupuesto y córtalo cuando se supere. Recuerda: lo que no se mide, se descontrola.

5. Crea un set de pruebas pequeño pero sólido: 6–10 casos que incluyan lo dorado (lo que siempre debería funcionar) y lo incómodo (errores, entradas incompletas, datos raros).

Con eso ya puedes correr un piloto seguro, detectar cuellos de botella y pulir antes de escalar.

Y si quieres una segunda mirada experta sobre tu diseño o una mano para armar tu primer MVP de agentes, podemos revisarlo juntos: agenda aquí tu evaluación de flujos.