Arquitectura agéntica: qué es y cómo implementarla

Para conseguir una arquitectura agéntica, no basta con elegir un modelo de lenguaje. Es necesario definir cómo se conectan elementos como los datos, la memoria, las API, los permisos, las reglas de negocio y la supervisión humana para que el agente pueda actuar de forma fiable y controlada.

Diseñar una arquitectura agéntica también implica decidir qué nivel de autonomía necesita cada proceso y si conviene utilizar un único agente, un workflow o un sistema multiagente. La elección dependerá de la complejidad del caso de uso, los riesgos asociados y las acciones que la IA deba realizar.

¿Qué es una arquitectura agéntica?

Cuando un modelo recibe un texto y genera una respuesta, el recorrido sigue siendo sencillo: entrada, generación y salida. Una arquitectura agéntica añade un bucle en el que el sistema puede:

1. Observar la situación.
2. Seleccionar una acción.
3. Utilizar una herramienta.
4. Analizar el resultado.
5. Decidir cuál será el siguiente paso.

Del modelo de lenguaje a un sistema capaz de actuar

Un agente de IA básico se basa en tres componentes: un modelo, herramientas e instrucciones que definen su comportamiento. Su motor de ejecución le permite trabajar hasta obtener un resultado o hasta que se active una condición de parada [1].

Pensemos en una solicitud dirigida a un servicio de atención al cliente: «Quiero modificar la dirección de entrega de mi pedido».

Un asistente generativo puede explicar el procedimiento. Un agente puede ir más allá:

1. identificar al cliente;
2. localizar el pedido correspondiente;
3. comprobar si ya ha sido enviado;
4. solicitar una confirmación si todavía es posible realizar la modificación;
5. llamar a la API de gestión de pedidos;
6. comprobar el resultado;
7. informar al cliente o transferir el caso.

La autonomía no procede únicamente del modelo. También depende de la capacidad de elegir y encadenar acciones dentro de un marco previamente definido.

Arquitectura agéntica, RAG, workflow de IA y sistema multiagente

Estos conceptos suelen intervenir en un mismo proyecto, pero no significan lo mismo.

El RAG puede alimentar a un agente, pero por sí solo no convierte una aplicación en agéntica. Del mismo modo, un workflow IA puede incluir varias llamadas a modelos y mantener, al mismo tiempo, un recorrido totalmente programado.

Una distinción útil consiste en separar los workflows, cuyo recorrido se define mediante código, de los agentes, que eligen dinámicamente su proceso y el uso de sus herramientas [2]. Esta frontera no siempre es absoluta: las arquitecturas más fiables suelen combinar etapas deterministas con determinadas decisiones confiadas al modelo.

Por último, una arquitectura agéntica no tiene por qué ser multiagente. Un único agente bien equipado suele ser más sencillo de probar, mantener y supervisar.

¿Cuáles son los componentes de una arquitectura agéntica?

Una solicitud de reembolso no puede gestionarse de forma fiable únicamente con un modelo y un prompt aislados. El sistema debe conocer la política comercial, localizar la transacción, comprobar los permisos del usuario, solicitar una validación y conservar un registro de cada etapa.

Una arquitectura empresarial puede representarse mediante siete capas:

Canal → Agente y orquestador → Contexto → Modelo → Herramientas → Controles → Resultado

La seguridad, la observabilidad y la gobernanza atraviesan todas estas capas. De hecho, las arquitecturas de referencia destinadas a empresas las consideran aspectos transversales, en lugar de módulos que se añaden al final del proyecto [3].

1. El canal y la percepción de la solicitud

El punto de entrada puede ser un chat, una llamada telefónica, un correo electrónico, una aplicación interna o un evento generado por un software empresarial.

Esta capa transforma la señal recibida en información aprovechable: transcripción de una llamada, identificación del idioma, archivos adjuntos, identidad del usuario o metadatos de un evento. También debe rechazar los formatos no válidos y detectar las entradas que requieran un tratamiento específico.

