Arquitectura de agentes de IA: componentes, memoria y orquestación

La arquitectura de un agente de IA es el conjunto de componentes que rodean a un modelo de lenguaje y deciden qué ve, qué puede hacer y qué ocurre cuando se equivoca. Un diseño viable tiene ocho partes: un punto de entrada que establece la identidad, un bucle de control, un adaptador de modelo, un constructor de contexto, una capa de herramientas, una puerta de políticas, un almacén de estado y una traza. La memoria y los agentes adicionales son opcionales, y cada uno trae modos de fallo que tendrá que pagar. La línea divisoria que condiciona todo lo demás: el modelo propone, y un código determinista decide qué se ejecuta realmente.

Este artículo es una referencia de esa estructura, para leer componente a componente. Si prefiere recorrer una construcción en orden, con Python ejecutable para el bucle, consulte cómo crear un agente de IA. Las prácticas de producción, como las reglas de diseño de herramientas, las salvaguardas y la evaluación, están en nuestro artículo sobre desarrollo de agentes de IA. El estado de los productos y protocolos corresponde a noviembre de 2026.

El diagrama de arquitectura

                 user or calling system
                           |
                           v
               +-----------------------+
               | ENTRY POINT           |   who is asking, on whose
               | identity, disclosure  |   permissions, with what budget
               +-----------+-----------+
                           |
                           v
 +-------------------------+----------------------------+
 | CONTROL LOOP (your code; owns the run)               |
 |                                                      |
 |   +-----------------+        +-------------------+   |      +--------------+
 |   | CONTEXT BUILDER |------->| MODEL ADAPTER     |---+----->| model        |
 |   | what the model  |        | one call, one     |<--+------| (hosted or   |
 |   | sees this step  |        | neutral format    |   |      | self-run)    |
 |   +--+-----------+--+        +---------+---------+   |      +--------------+
 |      ^           ^                     |             |
 |      |           |                     | proposal:   |
 |      |           |                     | text or     |
 |      |           |                     | tool call   |
 |      |           |                     v             |
 |      |           |           +-------------------+   |      +--------------+
 |      |           |           | POLICY GATE       |---+----->| person       |
 |      |           |           | allow, deny, or   |<--+------| (approval    |
 |      |           |           | ask a person      |   |      |  queue)      |
 |      |           |           +---------+---------+   |      +--------------+
 |      |           |                     | allowed     |
 |      |           |                     v             |
 |      |           |           +-------------------+   |      +--------------+
 |      |           +-----------| TOOL LAYER        |---+----->| your systems |
 |      |        tool results   | registry, schemas,|<--+------| and data     |
 |      |        (UNTRUSTED)    | scoped credentials|   |      | (UNTRUSTED   |
 |      |                       +-------------------+   |      |  content)    |
 +------+------------------+----------------------+-----+      +--------------+
        ^                  |                      |
        v                  v                      v
 +--------------+   +--------------+   +----------------------------+
 | MEMORY       |   | STATE STORE  |   | TRACE                      |
 | across runs  |   | this run,    |   | every proposal, decision,  |
 | (optional)   |   | checkpoints  |   | call; feeds evaluation     |
 +--------------+   +--------------+   +----------------------------+

El mismo diagrama en palabras

Una solicitud llega al punto de entrada (ENTRY POINT), que le asigna una identidad, un conjunto de permisos y un presupuesto, y después inicia una ejecución. A partir de ahí, esa ejecución pertenece al bucle de control (CONTROL LOOP).

En cada paso, el constructor de contexto (CONTEXT BUILDER) reúne lo que verá el modelo: instrucciones, la tarea, resultados recientes de herramientas y cualquier cosa leída de la memoria. El adaptador de modelo (MODEL ADAPTER) lo envía al modelo y devuelve una de estas dos cosas: una respuesta final o una llamada a una herramienta propuesta. Una propuesta es solo una propuesta. Va a la puerta de políticas (POLICY GATE), que la permite, la deniega con un error que el modelo puede leer o suspende la ejecución y pregunta a una persona. Una llamada permitida pasa a la capa de herramientas (TOOL LAYER), que la ejecuta con credenciales limitadas a esa herramienta y devuelve el resultado al constructor de contexto para el paso siguiente.

