Flujos agénticos que no se rompen: llamadas a herramientas, humano en el bucle y las costuras entre sistemas

La automatización de procesos de negocio y un agente de IA se venden como lo mismo, y no lo son. La automatización es un pipeline fijo: el paso dos siempre sigue al paso uno de la misma manera. Un agente es un bucle donde el modelo decide qué paso viene después, según lo que acaba de devolver una llamada a una herramienta. Ambos tienen su lugar - la mayoría de lo que un negocio de verdad necesita es automatización con uno o dos puntos de decisión agénticos, no un agente que toma cada decisión.

La arquitectura de fondo, en cualquiera de los dos casos, es lo que determina si sobrevive al contacto con datos reales: cómo se le da contexto al modelo, cómo se recupera una respuesta en una forma en la que el código pueda confiar, cómo el modelo llega a otros sistemas, y dónde una persona todavía tiene que decir que sí. Esa fontanería, no la elección del modelo, es en lo que paso la mayor parte de un proyecto.

1. Ingeniería de contexto: darle al modelo la porción correcta, no todo

La ingeniería de contexto es el trabajo poco glamuroso de decidir qué ve el modelo en una llamada dada - qué registros, qué turnos anteriores, qué instrucciones - y, igual de importante, qué no ve. Volcar todo el historial de un cliente o un documento entero en el prompt cada vez no es minuciosidad; es ruido que aleja la pregunta real de la atención del modelo e infla en silencio el coste de cada llamada.

El patrón que aguanta se parece más a un problema de búsqueda que a uno de memoria: recuperar los dos o tres registros relevantes para este paso concreto, resumir lo anterior en vez de repetirlo palabra por palabra, y dejar que el agente pida más solo cuando lo necesite. Un flujo que saca de forma fiable las cinco líneas correctas de diez mil gana al que mete las diez mil de golpe y espera.

2. Las salidas estructuradas y las llamadas a herramientas/funciones son la interfaz real

Un modelo que responde en texto libre y se parsea con una regex es donde estas construcciones fallan en silencio en producción. Las salidas estructuradas - un esquema JSON dentro del cual el modelo está obligado a responder - y las llamadas a herramientas/funciones - el modelo solicita una función concreta con argumentos tipados en vez de describir una acción en prosa - son lo que permite que su código confíe lo suficiente en una respuesta para actuar sin que un humano vuelva a leer cada salida.

Valido el esquema a la salida del modelo y otra vez antes de que llegue a un sistema real, porque un modelo puede producir JSON sintácticamente válido que igual está mal para la regla de negocio en cuestión - una cantidad negativa, una fecha en el pasado, una moneda que la cuenta no admite. El esquema atrapa errores de forma; una segunda capa de validación, aburrida, atrapa los que son JSON válido y aun así están mal.

3. Embeddings y base de datos vectorial - solo cuando la búsqueda es de verdad el trabajo

Los embeddings y una base de datos vectorial se ganan su lugar cuando la tarea es de verdad recuperación: encontrar los tres tickets de soporte más cercanos a este nuevo, encontrar la cláusula de un contrato más cercana a esta pregunta. Son la herramienta equivocada para un conjunto fijo y pequeño de registros que ya cubre una consulta normal de base de datos - he visto una base vectorial atornillada a un flujo con once categorías posibles, donde una tabla de consulta habría sido más rápida, más barata y más fácil de depurar.

Cuando es la herramienta correcta, lo que de verdad necesita cuidado no es el modelo de embedding - es qué se trocea, cómo, y qué tan fresco se mantiene el índice después de que cambia el documento fuente. Una búsqueda vectorial sobre trozos obsoletos da una respuesta segura y equivocada, y nada en la salida del agente le dice que pasó.

4. Humano en el bucle y orquestación de API: dónde se rompe de verdad

El fallo que más veo no es un mal razonamiento del modelo - es la costura entre dos sistemas: una llamada a la API que expira y el agente la reintenta dos veces, enviando un pedido duplicado; un webhook que se dispara antes de que el paso anterior termine de escribir; una llamada a una herramienta que tiene éxito del lado del proveedor pero la respuesta que recibe el agente indica un fallo. Orquestar llamadas entre CRM, facturación y correo significa decidir qué pasa ante un timeout o un fallo parcial antes de que ocurra en producción, no después.

Todo lo que envía dinero, borra un registro o le manda un correo a un cliente pasa por un paso de confirmación humana antes de dispararse - no porque el modelo sea poco fiable en general, sino porque el coste de una acción automática equivocada es asimétrico respecto al coste de un clic extra. Prefiero que una persona apruebe veinte acciones correctas al día a que el agente envíe automáticamente una factura equivocada.

Conclusión: el agente es el 10% fácil

Elegir un modelo y escribir el primer prompt es de verdad la parte fácil de un flujo agéntico. El contexto que se le pasa, el esquema que se valida, la búsqueda vectorial que solo corre cuando debe, la lógica de reintento a través de tres API, y ese único paso que sigue aprobando un humano - eso es el otro 90%, y es lo que decide si la automatización sigue funcionando un martes dentro de seis meses con datos que nadie probó. Escriba por el formulario el proceso que quiere automatizar, y le diré cuál 10% es el agente y cuál 90% es lo que realmente hay que construir.