En un call assist, por ejemplo, un error de transcripción en un número de pedido puede afectar a todo el proceso. Por ello, la arquitectura debe prever una confirmación explícita antes de ejecutar cualquier acción basada en un dato crítico.

2. El modelo, los objetivos y las instrucciones

El modelo interpreta la situación y elige el siguiente paso. Sus instrucciones especifican su función, su objetivo, sus límites, las reglas de negocio y las circunstancias en las que debe recurrir a una persona.

Un buen objetivo debe poder verificarse. «Ayudar al cliente» es demasiado impreciso. «Identificar el pedido, determinar si todavía puede modificarse la dirección y ejecutar el cambio después de recibir confirmación» ofrece una condición de éxito mucho más útil.

No siempre es necesario utilizar el modelo más potente en cada etapa, especialmente si tenemos en cuenta los costes. Una arquitectura puede reservar un modelo avanzado para la planificación o los casos ambiguos y utilizar un modelo más ligero para clasificar una intención, extraer una referencia o dar formato a una respuesta.

3. El contexto, el RAG y la memoria

El contexto inmediato agrupa la información necesaria para la etapa en curso: solicitud del cliente, resultados de las herramientas, reglas aplicables y estado del caso.

El RAG aporta conocimientos procedentes de documentos externos al modelo: catálogo, procedimientos internos, condiciones contractuales o base de ayuda. La memoria, por su parte, conserva determinados elementos más allá de una única ejecución.

Conviene distinguir tres niveles:

• la memoria de trabajo, limitada a la ejecución actual;
• la memoria conversacional, utilizada durante varios intercambios;
• la memoria persistente, almacenada para utilizarla posteriormente.

Conservarlo todo incrementa los costes, el ruido contextual y el riesgo de exponer datos innecesarios. Una arquitectura sólida define qué puede memorizarse, durante cuánto tiempo y con qué finalidad. La memoria tampoco equivale al aprendizaje automático: guardar una preferencia de un cliente no significa que el modelo haya mejorado.

4. Herramientas, API y conectores

Un modelo de lenguaje no puede, por sí solo, consultar un CRM, modificar una cita o enviar un correo electrónico. Para intervenir en un software, el agente debe utilizar una herramienta puesta a su disposición por la arquitectura.

En este contexto, pueden distinguirse tres conceptos:

• La herramienta corresponde a una acción que el agente puede solicitar, por ejemplo, buscar un cliente, consultar un pedido o crear un ticket.
• La API es la interfaz técnica que transmite esa solicitud al software correspondiente.
• El conector facilita la integración entre ambos sistemas y se ocupa, entre otras cosas, de los formatos de datos y la autenticación.

Para una solicitud de modificación de una cita, el agente podría disponer de tres herramientas: consultar el expediente del cliente, buscar los horarios disponibles y registrar la nueva cita. No debería disponer de acceso general al software de planificación si esas tres funciones son suficientes.

Cada herramienta debe estar, por tanto, sujeta a reglas precisas:

• qué información debe proporcionar el agente;
• qué datos puede consultar o modificar;
• qué identidad y permisos se utilizan;
• en qué casos es obligatoria una confirmación humana;
• cómo comunica la herramienta un resultado correcto o un error.

La arquitectura también debe evitar que una misma acción se ejecute dos veces. Si el agente vuelve a realizar una solicitud después de un retraso en la respuesta, el sistema debe comprobar que la cita o el reembolso no se haya registrado previamente antes de repetir la operación.

El Model Context Protocol, o servidor MCP, estandariza la forma en que una aplicación presenta recursos y herramientas a un sistema de IA. Su arquitectura permite, entre otras cosas, separar los diferentes servidores y limitar el contexto transmitido a cada uno de ellos [4].

MCP facilita, por tanto, la conexión entre un agente y servicios externos. Sin embargo, no decide qué acciones están autorizadas ni qué reglas de negocio deben aplicarse.