Dos hechos del dibujo importan más que sus cajas. El contenido que vuelve de las herramientas no es de confianza (UNTRUSTED), porque un correo de un cliente o una página web pueden contener instrucciones, y ese contenido vuelve a entrar en el contexto del modelo en el paso siguiente. Y la puerta de políticas está después del modelo en el camino de salida, donde nada de lo que el modelo lea o escriba puede eliminarla. El almacén de estado (STATE STORE), la memoria (MEMORY) y la traza (TRACE) están debajo del bucle: el almacén de estado guarda esta ejecución, la memoria lleva información de una ejecución a otra y la traza lo registra todo.

Los componentes, uno a uno

Punto de entrada

El punto de entrada responde a tres preguntas antes de cualquier llamada al modelo: quién pregunta, con los permisos de quién actuará el agente y cuánto presupuesto tiene esta ejecución. Si se omite, el agente recurre a una única cuenta de servicio amplia, y cada usuario puede llegar a todo lo que alcance esa cuenta. El Top 10 for Agentic Applications de OWASP (diciembre de 2025) recoge este tipo de problema como ASI03, Identity & Privilege Abuse. El CAISI del NIST puso en marcha una AI Agent Standards Initiative en febrero de 2026, con la identidad entre sus pilares de investigación, pero su página no recogía ninguna guía definitiva sobre agentes a fecha de la actualización de agosto de 2026.

En los agentes de cara al cliente, el deber de transparencia del artículo 50 del Reglamento de IA de la UE, aplicable desde el 2 de agosto de 2026, también se resuelve con más facilidad aquí.

Bucle de control

El bucle es código normal que alterna llamadas al modelo y llamadas a herramientas hasta que salta una condición de parada. Suyos son el recuento de pasos, el plazo y la decisión de que una ejecución ha terminado. No debe contener lógica de negocio. Lo que va en otro sitio: las reglas, en la puerta de políticas; los prompts, en el constructor de contexto; las integraciones, en la capa de herramientas.

Una opción razonable por defecto es integrar el bucle como un nodo de un flujo de trabajo mayor, con pasos fijos antes (clasificar, enrutar) y después (validar la salida). La guía práctica tiene una versión ejecutable con cada condición de parada enumerada.

Adaptador de modelo

Una función, con un formato neutro para los mensajes y las llamadas a herramientas, que traduce al proveedor que use. Contiene el tiempo de espera, los reintentos por límite de peticiones, la versión fijada del modelo y la alternativa de respaldo. El enrutamiento de modelos por paso también vive aquí, con un modelo más pequeño para resumir la salida de las herramientas si su conjunto de evaluación no muestra pérdida.

Constructor de contexto

El constructor de contexto decide qué ve el modelo en este paso. Sin él como módulo con nombre propio, los mensajes simplemente se acumulan. Sus tareas son mantener las instrucciones y la tarea en una posición estable, recortar o resumir la salida antigua de las herramientas, cargar solo las herramientas relevantes para la tarea y etiquetar qué contenido vino de fuera.

La lista LLM de OWASP para 2026 tiene una entrada llamada Hidden Context Exposure (LLM08). Nuestra regla para este componente: nunca ponga un secreto en el contexto dando por hecho que el modelo lo guardará.

Capa de herramientas

La capa de herramientas es un registro: para cada herramienta, un esquema, una clase de riesgo, sus credenciales, un tiempo de espera y un límite de peticiones. La clase de riesgo (lectura, escritura reversible, escritura irreversible) es lo que la conecta con la puerta de políticas. Las herramientas pueden ser funciones dentro del proceso o servidores MCP remotos.

Para las herramientas remotas, la revisión de MCP del 28 de julio de 2026 cambia el panorama de despliegue. Las sesiones de protocolo y el handshake de inicialización (initialize) han desaparecido, la versión y las capacidades viajan con cada petición y server/discover es obligatorio. Nuestra lectura es que esto facilita ejecutar servidores MCP remotos detrás de balanceadores de carga corrientes, ya que el protocolo deja de mantener una sesión, pero cualquier estado que necesite su herramienta pasa a ser problema suyo. HTTP+SSE, Sampling, Roots y Logging están entre las partes declaradas obsoletas, con un plazo mínimo de doce meses, así que compruebe de qué dependen sus servidores actuales.

