No todos nuestros agentes viven en el navegador. Para nuestros clientes corporativos, el sitio natural donde "vive" un asistente es Microsoft Teams, donde el equipo ya trabaja cada día. En este artículo te contamos cómo construimos un agente de Teams cuyo cerebro es un flujo agéntico LangGraph diseñado para ser determinista, desplegado íntegramente en Azure y dentro de la región West Europe.
El reto: agentes que sean fiables, no impredecibles
Un agente útil para una empresa no puede comportarse de forma distinta cada vez que se le pregunta lo mismo. La fiabilidad es un requisito, no un lujo. Por eso, nuestra obsesión al construir agentes es el determinismo: que el flujo de decisiones sea explícito, auditable y reproducible, dejando la creatividad del modelo de lenguaje acotada a los puntos donde realmente aporta.
Trasladamos al mundo de los agentes la misma disciplina que aplicamos en DevOps: pasos controlados, estados explícitos y nada librado al azar.
La pieza central: un grafo de estados con LangGraph
En lugar de un agente "suelto" que decide libremente qué hacer en cada turno, modelamos la lógica como un grafo de estados con LangGraph. Cada nodo del grafo es un paso bien definido (interpretar la petición, recuperar datos, llamar al modelo, validar, responder) y las transiciones entre nodos siguen reglas explícitas.
Esto nos da varias garantías:
- Caminos predecibles: el flujo siempre recorre el grafo de la misma forma ante las mismas condiciones.
- Estado explícito: sabemos en todo momento en qué punto está la conversación y con qué datos.
- Puntos de control: podemos validar la salida del modelo antes de actuar, en vez de confiar a ciegas.
- Trazabilidad: cada ejecución deja un rastro claro de por qué tomó cada decisión.
El modelo de lenguaje participa donde aporta valor —comprender lenguaje natural, redactar— pero enmarcado dentro del grafo, no al mando de todo. Ese es el equilibrio que buscamos: potencia del LLM, control de la ingeniería.
El despliegue: todo en Azure, todo en West Europe
La arquitectura de ejecución está pensada para ser controlada y estar contenida en una única región, West Europe, por coherencia, latencia y cumplimiento. Estas son las piezas:
Azure App Service: donde corre el flujo LangGraph
El flujo agéntico LangGraph se ejecuta como una aplicación en Azure App Service. Aquí vive la lógica del grafo: recibe las peticiones, recorre los nodos, llama al modelo cuando toca y compone la respuesta. App Service nos da un entorno gestionado, escalable y fácil de operar, coherente con nuestra forma de trabajar con CI/CD.
Azure Bot Service: el puente con Teams
Entre Microsoft Teams y nuestro App Service se sitúa Azure Bot Service. Su papel es hacer de puente de comunicaciones: recibe los mensajes que los usuarios escriben en Teams y los reenvía al endpoint de mensajería de nuestro App Service; y a la inversa, devuelve a Teams las respuestas que genera el flujo. Gracias a esto, no tenemos que implementar nosotros la mensajería de Teams: Azure Bot Service gestiona ese canal de forma estándar y segura.
Dicho de otro modo: el usuario habla en Teams, Azure Bot Service traduce y enruta, y el flujo LangGraph del App Service hace el trabajo.
Azure AI Foundry: el modelo de lenguaje gestionado
El LLM que utiliza el flujo está desplegado en Azure AI Foundry, también en West Europe. Esto nos permite consumir el modelo como un servicio gestionado dentro del mismo entorno Azure, con control sobre el despliegue, las cuotas y la gobernanza, y manteniendo los datos dentro de la región.
El recorrido de un mensaje, de principio a fin
Para que se vea claro (y como recoge el diagrama de arquitectura que acompaña a este artículo), este es el viaje completo de una interacción:
- Un usuario escribe un mensaje al agente en Microsoft Teams.
- Azure Bot Service recibe el mensaje y lo enruta al endpoint de mensajería del App Service.
- En el App Service, el flujo LangGraph arranca: interpreta la petición y recorre el grafo de estados.
- Cuando necesita capacidades de lenguaje, el flujo llama al LLM desplegado en Azure AI Foundry.
- El grafo valida y compone la respuesta de forma controlada.
- La respuesta vuelve a través de Azure Bot Service hasta la conversación de Teams.
Todo el recorrido —desde el App Service hasta el LLM en Foundry— ocurre dentro de West Europe.
Por qué esta arquitectura
Esta solución refleja cómo entendemos la IA en Fastex:
- Determinismo primero: el grafo manda; el modelo aporta dentro de límites claros.
- Servicios gestionados de Azure: App Service, Bot Service y Foundry encajan como piezas estándar, fáciles de operar y gobernar.
- Una sola región: West Europe para todo, por latencia, coherencia y control de los datos.
- Integración natural: el agente aparece donde el equipo ya trabaja, en Teams, sin pedirle que cambie de herramienta.
El resultado es un agente corporativo en el que se puede confiar: integrado en Teams, potente gracias al LLM, pero gobernado por un flujo de ingeniería que sabe exactamente lo que hace en cada paso.
¿Quieres un agente de IA en Teams fiable y gobernado, desplegado en tu propio Azure? En Fastex diseñamos este tipo de arquitecturas de principio a fin. Escríbenos a través del formulario de contacto.