Estos controles siguen siendo responsabilidad de la empresa: un agente autorizado para consultar una ficha de cliente no debería poder modificarla automáticamente, y una herramienta de reembolso solo debería estar disponible en las situaciones previstas.

5. El orquestador y la gestión del estado

El orquestador controla el bucle de ejecución. Transmite los mensajes, llama a los modelos, ejecuta las herramientas y comprueba si el trabajo debe continuar.

El estado permite saber en qué punto se encuentra la tarea: información ya recopilada, decisiones tomadas, validaciones obtenidas, errores encontrados y siguiente paso previsto. En un proceso largo, este estado debe conservarse en un almacenamiento persistente y no únicamente en el historial de conversación.

Las condiciones de parada son indispensables. El sistema puede detenerse cuando:

• obtiene un resultado conforme a un esquema esperado;
• alcanza un número máximo de etapas;
• encuentra un error del que no puede recuperarse;
• le falta información;
• necesita una autorización;
• detecta que el objetivo ya se ha alcanzado.

Sin estos límites, un agente puede repetir una búsqueda, multiplicar las llamadas a API o transferir indefinidamente la tarea entre diferentes componentes.

6. Los mecanismos de protección y la supervisión humana

Los mecanismos de protección combinan reglas deterministas y controles semánticos. Pueden verificar las entradas, los parámetros enviados a las herramientas, los resultados obtenidos y la respuesta final.

Una solicitud para consultar un expediente puede ejecutarse automáticamente. Una modificación de dirección puede requerir confirmación. Un reembolso de importe elevado puede necesitar la aprobación de un responsable. La intervención humana debe depender del riesgo, en lugar de añadirse de forma uniforme a todas las etapas.

El mecanismo de transferencia debe proporcionar al asesor el motivo del contacto, la información verificada, las acciones ya intentadas y la causa de la escalada. De lo contrario, el agente automatiza el inicio del recorrido, pero obliga al cliente a volver a explicar su situación desde el principio.

7. Observabilidad y evaluaciones

Los registros técnicos no son suficientes. Debe ser posible reconstruir el recorrido seguido: modelo utilizado, herramienta seleccionada, parámetros enviados, resultado devuelto, control activado y decisión final.

Las evaluaciones deben abarcar diferentes niveles:

• exactitud de la respuesta;
• elección de la herramienta adecuada;
• validez de los parámetros;
• cumplimiento de las reglas de negocio;
• éxito real de la acción;
• pertinencia de la transferencia a una persona;
• coste y duración de la ejecución.

Un agente puede generar un mensaje convincente y, al mismo tiempo, no haber conseguido modificar el expediente. El KPI decisivo es entonces el estado realmente registrado en el sistema empresarial, no la aparente calidad del texto.

Agente único, workflow o sistema multiagente: ¿cuál elegir?

Para gestionar una consulta de facturación, pueden plantearse tres arquitecturas. Un agente único puede consultar la factura y explicar la diferencia. Un workflow puede imponer una secuencia fija de controles. Un sistema multiagente puede distribuir el análisis entre un agente documental, un agente contable y otro encargado de elaborar la respuesta.

La solución más compleja solo está justificada si mejora un resultado medible.

El agente único equipado con varias herramientas

Un agente único resulta adecuado cuando el ámbito de actuación es coherente, las herramientas comparten reglas comunes y el número de decisiones sigue siendo manejable.

Sus ventajas son concretas: menos transferencias de contexto, un recorrido más fácil de rastrear y menos llamadas a modelos. Además, puede evolucionar progresivamente mediante la incorporación de nuevas herramientas o modelos de instrucciones especializados.

Sin embargo, alcanza sus límites cuando sus instrucciones se vuelven contradictorias, sus herramientas requieren niveles de autorización incompatibles o varios ámbitos empresariales necesitan trabajar de forma independiente.

Los workflows agénticos

Un workflow mantiene una estructura determinista y, al mismo tiempo, delega determinadas decisiones en un modelo. Este enfoque resulta especialmente adecuado para procesos cuyas principales etapas ya están definidas.

Hay cuatro patrones que aparecen con frecuencia:

• Secuencial: cada etapa transforma el resultado de la anterior.
• Enrutamiento: una solicitud se dirige hacia una rama especializada.
• Paralelización: varios análisis independientes se ejecutan simultáneamente.
• Evaluador-optimizador: un componente genera un resultado, otro lo evalúa y, si es necesario, se genera una nueva versión.

En el caso de una reclamación, el recorrido puede exigir la identificación, la recopilación de los hechos y la comprobación de los requisitos, al tiempo que permite al modelo elegir qué documentos consultar. De este modo, la estructura sigue siendo predecible sin tener que predeterminar cada microdecisión.

Las arquitecturas multiagente

Un sistema multiagente resulta pertinente cuando es realmente necesario separar las responsabilidades. Un agente supervisor puede delegar tareas en agentes especializados, o cada agente puede transferir el control al siguiente.

La documentación sobre arquitecturas distingue, entre otros, los modelos secuenciales, concurrentes, con conversación grupal, con handoff y con planificación central [5] [6].

La opción más recomendable es empezar con un agente único o un workflow controlado. El sistema multiagente entra en juego cuando la especialización, la separación de permisos o la ejecución en paralelo compensan realmente la complejidad adicional.

¿Cómo diseñar una arquitectura agéntica en seis pasos?

Una empresa que quiere «incorporar un agente a su servicio de atención al cliente» parte de una tecnología. Un enfoque más sólido consiste en partir de un proceso concreto, por ejemplo, reducir las solicitudes manuales para cambiar la fecha de una cita.

1. Definir un objetivo operativo

El caso de uso debe tener un resultado observable: cita modificada, ticket clasificado, ficha del CRM enriquecida o solicitud transferida al departamento adecuado.

A continuación, hay que identificar las entradas, las excepciones y los posibles motivos de error. Si el proceso puede describirse íntegramente mediante unas pocas reglas estables, una automatización tradicional suele ser más fiable y menos costosa.

2. Establecer el nivel de autonomía

Cada acción puede clasificarse según su impacto y su reversibilidad.

La consulta de un estado puede realizarse automáticamente. La eliminación de una cuenta o la autorización de un gasto no deberían depender de una simple decisión probabilística.

3. Mapear los datos y las herramientas

Para cada herramienta, documenta los datos consultados, los datos modificados, la identidad utilizada y las dependencias externas. Separa, en la medida de lo posible, las funciones de lectura y escritura.

Este mapeo suele revelar los verdaderos obstáculos: fuentes de datos incoherentes, API incompletas, permisos demasiado amplios o ausencia de una fuente de información de referencia.

4. Elegir el patrón más sencillo

Empieza por un recorrido estándar. Añade enrutamiento si varias intenciones requieren tratamientos diferentes y recurre a agentes especializados únicamente cuando sea necesario aislar funciones o permisos.

La complejidad debe responder a una necesidad identificada. «Un agente por departamento» no constituye por sí solo un principio de arquitectura suficiente.

5. Anticipar los errores

Define los tiempos de espera, los reintentos, los límites de llamadas, las respuestas alternativas y las transferencias a personas. Un error de una herramienta debe ser visible para el orquestador y no presentarse como si la acción se hubiera ejecutado correctamente.

Para las acciones sensibles, una clave de idempotencia evita que un nuevo intento genere dos reembolsos, dos citas o dos tickets.

6. Evaluar antes de ampliar

El conjunto de pruebas debe incluir las solicitudes habituales, las formulaciones ambiguas, la información incompleta, los ataques y las excepciones relacionadas con las reglas de negocio.

Un proyecto piloto puede comenzar funcionando en modo de recomendación: el agente prepara la acción, pero es un empleado quien la ejecuta. Una vez medidos los resultados, determinadas categorías de bajo riesgo pueden pasar a ejecutarse automáticamente.

¿Cómo hacer que el sistema sea fiable, seguro y gobernable?