La cadena de suministro es el riesgo estructural aquí, ya que cada servidor remoto es código que tiene credenciales y cuyas descripciones entran en el contexto del modelo. LLM04 y ASI04 de OWASP lo cubren, y MITRE ATLAS tiene una técnica para ello, AI Agent Tool Poisoning (AML.T0110).

Puerta de políticas

La puerta es código determinista que inspecciona cada llamada propuesta frente a los permisos del usuario, las listas de permitidos, los presupuestos y la clase de riesgo de la herramienta, y después responde permitir, denegar o preguntar. El modelo no puede editarla, y no depende de que el modelo coopere. De todos los componentes, este es el que más limita los daños cuando otro falla. La guía práctica de OpenAI nombra dos desencadenantes para la intervención humana: superar los umbrales de fallo y las acciones que son «delicadas, irreversibles o de consecuencias importantes». Ambos se implementan aquí.

Una arquitectura sin puerta confía la seguridad al prompt, y esa es una mala apuesta. «The Attacker Moves Second» (Nasr, Carlini et al., octubre de 2025) informa de que los ataques adaptativos sortearon 12 defensas publicadas contra la inyección de prompts, la mayoría con un éxito superior al 90%, aunque la mayoría de esas defensas había declarado tasas de ataque cercanas a cero. Nuestro artículo sobre seguridad de los agentes de IA trata el modelo de amenazas y los controles.

Almacén de estado

El estado de la ejecución es todo lo necesario para reanudar o auditar una ejecución: número de paso, mensajes o un puntero a ellos, llamadas realizadas, aprobaciones pendientes, presupuesto consumido. Su sitio es una base de datos, y debe quedar fuera del prompt. La necesidad se hace evidente con las aprobaciones, ya que una ejecución suspendida dos días en la mesa de alguien no puede vivir en la memoria del proceso. La documentación de LangGraph lo llama memoria a corto plazo, estado limitado a un hilo y conservado mediante checkpoints, y el OpenAI Agents SDK habla de sesiones. Sea cual sea la palabra, escriba un checkpoint después de cada paso y trate las herramientas de escritura como reintentables tras una caída, lo que significa darles claves de idempotencia.

Traza y enganches de evaluación

Cada ejecución debe dejar un registro de cada contexto enviado, propuesta devuelta, decisión de la puerta y resultado de herramienta bajo un único ID de ejecución. El sistema de evaluación lee ese mismo registro: lo que «Demystifying evals for AI agents» (enero de 2026), de Anthropic, llama transcripción es, en un sistema de producción, esta traza. Las convenciones semánticas GenAI de OpenTelemetry incluyen spans de agente pero siguen marcadas como Development, así que adóptelas detrás de un envoltorio fino propio, y un cambio de nombre tocará un solo archivo.

Las trazas contienen prompts y salidas de herramientas, a menudo datos personales. En Alemania, las trazas que muestran quién usó el agente y cómo son también un asunto que probablemente llegue al comité de empresa, como explica nuestro artículo sobre el proceso.

Memoria de los agentes de IA

«Memoria» nombra varias cosas, y las preguntas de diseño son distintas para cada una. La documentación de LangGraph, de LangChain, la divide en memoria a corto plazo (el almacén de estado anterior) y memoria a largo plazo entre sesiones, esta última repartida en tres tipos: semántica, episódica y procedimental. Es el vocabulario de un proveedor, aplicado aquí a decisiones de almacenamiento.

Sobre esta tabla tenemos una opinión firme: empiece sin ninguna memoria a largo plazo. La mayoría de los primeros agentes pueden leer lo que necesitan del sistema de origen mediante una herramienta, y el sistema de origen sigue siendo correcto y tiene un responsable. La memoria añade una segunda copia que puede quedar desfasada o envenenarse. Una sola instrucción inyectada y escrita en la memoria llega a ejecuciones posteriores que nunca vieron el contenido del atacante. OWASP recoge Memory & Context Poisoning como ASI06, y MITRE ATLAS tiene una subtécnica Memory dentro de AI Agent Context Poisoning (AML.T0080.001).

