El problema
Imagina que escribes: «envía la dirección del restaurante de mi cena del viernes a todos los invitados». Para conseguirlo, hay que leer tu agenda, encontrar la cena, sacar de ella el lugar, buscar a cada invitado en tus contactos y preparar un correo. Cinco gestos, tres servicios.
Dárselo todo de golpe a un solo modelo de lenguaje, con todas las herramientas a la vista, funciona mal. Cuantas más herramientas ve, más duda y más se equivoca de herramienta. Cada llamada cuesta más. Y cuando falla, es imposible saber dónde.
Lo que quería
Quería que LIA trabajara como un pequeño equipo bien organizado: alguien clasifica la petición, alguien prepara el plan, alguien lo comprueba, alguien lo ejecuta y alguien te responde. Cada papel hace una sola cosa. A su alrededor, cada dominio aporta sus propias herramientas y sus instrucciones de uso: correos, agenda, contactos, tareas, archivos, tiempo, lugares, itinerarios, búsqueda web, e incluso los servidores MCP que añades tú mismo.
Para enlazar esos papeles elegí LangGraph, una biblioteca que describe un procesamiento como un grafo: unos pasos y unas reglas que dicen cuál viene después. Tu mensaje recorre ese grafo de principio a fin.
Cómo funciona
- La clasificación. El router lee tu mensaje y decide si se trata de una conversación o de una petición de acción, y qué dominios están implicados. «Gracias, ha sido perfecto» va directo a la respuesta. La cena del viernes va al planificador, con la agenda, los contactos y los correos.
- El plan. El planificador solo recibe las herramientas de esos dominios. Escribe un plan: qué pasos, con qué parámetros y cuáles esperan el resultado de otro.
- La comprobación. Antes de la menor llamada, LIA revisa ese plan: una herramienta inventada, un paso que espera a otro inexistente, un valor fuera de límites. Lo que se puede reparar se repara; lo que sigue siendo dudoso vuelve al planificador.
- La ejecución. Los pasos independientes salen a la vez; los demás esperan lo que necesitan. Aquí: primero la agenda, luego todos los invitados en paralelo, luego el borrador del correo, que validas antes del envío.
- El toque extra. Una vez que vuelven los resultados, LIA mira si falta una información que simplemente puede leer. Si un correo propone una reunión el jueves, puede echar un vistazo a tu agenda del jueves. También puede sugerirte una acción, sin ejecutarla.
- La respuesta. Un último papel reúne lo que ha pasado y te lo escribe, distinguiendo lo que ha salido bien de lo que ha fallado.
Dos formas de trabajar
Este circuito es el modo Pipeline: planificar primero, ejecutar después. Es el más económico y el más previsible, y es el modo por defecto. Pero algunas preguntas no se pueden planificar de antemano. «¿Qué hacemos este fin de semana?» depende de lo que LIA vaya descubriendo por el camino. Para esas puedes pasar al modo ReAct con un clic en el botón de modo, en la parte superior de la pantalla: LIA avanza paso a paso, lee cada resultado y elige lo siguiente. Los dos modos comparten la misma memoria y las mismas confirmaciones, y confluyen en el mismo paso de respuesta.
Un hilo que no se pierde
Después de cada paso, el estado de la conversación se guarda en la base de datos (PostgreSQL). Cuando LIA espera tu validación, retoma exactamente donde se había quedado en cuanto respondes, mientras la pregunta no haya caducado. Si cierras la pestaña, la respuesta sigue en el servidor y te espera a tu vuelta. Y cuando una conversación se vuelve muy larga, LIA resume el principio para su propio uso, sin borrar nada del historial que ves.
Los límites
La clasificación puede equivocarse. Cuando el router duda de verdad, te responde sin actuar, y a menudo basta con reformular. El modo Pipeline fija su plan antes de haber visto los resultados: si un paso falla, te lo dice, sin improvisar otro camino. Y un dominio solo existe para LIA si el servicio está conectado: sin tu agenda, ningún plan puede leerla.
El circuito completo se describe en la página técnica.
Para profundizar: Un plan antes de actuar: cómo prepara y comprueba LIA tus peticiones de varios pasos; Pipeline o ReAct: dos formas de llevar a cabo tu petición.