Un chatbot que consulta una sección de preguntas frecuentes presenta principalmente el riesgo de proporcionar una respuesta incorrecta. Un agente autorizado para escribir en un CRM, enviar un mensaje o modificar un contrato tiene una superficie de ataque mucho mayor.

Controlar los accesos y las acciones

Entre los riesgos específicos de las arquitecturas agénticas se encuentran el desvío de objetivos, el uso indebido de herramientas, el abuso de identidad, el envenenamiento de la memoria y la propagación de errores entre agentes [7].

Algunas reglas fundamentales permiten reducir esta exposición:

• aplicar el principio de mínimo privilegio;
• separar la lectura, la propuesta y la ejecución;
• validar los parámetros del lado del servidor;
• aislar los datos de cada usuario;
• no tratar nunca el contenido recuperado como una instrucción de confianza;
• solicitar una confirmación explícita para las acciones sensibles;
• disponer de un mecanismo de parada inmediata.

La especificación MCP publicada en julio de 2026 también recomienda limitar las autorizaciones a los scopes necesarios y comprobar que cada token haya sido emitido para el servidor en el que se utiliza [8].

Proteger los datos y garantizar la trazabilidad

La CNIL recuerda que la seguridad de un sistema de IA debe combinar las medidas tradicionales relacionadas con la infraestructura, los permisos y el desarrollo con un análisis de los riesgos específicos de la IA [9].

En una arquitectura agéntica, este análisis también abarca los datos introducidos en el contexto, los resultados devueltos por las herramientas y la información almacenada en la memoria.

En particular, debe ser posible responder a cinco preguntas:

1. ¿Qué identidad solicitó la acción?
2. ¿Qué agente tomó la decisión?
3. ¿En qué información se basó esa decisión?
4. ¿Qué herramienta la ejecutó?
5. ¿Qué estado se creó realmente?

Esta trazabilidad facilita las auditorías, pero también la mejora continua. Permite identificar si un error procede del modelo, del contexto, de una herramienta o de una regla de negocio mal definida.

Encontrar el equilibrio entre calidad, coste y latencia

Una arquitectura multiagente multiplica las instrucciones, las transferencias de contexto y las llamadas a los modelos. Puede mejorar la especialización, pero también aumentar el tiempo de respuesta.

Por tanto, el coste debe analizarse teniendo en cuenta cada ejecución completa: tokens consumidos, llamadas a herramientas, reintentos e intervenciones humanas. Una resolución más costosa puede seguir siendo rentable si evita una cantidad considerable de trabajo manual; por el contrario, utilizar tres agentes para comprobar una respuesta sencilla genera, sobre todo, más costes y latencia.

Ejemplo de arquitectura agéntica para la atención al cliente

Imaginemos que un cliente llama para cambiar la fecha de una intervención técnica. El objetivo no consiste únicamente en responder a su pregunta, sino en conseguir una cita válida o realizar una transferencia correctamente documentada.

El proceso puede organizarse de la siguiente manera:

Imaginemos que un cliente llama para cambiar la fecha de una intervención técnica. El objetivo no consiste únicamente en indicarle qué debe hacer, sino en registrar una nueva cita o, en caso de que surja una excepción, transferir un expediente completo a un asesor.

El proceso puede organizarse de la siguiente manera:

1. Agente de voz: recibe al cliente, transcribe su solicitud e identifica su intención.
2. Servicio de identidad: verifica la información necesaria para acceder al expediente.
3. Orquestador: conserva el estado de la solicitud, carga las reglas aplicables y determina la siguiente acción.
4. Cliente MCP: identifica las herramientas autorizadas para esa tarea y transmite las solicitudes del agente a los servidores correspondientes.
5. Servidor MCP del CRM: expone funciones limitadas, como consultar el contrato, la dirección o el historial de intervenciones.
6. Servidor MCP de planificación: permite buscar los horarios disponibles y, después de recibir la confirmación, modificar la cita.
7. Agente: compara las posibilidades, propone varios horarios al cliente y recoge su elección.
8. Mecanismo de protección: comprueba la identidad, la dirección, el horario seleccionado y la existencia de una confirmación explícita.
9. Herramienta empresarial: registra la nueva cita a través de la API del software de planificación.
10. Control final: comprueba el estado realmente registrado antes de confirmar que la operación se ha realizado correctamente.
11. Transferencia a una persona: interviene cuando ningún horario resulta adecuado, alguna información sigue siendo incierta o la situación queda fuera del ámbito autorizado.