Los índices vectoriales tienen su propia entrada en la lista de OWASP para 2026, LLM09, Vector and Embedding Weaknesses. Si la memoria contiene documentos, la recuperación tiene que filtrar por los permisos del usuario al que se atiende, como en nuestro diseño de chatbot RAG para documentos internos.

La memoria sobre personas identificables son datos personales según el RGPD, así que cada almacén a largo plazo necesita un plazo de conservación y una forma de borrar las entradas de una persona. Resulta mucho más fácil si las entradas están estructuradas y etiquetadas por interesado desde el principio, y es doloroso añadirlo más tarde a resúmenes en prosa.

Tipos de agentes de IA

La clasificación de manual viene de Artificial Intelligence: A Modern Approach, de Stuart Russell y Peter Norvig. Es anterior a los LLM y ordena los agentes según cómo deciden:

Estos tipos describen la lógica de decisión, así que dicen poco sobre lo que hay que construir alrededor de un agente basado en un LLM. La mayoría de los agentes basados en LLM se comportan como agentes basados en objetivos, sea cual sea el resto de lo que hagan. La propia palabra «agente» también varía entre proveedores: la descripción general de Google Cloud usa una definición laxa de aplicaciones que responden a peticiones en lenguaje natural, mientras que OpenAI y Anthropic exigen que el modelo controle la ejecución. Nuestro artículo sobre agentes de IA e IA agéntica compara esas definiciones. Para la arquitectura, tres propiedades comprobables dicen más, porque cada una cambia lo que hay que construir.

Un agente de solo lectura y una sola petición que elige entre rutas fijas necesita poco más que el bucle y la capa de herramientas. Un agente de varios días con escrituras irreversibles necesita los ocho componentes, sea cual sea su categoría comercial. El ADK de Google, por ejemplo, separa agentes LLM, agentes de flujo de trabajo y agentes personalizados, lo que corresponde aproximadamente al primer eje.

Patrones de orquestación de agentes de IA

La orquestación decide cómo se mueve el trabajo cuando interviene más de una instancia de modelo. «AI Agent Orchestration Patterns» (febrero de 2026), de Microsoft, nombra cinco: secuencial, concurrente, chat de grupo, traspaso (handoff) y magentic. La guía de OpenAI nombra dos: un patrón de gestor (manager), en el que un LLM central orquesta, y uno descentralizado, en el que los agentes se traspasan el trabajo entre sí. El consejo de Microsoft, en paráfrasis, es usar el nivel de complejidad más bajo que cumpla de forma fiable sus requisitos. Estamos de acuerdo: cada paso a lo largo de la tabla siguiente añade nuevas formas de fallar.

Agente único

Quédese aquí hasta que un problema medido le obligue a moverse. Las presiones habituales son el exceso de herramientas y un contexto saturado, y ambas suelen arreglarse con una tarea más acotada o cargando las herramientas por tipo de tarea. La debilidad estructural es que el agente se corrige sus propios deberes y reúne todos los permisos en un solo sitio. Un paso de verificación determinista resuelve lo primero sin ninguna maquinaria multiagente.

Orquestador-trabajadores

Este patrón es el patrón de gestor de OpenAI con otras palabras. Hay dos razones que lo justifican. Las partes independientes pueden ejecutarse de forma concurrente, como al buscar en varias fuentes sin relación entre sí. O bien las distintas partes necesitan permisos distintos, de modo que un trabajador de investigación de solo lectura que procesa contenido no fiable nunca tenga las credenciales de escritura.

El punto débil es el límite entre ambos. Un trabajador ve solo lo que el orquestador decidió contarle, y el orquestador ve solo lo que el trabajador decidió devolver. La inyección de prompts también lo cruza: un trabajador que lee un documento envenenado puede pasar hacia arriba la instrucción del atacante dentro de su resultado. Las entradas agénticas de OWASP correspondientes son Agent Goal Hijack (ASI01) e Insecure Inter-Agent Communication (ASI07). Trate la salida del trabajador como trata la salida de las herramientas: como no fiable y validada contra un esquema. Un contrato de traspaso podría ser así:

{
  "run_id": "r-20261105-0412",
  "parent_step": 3,
  "worker": "invoice_research",
  "permissions": ["erp.invoices.read"],
  "budget": {"steps": 8, "seconds": 120},
  "goal": "Find the purchase order that matches invoice INV-1001.",
  "must_return": {
    "status": "found | not_found | gave_up",
    "purchase_order_id": "string or null",
    "evidence": ["source record ids"]
  }
}

Fíjese en lo que el contrato no incluye: la conversación completa del orquestador y cualquier credencial. El trabajador recibe un presupuesto recortado del total de la ejecución, de modo que el fan-out no puede superar el tope fijado en el punto de entrada. Los permisos solo pueden estrecharse al bajar.

Un ejemplo público y atribuible es el Project Nemo de Allianz en Australia. Allianz informó de siete agentes que gestionan reclamaciones por alimentos estropeados por debajo de 500 AUD, en funcionamiento desde julio de 2025, con una reducción del 80% en el tiempo de tramitación y liquidación y con una persona que toma cada decisión de pago. Son cifras de la propia Allianz, y no encontramos ninguna auditoría independiente. El artículo de Allianz no aclara de qué patrón se trata, así que solo extraemos de él una conclusión estructural: muchos agentes, una tarea acotada y el paso irreversible en manos de una persona.

Jerárquico

Una jerarquía es orquestador-trabajadores aplicado de forma recursiva, y querríamos un argumento sólido antes de usarla en los primeros sistemas de una empresa. Cada nivel resume para el nivel superior, de modo que el objetivo deriva al bajar y el detalle se pierde al subir. Un resultado erróneo puede ser recogido por ramas hermanas antes de que nadie lo note, que es ASI08 de OWASP, Cascading Failures. La delegación también tiende a blanquear autoridad: a menos que los permisos solo se estrechen en cada nivel, un agente de nivel bajo puede pedirle a uno superior que haga lo que él no puede, y eso vuelve a entrar en ASI03. Los bucles de delegación necesitan un límite de profundidad en el código.

Si equipos distintos son dueños de dominios distintos, considere en su lugar un orquestador plano que llame al agente de cada equipo a través de una interfaz estable. A2A es el protocolo creado para las llamadas de agente a agente. Su v1.0 es su primera especificación estable, y la Linux Foundation informa de más de 150 organizaciones que lo apoyan, aunque no define qué significa «apoyar» ni nombra clientes en producción. No encontramos datos independientes que comparen su adopción con la de MCP.

Traspasos

En un traspaso (handoff), el control pasa de un agente a otro sin un planificador central, el patrón que OpenAI llama descentralizado. Encaja en el triaje, donde un agente enruta a un especialista y se retira. Los modos de fallo son agentes que se devuelven un caso entre sí y una responsabilidad poco clara del resultado final, así que asigne un responsable por ejecución y ponga un tope al número de traspasos.

Construir o tomar de un framework

Los frameworks se diferencian sobre todo en cuáles de estos componentes aportan. Las descripciones siguientes son las de los propios proveedores.

Adopte lo que adopte, mantenga la puerta de políticas y el registro de herramientas en su propio código. Codifican sus reglas, y son lo que menos querrá reescribir cuando un framework cambie o, como AutoGen, se archive. El almacén de estado es razonable tomarlo de un framework, y lo mismo el propio bucle.

Dónde se ejecuta cada componente, en términos de la UE

El diagrama sirve también de mapa de datos para una revisión de protección de datos. El adaptador de modelo decide si los prompts salen de su región, así que, si la residencia importa, en esa caja va un endpoint alojado en la UE o un modelo propio. El contexto, el almacén de estado, la memoria y la traza guardan copias de todo lo que lee el agente, y cada copia necesita su propio control de acceso y su propia regla de conservación.

