Los primeros proyectos de IA generativa en empresa fueron, casi todos, asistentes que responden preguntas. Son útiles, pero tienen dos límites claros: solo actúan cuando alguien les escribe y su memoria se reduce a lo que cabe en la conversación. Un agente de IA va un paso más allá: razona sobre un objetivo, planifica los pasos, consulta información de la organización y ejecuta acciones en otros sistemas. Y cuando hay varios agentes trabajando juntos, la arquitectura importa tanto como el modelo.
Este artículo repasa las decisiones de diseño que determinan si un sistema de agentes será mantenible y escalable o si se convertirá en un prototipo imposible de llevar a producción.
Las cuatro piezas de un agente
Un agente es la orquestación de cuatro elementos:
| Pieza | Qué aporta | Ejemplo |
|---|---|---|
| Modelo de razonamiento | Interpreta la intención, decide y planifica la secuencia de acciones | Un modelo de lenguaje de propósito general |
| Instrucciones | Definen la especialidad, el tono, los límites y qué hacer ante la duda | «Agente de nómina», «agente de cumplimiento normativo» |
| Conocimiento | Memoria de la conversación y acceso a documentación propia mediante búsqueda semántica (RAG) | Políticas internas, procedimientos, convenios |
| Herramientas | Conectores que permiten consultar y modificar sistemas reales | ERP, CRM, sistema de recursos humanos |
La pieza que más riesgo introduce es la última: en cuanto un agente puede cambiar el estado de un sistema (crear un pedido, modificar un contrato, enviar un correo), deja de ser un experimento y pasa a ser una aplicación con consecuencias. Por eso conviene que cada agente tenga pocas herramientas y bien acotadas.
Sistemas multiagente: especializar y coordinar
Un único agente que lo sabe todo y lo puede todo es difícil de probar y de corregir. La alternativa es descomponer por dominio: en recursos humanos, por ejemplo, un agente de vacaciones, otro de nómina y otro de incorporación, cada uno con sus instrucciones, su conocimiento y sus permisos.
Por encima, un agente orquestador recibe la petición, identifica qué agentes deben intervenir, en qué orden y con qué dependencias, y compone la respuesta final. Hay dos formas de orquestar:
- Secuencial: el flujo está definido de antemano. Es la opción adecuada para procesos con pasos obligatorios y requisitos de cumplimiento, como una incorporación en un sector regulado o una revisión financiera.
- Autónoma: el modelo decide el flujo sobre la marcha según el contexto y los resultados parciales de cada agente. Da más flexibilidad, pero es menos predecible y exige más trazabilidad y más pruebas.
En la práctica, muchos sistemas combinan ambas: un esqueleto secuencial para lo que tiene que cumplirse siempre y tramos autónomos donde la variabilidad es aceptable.
Arquitectura orientada a eventos: autonomía de verdad
Si un agente solo actúa cuando alguien le escribe, sigue siendo reactivo. La autonomía real llega cuando reacciona a lo que ocurre en el negocio: se emite una factura, llega un correo a un buzón, baja el inventario de un artículo o vence un plazo. La arquitectura orientada a eventos (EDA) proporciona esa capacidad.
Tres ventajas la hacen casi imprescindible en sistemas de agentes:
- Disparadores automáticos. Los agentes se suscriben a eventos y actúan sin intervención humana: preparar una reclamación de cobro, abrir una incidencia o lanzar una alerta.
- Respuesta en tiempo real. El agente actúa cuando el evento se produce, no cuando alguien revisa una bandeja.
- Resiliencia. Al estar desacoplados, el fallo de un agente no tumba el sistema: el evento queda en cola y se procesa cuando el componente se recupera.
Protocolos de interoperabilidad: MCP y A2A
Dos estándares están ordenando un ecosistema que hasta hace poco era una colección de integraciones a medida:
- MCP (Model Context Protocol): una capa común para ofrecer herramientas y contexto a cualquier agente. Una herramienta publicada por MCP se puede reutilizar en agentes construidos con plataformas distintas.
- A2A (Agent-to-Agent): un estándar emergente para que agentes de plataformas y lenguajes diferentes se comuniquen de forma segura.
Apostar por ellos desde el principio reduce la dependencia de un proveedor y evita rehacer integraciones cada vez que cambia el modelo o la plataforma.
Gobierno, seguridad y monitorización
Un agente en producción necesita el mismo rigor que cualquier aplicación crítica, y algunos controles específicos:
- Identidad propia por agente. Cada agente se da de alta en el proveedor de identidad con permisos mínimos sobre datos y API, y sus acciones quedan registradas a su nombre. Los principales proveedores, como Microsoft Entra, ya ofrecen identidades específicas para agentes.
- Persona en el bucle. Las decisiones no estándar o de alto riesgo (una concesión de crédito, un cambio contractual, cualquier acción irreversible) requieren aprobación humana explícita.
- Cumplimiento aplicado en la plataforma. Las políticas de protección de la información y las obligaciones del RGPD y del Reglamento europeo de IA se aplican de forma centralizada, no agente a agente.
- Trazabilidad completa. Cada paso (orquestador, agente, herramienta, respuesta) se registra con herramientas de observabilidad como OpenTelemetry o Azure Monitor. Sin ese rastro, depurar un error o responder a una auditoría es casi imposible.
- Evaluación continua. Como las respuestas no son deterministas, se prueban de forma automática y periódica la fidelidad a las fuentes y la seguridad del contenido, no solo en el momento de la entrega.
Qué plataforma elegir
No hay una solución única. La elección equilibra velocidad de desarrollo, control técnico e integración con lo que ya existe:
| Plataforma | Desarrollo | Integración | Despliegue | Encaja en |
|---|---|---|---|---|
| Copilot Studio | Low-code, visual | Microsoft 365 y Power Platform | Nube gestionada | Prototipos rápidos y flujos creados por usuarios de negocio |
| Microsoft Foundry (antes Azure AI Foundry) | Pro-code (Python, C#) | Ecosistema Azure | Contenedores, Kubernetes | Sistemas críticos con requisitos de cumplimiento |
| n8n | Low-code, visual | Agnóstico, con soporte de MCP | Nube o instalación propia | Integraciones complejas y portabilidad |
| LangChain, LlamaIndex | Bibliotecas de Python | API genéricas | Contenedores, Kubernetes | Experimentación y modelos abiertos |
Una arquitectura dual en entornos Microsoft
En organizaciones que ya trabajan con Microsoft, una combinación que funciona bien es:
- Delante, Copilot Studio, como cara conversacional y orquestación de alto nivel. Los usuarios de negocio pueden crear y ajustar flujos sin programar.
- Detrás, Microsoft Foundry, como motor para lo complejo: RAG avanzado, modelos ajustados, evaluación y despliegue controlado.
- Para los agentes desarrollados a medida, un SDK como Semantic Kernel (hoy integrado en Microsoft Agent Framework), independiente del modelo y con soporte de los protocolos abiertos.
El principio es sencillo: la capa delantera gestiona la experiencia de usuario; la trasera garantiza seguridad, escalabilidad y cumplimiento en las operaciones críticas.
Seis comprobaciones antes de producción
Si un sistema falla en alguna, su mantenimiento a medio plazo está en riesgo:
- Modularidad: ¿cada agente tiene un rol único y un conjunto limitado de herramientas?
- Infraestructura desacoplada: ¿usa eventos y puede escalar horizontalmente con contenedores cuando crecen los disparadores y la demanda?
- Protocolos estándar: ¿la comunicación entre agentes y herramientas usa MCP o A2A?
- Identidad y acceso: ¿cada agente tiene identidad propia con permisos mínimos sobre datos y API?
- Trazabilidad: ¿se registra cada paso del orquestador y de los agentes?
- Evaluación automatizada: ¿hay pruebas periódicas de fidelidad y de seguridad del contenido?
Por dónde empezar
El éxito depende menos de la tecnología que de aplicar con disciplina unos pocos principios: modularidad, gobierno, observabilidad y cumplimiento. Un camino razonable:
- Elegir uno o dos casos de uso con valor claro y riesgo controlado.
- Definir desde el principio las identidades, los permisos y los puntos de aprobación humana.
- Construir una prueba de concepto en un entorno controlado, con trazabilidad desde el primer día.
- Escalar de forma gradual, con métricas de calidad que se revisan de forma continua.
En Bidatia ayudamos a diseñar este tipo de arquitecturas y a llevarlas a producción con los controles adecuados.
Preguntas frecuentes
¿Qué diferencia hay entre un asistente basado en un modelo de lenguaje y un agente de IA?
El asistente responde a lo que se le pide y su capacidad depende de lo que cabe en la conversación. El agente, además de razonar, planifica, consulta conocimiento propio de la organización y usa herramientas para ejecutar acciones en otros sistemas, como registrar una solicitud en el ERP o actualizar el CRM.
¿Cuándo conviene un sistema multiagente en lugar de un único agente?
Cuando el proceso abarca tareas distintas con reglas, datos y permisos diferentes. Un agente por tarea, con pocas herramientas, es más fácil de probar, corregir y auditar que un agente generalista que lo hace todo.
¿Qué aportan MCP y A2A?
MCP (Model Context Protocol) estandariza cómo se ponen herramientas y contexto a disposición de un agente. A2A (Agent-to-Agent) estandariza la comunicación entre agentes construidos en plataformas distintas. Con ambos, cambiar de plataforma o de modelo no obliga a rehacer las integraciones.
¿Hay que empezar con low-code o con pro-code?
Depende del caso. El low-code permite validar rápido un flujo conversacional; el pro-code da más control para lógica crítica, pruebas y despliegue. Muchas arquitecturas combinan ambos: una capa conversacional ágil delante y servicios desarrollados detrás.