Diseñar la autonomía por niveles

Una arquitectura agéntica eficaz no busca automatizarlo todo, especialmente cuando se trata de tareas que requieren control. Asigna al agente un nivel de autonomía proporcional al riesgo y a la capacidad de verificar sus resultados.

El punto de partida más sólido sigue siendo un caso de uso bien delimitado, un agente o un workflow sencillo, herramientas con permisos limitados y un conjunto de evaluaciones representativo. A partir de ahí, la arquitectura puede evolucionar hacia una mayor autonomía o incorporar varios agentes cuando los resultados justifiquen esa complejidad.

Para aplicar este enfoque a la atención al cliente, empieza por mapear un recorrido concreto: información necesaria, decisiones esperadas, herramientas utilizadas, excepciones y transferencia a una persona.

Los equipos de Ringover pueden ayudarte a identificar los componentes conversacionales y de telefonía más adecuados para este recorrido. ¿Tienes alguna pregunta? Consulta a nuestros expertos nuestras soluciones de IA.

FAQs sobre la arquitectura agéntica

¿Una arquitectura agéntica tiene que ser necesariamente multiagente?

No. Un único agente equipado con varias herramientas puede ser suficiente. Una arquitectura multiagente resulta pertinente cuando el proceso requiere competencias especializadas, diferentes permisos o tratamientos en paralelo.

¿Qué diferencia hay entre una arquitectura RAG y una arquitectura agéntica?

El RAG recupera conocimientos para enriquecer la respuesta de un modelo. Una arquitectura agéntica incorpora además la toma de decisiones, el uso de herramientas, la gestión del estado y la ejecución de acciones.

¿Para qué sirve un orquestador de agentes de IA?

Gestiona las llamadas a modelos y herramientas, transmite el contexto, conserva el estado de la tarea y aplica las condiciones de parada. En un sistema multiagente, también puede asignar tareas y gestionar las transferencias.

¿Qué papel desempeña MCP en una arquitectura agéntica?

MCP estandariza la forma en que una aplicación expone recursos, prompts y herramientas a un sistema de IA. Facilita su descubrimiento y utilización, pero no sustituye la orquestación, las reglas de negocio ni los controles de seguridad.

¿Cómo elegir entre un workflow y un agente de IA?

Elige un workflow cuando sea posible prever las etapas y las excepciones. Un agente resulta útil cuando el sistema necesita interpretar información no estructurada, adaptar su recorrido o elegir entre varias herramientas en función del contexto.

¿Cómo se puede probar una arquitectura agéntica?

Es necesario probar la respuesta final, pero también las decisiones intermedias: selección de herramientas, parámetros, permisos, gestión de errores y estado creado en los sistemas empresariales. Las pruebas deben incluir situaciones ambiguas, incompletas y maliciosas.

Referencias

• [1] https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/
• [2] https://www.anthropic.com/engineering/building-effective-agents
• [3] https://docs.aws.amazon.com/prescriptive-guidance/latest/govern-architect-agentic-ai/enterprise-architecture.html
• [4] https://modelcontextprotocol.io/specification/2026-07-28/architecture
• [5] https://docs.cloud.google.com/architecture/choose-design-pattern-agentic-ai-system
• [6] https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/ai-agent-design-patterns
• [7] https://genai.owasp.org/initiatives/agentic-security-initiative/
• [8] https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization
• [9] https://www.gob.mx/buengobierno/documentos/medidas-de-seguridad-previstas-por-la-lgpdppso
• [10] https://dicodunumerique.com/definitions/handoff

Publicado el 4 Septiembre 2026.