El Reglamento de IA de la UE clasifica por uso, de modo que ninguna decisión de arquitectura saca a un agente de la categoría de alto riesgo. Un agente que evalúa la solvencia de personas físicas entra en el punto 5, letra b), del anexo III se construya como se construya, y las obligaciones de los sistemas del anexo III se aplican a partir del 2 de diciembre de 2027 tras el Digital Omnibus, según indica la página de la Comisión Europea. La arquitectura puede hacer viable cumplir esas obligaciones: la traza le da registros, y la puerta de políticas, un punto documentado de supervisión humana.

Preguntas frecuentes

¿Qué diferencia hay entre la memoria y el estado de un agente de IA?

El estado pertenece a una sola ejecución y existe para que esta pueda reanudarse y auditarse. La memoria a largo plazo lleva información de una ejecución a otra. La documentación de LangGraph llama al primero memoria a corto plazo y divide la segunda en semántica, episódica y procedimental.

¿Qué debe incluir un diagrama de arquitectura de agentes de IA?

Como mínimo, el camino desde la propuesta del modelo hasta las herramientas pasando por una puerta de políticas, el camino de vuelta de los resultados no fiables de las herramientas, dónde aprueba una persona y dónde se guardan el estado y las trazas. Un diagrama que solo muestre «LLM, herramientas, memoria» omite las partes que limitan los daños.

¿Cuándo es mejor orquestador-trabajadores que un agente único?

Cuando partes de una tarea pueden ejecutarse en paralelo con poco contexto compartido o necesitan permisos distintos. Para ver los costes, consulte nuestro artículo sobre el coste de desarrollar un sistema multiagente. En los demás casos, un agente único es más fácil de probar y de depurar.

¿Una arquitectura de agentes necesita MCP o A2A?

Ninguno es obligatorio. MCP es útil cuando varios agentes o clientes comparten herramientas, y A2A cuando agentes de equipos o empresas distintos se llaman entre sí. Dentro de un mismo sistema bastan las funciones dentro del proceso y las llamadas a funciones normales.

Diseñar la arquitectura de un agente con AI Superior

AI Superior es una empresa de ingeniería de IA con sede en Darmstadt (Alemania), fundada en 2019 por científicos de IA, y desarrollamos aplicaciones LLM, sistemas RAG y agentes de IA para clientes B2B. Nuestros servicios de desarrollo de agentes de IA cubren el diseño y la construcción. Cuando la identidad, la auditoría y los sistemas existentes condicionan el diseño, consulte desarrollo de agentes de IA para grandes empresas.

Fuentes y lecturas recomendadas

• OpenAI, «A practical guide to building agents», 2025.
• Anthropic, «Building effective agents», diciembre de 2024.
• Russell, S. y Norvig, P., Artificial Intelligence: A Modern Approach.
• Grace, Hadfield, Olivares, De Jonghe (Anthropic), «Demystifying evals for AI agents», enero de 2026.
• Google Cloud, AI Agent Ecosystem overview, sin fecha.
• Microsoft, «AI Agent Orchestration Patterns», febrero de 2026.
• LangChain, documentación de memoria de LangGraph, consultada en noviembre de 2026.
• Documentación de los proyectos: OpenAI Agents SDK, Claude Agent SDK, Microsoft Agent Framework, Google ADK, CrewAI, consultada en noviembre de 2026.
• Model Context Protocol, «Key Changes» de la revisión 2026-07-28.
• Linux Foundation, nota de prensa sobre A2A, abril de 2026.
• OWASP, GenAI LLM Top 10 2026; Top 10 for Agentic Applications for 2026, diciembre de 2025.
• MITRE ATLAS, versión de contenido 2026.10, octubre de 2026.
• NIST CAISI, AI Agent Standards Initiative, febrero de 2026, página actualizada en agosto de 2026.
• OpenTelemetry, convenciones semánticas para IA generativa.
• Nasr, Carlini et al., «The Attacker Moves Second», octubre de 2025.
• Allianz, artículo sobre Project Nemo, noviembre de 2025.
• Comisión Europea, página sobre el marco regulador del Reglamento de IA de la UE; anexo III del Reglamento de IA de la UE.