ARQUITECTURA DE SISTEMAS AGÉNTICOS
Arquitectura de un agente de IA: componentes, límites y flujo de ejecución
Un agente no es solo un modelo conectado a herramientas. En producción necesita responsabilidades claras para identidad, contexto, estado, permisos, ejecución y observabilidad.
La pregunta central no es qué framework utilizar, sino qué debe decidir el modelo y qué debe seguir controlando el sistema que lo rodea.
RESPUESTA RÁPIDA
La arquitectura de un agente de IA define qué componentes participan, qué responsabilidad tiene cada uno, cómo intercambian información y qué límites existen antes de producir una acción real. El modelo es una pieza, no el sistema completo. La arquitectura puede incluir orquestación, contexto, estado, memoria, RAG, tools, policy, executor, runtime, supervisión humana, trazas y evals; no todos esos componentes son obligatorios.
La regla práctica de este artículo: el modelo decide dentro de límites; la arquitectura define los límites.
Qué significa arquitectura de un agente de IA
Cuando una empresa empieza a diseñar un agente de IA es fácil dibujar el sistema como cuatro cajas: modelo, memoria, herramientas y un orquestador que las conecta.
Ese dibujo puede servir para una primera conversación, pero se queda corto en cuanto el agente debe trabajar sobre sistemas reales.
¿Quién identifica al usuario? ¿Dónde vive el estado si una ejecución se interrumpe? ¿Quién decide si una acción está autorizada? ¿Qué componente ejecuta realmente una herramienta? ¿Dónde se comprueba que el efecto ocurrió? ¿Qué sucede si una API responde con un timeout después de haber realizado la operación?
Esas preguntas son arquitectura porque obligan a repartir responsabilidades.
OpenAI puede describir los fundamentos de un agente mediante modelo, instrucciones y herramientas. Microsoft puede mostrar cliente, orquestador, modelo, almacenamiento, catálogo, tool calling, APIs e índices. Google separa además framework, herramientas, memoria, patrones, agent runtime, modelos y model runtime.
Esas descripciones no se contradicen necesariamente. Observan el sistema desde niveles diferentes.
Para este artículo utilizaremos una definición operativa:
La arquitectura de un agente es el mapa de componentes, responsabilidades, interfaces y límites que permiten convertir una entrada en decisiones y, cuando corresponde, en efectos verificables sobre sistemas reales.
La arquitectura no es el framework. Un mismo patrón puede implementarse con tecnologías distintas. Tampoco es únicamente el modelo: cambiarlo puede alterar calidad, coste o latencia sin modificar las fronteras principales del sistema.
El modelo es una pieza, no el sistema
Un modelo puede interpretar una solicitud, clasificarla, generar texto, elegir entre herramientas permitidas o proponer el siguiente paso.
Pero alrededor de esa decisión suele existir software que prepara contexto, mantiene estado, controla permisos, ejecuta funciones y registra lo ocurrido.
Ejemplo orientativo — no es un caso de cliente.
Un usuario solicita:
Quiero cambiar la dirección de entrega de mi pedido.
El modelo puede interpretar la intención y proponer una llamada como:
update_shipping_address(order_id, address)
Eso todavía no significa que la dirección deba cambiarse. El sistema puede necesitar comprobar identidad, ownership del pedido, estado actual, formato de dirección, operaciones previas y si la acción necesita aprobación.
Solo entonces un componente ejecutor puede realizar la operación contra el sistema de pedidos. Y después todavía falta comprobar el resultado.
El modelo propone dentro de un espacio de posibilidades. La arquitectura define qué parte de ese espacio es realmente ejecutable.
Esta separación es fundamental porque las instrucciones del prompt no deberían sustituir autenticación, autorización, límites o reglas cuya violación tenga consecuencias reales.
Arquitectura y ciclo de ejecución no son lo mismo
La arquitectura describe un mapa relativamente estable de responsabilidades. Puede contener interfaz, identidad, orquestador, modelo, estado, herramientas, policy, executor y capas de recuperación u observabilidad.
El ciclo de ejecución, en cambio, describe qué ocurre en el tiempo durante una tarea concreta.
Una ejecución puede seguir un recorrido como:
objetivo → contexto → decidir → validar → ejecutar → observar → actualizar estado → continuar / parar
La misma arquitectura puede soportar recorridos distintos. Una tarea puede responder sin herramientas. Otra puede necesitar tres consultas y una aprobación. Otra puede detenerse porque falta evidencia. Otra puede reanudarse horas después.
Por eso anatomía no equivale a secuencia.
Arquitectura y ejecución responden preguntas distintas
La arquitectura muestra responsabilidades relativamente estables. La ejecución muestra cómo esas responsabilidades participan en una tarea concreta a lo largo del tiempo.
Equivalente textual del diagrama
Arquitectura: interfaz, identidad, orquestador, modelo, estado, herramientas, policy y executor.
Ejecución: objetivo → contexto → decidir → validar → ejecutar → observar → actualizar → continuar o parar.
Una arquitectura de referencia
No existe una arquitectura universal, pero podemos construir una referencia que ayude a hacer las preguntas correctas.
1. Interfaz o evento de entrada
La ejecución puede comenzar desde una interfaz web, chat, email, API, webhook, documento, cola o tarea programada. Un agente no necesita una interfaz conversacional.
2. Identidad y validación de entrada
Antes de decidir qué hacer conviene saber quién inicia la operación, qué cuenta representa y qué recursos puede consultar. Aquí también pueden validarse formato, tamaño o condiciones mínimas de una petición.
3. Orquestador o harness
Mantiene el loop: construye contexto, llama al modelo, procesa tool calls, mantiene estado, gestiona límites, reintentos, aprobaciones y condiciones de salida.
4. Modelo e instrucciones
El modelo produce una respuesta, clasificación, decisión, parámetros de una herramienta o propuesta de siguiente paso. Las instrucciones orientan su comportamiento, pero no deberían ser la única barrera para acciones sensibles.
5. Contexto, estado, memoria y conocimiento
El sistema decide qué información entra en cada inferencia, qué estado operativo debe persistir y qué memoria o evidencia externa necesita recuperar.
6. Herramientas, policy y executor
El modelo puede solicitar una capacidad; policy decide si está permitida y el executor realiza la operación real contra una API, base de datos o entorno.
7. Observabilidad y evaluación
Las trazas deben permitir reconstruir eventos, cambios de estado, herramientas, errores, aprobaciones y outcome.
No todas estas capas necesitan ser servicios separados. Una aplicación pequeña puede agrupar varias responsabilidades en el mismo proceso.
La arquitectura sirve para hacer explícitas las responsabilidades, no para multiplicar cajas.
Una arquitectura de referencia por responsabilidades
El modelo participa en la decisión, pero identidad, permisos, ejecución, estado y observabilidad siguen perteneciendo al sistema que lo rodea.
Equivalente textual del diagrama
- INPUT
- IDENTIDAD
- ORQUESTADOR
- MODELO + CONTEXTO
- TOOL REQUEST
- POLICY
- EXECUTOR
- SISTEMA DE VERDAD
Capas laterales: estado, memoria y RAG; tracing, evals y audit.
Orquestador: dónde vive el control del proceso
El orquestador es una de las piezas más importantes y también una de las más ambiguas.
En un workflow clásico, el código puede determinar exactamente qué ocurre después de cada paso. En un agente, el modelo puede tener margen para decidir si necesita una herramienta, qué herramienta utilizar o si debe pedir más información.
Entre ambos extremos hay muchas arquitecturas híbridas.
Por ejemplo:
- El código valida identidad.
- El modelo clasifica la solicitud.
- El código selecciona el workflow permitido.
- El modelo interpreta un documento dentro de ese workflow.
- Una regla exige aprobación para una acción sensible.
- El executor realiza la operación y registra el outcome.
No necesitamos elegir entre «todo determinista» y «todo agéntico».
Como vimos en agente de IA vs automatización, muchas arquitecturas útiles reservan la flexibilidad para los puntos donde aporta valor y mantienen el resto explícito.
El orquestador puede ser determinista, dirigido en mayor medida por el modelo o híbrido. La pregunta no es cuál parece más avanzado, sino cuál ofrece suficiente flexibilidad sin perder control innecesariamente.
Context assembly: qué sabe el modelo en cada decisión
El modelo no trabaja con todo lo que existe en la empresa. Trabaja con lo que está disponible en su contexto en ese momento.
Por eso conviene separar tres conceptos:
Almacenamiento: dónde existe la información.
Recuperación: cómo encontramos la información pertinente.
Contexto: qué información entregamos al modelo ahora.
El contexto de una decisión concreta puede contener únicamente identidad, estado actual, instrucciones, evidencia recuperada y el resultado de la herramienta anterior.
Anthropic describe el contexto como un recurso finito que debe gestionarse deliberadamente. Esto explica por qué memoria, retrieval, compaction y subagentes son técnicas de selección, no una invitación a introducir todo el historial disponible.
Un contexto demasiado pobre produce decisiones sin evidencia suficiente. Uno demasiado grande puede introducir ruido, datos obsoletos o información que el agente no necesitaba ver.
El almacenamiento conserva, la recuperación encuentra y el contexto decide qué entra ahora.
Estado, memoria y conocimiento: tres responsabilidades distintas
Paso actual, approval pendiente, operation ID, retries y progreso durable.
Preferencias, episodios o información seleccionada para reutilizarse más adelante.
Políticas, documentación o conocimiento externo recuperado para la tarea actual.
Estas capas pueden utilizar almacenamientos parecidos, pero no tienen la misma función.
El estado permite reanudar una ejecución, evitar duplicados o saber dónde se encuentra un proceso. La memoria en agentes de IA conserva información seleccionada para futuras tareas. RAG recupera evidencia desde fuentes externas y la añade al contexto cuando hace falta.
En qué es RAG en IA explicamos por qué retrieval no significa que el modelo haya aprendido esa información.
Una ejecución no debería depender de una «memoria» informal para saber si una transacción se completó. Ese dato pertenece al estado o al sistema de verdad.
Herramientas y executor: solicitar no es ejecutar
Una herramienta expone una capacidad que el modelo puede solicitar.
Pero, como desarrollamos en Tool calling: cómo utilizan herramientas los agentes de IA, una solicitud del modelo no debería confundirse con la ejecución real.
modelo → tool call → validación → policy → executor → API / sistema → resultado → modelo
En la frontera del executor pueden existir credenciales, timeouts, claves de idempotencia, transacciones, retry policy y registro del efecto.
El modelo puede solicitar «actualiza la dirección del pedido 123». El executor traduce una solicitud autorizada en una operación concreta contra el sistema real.
Por eso el executor puede considerarse una frontera de confianza.
Identidad, permisos y policy
Antes de permitir una acción conviene responder una pregunta básica:
¿En nombre de quién está actuando el agente?
No es lo mismo un agente que responde a un usuario autenticado que un proceso autónomo nocturno con identidad de servicio.
Microsoft está formalizando esta diferencia mediante identidades de agente y distingue escenarios autónomos de otros donde el agente actúa en contexto delegado de un usuario. Más allá del producto concreto, la pregunta arquitectónica es general.
Una arquitectura puede aplicar mínimo privilegio, credenciales acotadas, permisos por usuario o tenant, scopes por herramienta, revocación y auditoría. En autonomía en agentes de IA desarrollamos cómo convertir esos límites en políticas por acción, presupuestos y mecanismos de parada.
Las instrucciones del modelo pueden decir «no modifiques pedidos de otros usuarios», pero esa regla debería reforzarse con controles que el modelo no pueda reinterpretar.
Cuando una acción necesita juicio humano, la policy puede conducir a un gate de human-in-the-loop antes del executor.
Source of truth: qué datos no deberían vivir en el modelo
No toda información que el agente utiliza debería almacenarse como memoria o incorporarse a una base RAG.
Algunos datos tienen un sistema autoritativo que debería seguir siendo la fuente de verdad: saldo actual, estado de pedido, permisos, disponibilidad, estado de una transacción o versión vigente de un registro operativo.
Si existe una API o base de datos responsable de ese dato, recordar una copia puede introducir desactualización.
Una memoria puede conservar que un usuario prefiere recibir facturas en PDF. Pero si el agente necesita saber si la factura 938 está pagada, debería consultar el sistema financiero cuando esa es la fuente autoritativa.
RAG puede recuperar documentación útil, pero no sustituye necesariamente el estado transaccional actual.
Recordar no sustituye consultar la realidad.
Runtime y entorno: dónde trabaja realmente el agente
Otro elemento que suele desaparecer en los diagramas simplificados es el entorno de ejecución.
OpenAI separa actualmente el harness de ejecución, el environment y el application server. Google distingue agent runtime de model runtime. La idea general es importante aunque no utilicemos esas plataformas.
Un agente puede necesitar un entorno para crear archivos, ejecutar comandos, procesar documentos, utilizar dependencias, realizar cálculos, acceder a red o conservar artefactos temporales.
Ese entorno puede ser la propia aplicación, un worker, un contenedor, un sandbox o infraestructura gestionada por un proveedor.
No todos los agentes necesitan sandbox. Si el agente solo consulta una API y prepara una respuesta, puede no necesitar filesystem ni ejecución de código.
La pregunta no es «¿qué sandbox utilizamos?», sino qué recursos necesita realmente la tarea y cómo los limitamos.
Qué debería ser probabilístico y qué debería ser determinista
Esta es una de las decisiones centrales de arquitectura.
Los modelos son útiles cuando el sistema necesita interpretación flexible: comprender lenguaje, clasificar casos ambiguos, formular búsquedas, sintetizar evidencia, seleccionar entre herramientas permitidas o proponer un siguiente paso.
En cambio, autenticación, autorización, límites duros, integridad transaccional, idempotencia, estado durable, secretos y auditoría suelen beneficiarse de controles explícitos.
No es una frontera matemática. Puede haber verificadores basados en modelos y reglas dependientes del contexto.
El principio es no delegar a una salida probabilística aquello cuya corrección necesita una garantía operacional que puede imponerse mediante software.
El modelo puede interpretar si una solicitud parece una devolución; una regla puede comprobar que el importe no supera el máximo autorizado. El modelo puede seleccionar un documento; el sistema puede impedir que recupere documentos de otra cuenta.
Criterio probabilístico dentro de límites deterministas
La arquitectura decide qué responsabilidades pueden beneficiarse del juicio del modelo y cuáles necesitan controles que no dependan de una salida probabilística.
Equivalente textual del diagrama
Modelo: interpretar, clasificar, sintetizar, formular búsquedas, elegir entre acciones permitidas.
Sistema: autenticar, autorizar, aplicar límites, mantener estado, ejecutar transacciones y auditar.
La arquitectura también describe cómo falla
Un diagrama que solo representa input → modelo → tool → éxito no es suficiente para un sistema que deba operar de forma fiable.
Consideremos una llamada que devuelve timeout. El sistema puede comprobar si la operación se ejecutó aunque la respuesta se perdiera, reintentar si es seguro, utilizar otra ruta, esperar y reanudar, escalar o detenerse.
La decisión depende del tipo de herramienta y del posible side effect.
Otros fallos que necesitan una respuesta arquitectónica incluyen argumentos inválidos, autenticación caducada, permiso insuficiente, fuente no disponible, evidencia contradictoria, aprobación rechazada, usuario que no responde, máximo de pasos, crash o ejecución parcial.
En algunos casos el modelo puede participar en la recuperación. En otros, el comportamiento debe estar fijado por reglas.
Después de una operación financiera ambigua, por ejemplo, quizá no queramos que el modelo decida libremente «voy a intentarlo otra vez». Necesitamos estrategia de estado e idempotencia.
Si el diagrama solo explica cómo funciona cuando todo sale bien, todavía no describe una arquitectura de producción.
Observabilidad y evaluación forman parte de la arquitectura
Si una ejecución falla y no podemos reconstruir lo que ocurrió, será difícil mejorar el sistema.
La observabilidad debería permitir seguir entrada e identidad, referencias recuperadas, tools solicitadas, argumentos, resultados, transiciones de estado, aprobaciones, errores, outcome, latencia y coste.
No necesitamos registrar razonamiento privado interno del modelo para tener trazas operativas útiles. Necesitamos evidencias de lo que el sistema recibió, solicitó, ejecutó y produjo.
Esto conecta directamente con cómo evaluar un agente de IA: una suite de evals necesita outcomes y trazas observables para comprobar resultados, trayectoria y controles.
Por eso evaluación y tracing no deberían añadirse únicamente después del despliegue. La arquitectura debe hacer posible medir el comportamiento desde el principio.
Qué componentes no necesita todo agente
Uno de los riesgos al estudiar arquitecturas es convertir los diagramas de referencia en checklists obligatorios.
Memoria persistente
Si cada tarea es independiente, quizá no haya nada que merezca recordarse entre sesiones.
RAG
Si la información ya viene en la petición o se consulta directamente mediante una API, puede no ser necesario construir retrieval documental.
Planner dedicado
El modelo puede decidir el siguiente paso localmente sin un componente separado llamado «planner».
Sistema multiagente
Como vimos en sistemas multiagente, otro agente necesita una frontera que justifique su existencia.
Interfaz de chat
La ejecución puede ser activada por eventos, APIs o procesos programados.
Sandbox
Si no existe ejecución de código, filesystem o navegación que deba aislarse, quizá no aporte nada.
El objetivo no es reunir todas las capacidades posibles. Es construir la arquitectura mínima que permita hacer el trabajo con el nivel de flexibilidad y control requerido.
No diseñes por checklist. Diseña por necesidad del proceso.
Framework para diseñar la arquitectura de un agente
Antes de elegir framework, modelo o proveedor, conviene responder estas preguntas.
¿Qué resultado debe producir el sistema?
Define un outcome observable. «Ayudar al usuario» no basta si no sabemos cuándo la tarea está realmente terminada.
¿Qué parte necesita criterio dinámico?
Localiza los puntos donde las reglas no describen razonablemente todas las rutas válidas.
¿Qué parte puede seguir siendo determinista?
Mantén explícitas las rutas estables, validaciones e invariantes que no necesitan decisión del modelo.
¿Cuál es la fuente de verdad?
Para cada dato crítico identifica qué sistema tiene autoridad sobre su estado actual.
¿Qué contexto necesita cada decisión?
Selecciona instrucciones, estado, evidencia y observaciones sin introducir información innecesaria o no autorizada.
¿Qué estado debe persistir?
Define qué necesita la ejecución para reanudarse, evitar duplicados y conocer el progreso real.
¿Necesitamos memoria?
Pregunta qué información merece reutilizarse en futuras sesiones y durante cuánto tiempo seguirá siendo válida.
¿Necesitamos retrieval o RAG?
Añádelo cuando el sistema necesite recuperar evidencia de forma selectiva, no como componente automático.
¿Qué herramientas necesita?
Expón capacidades concretas y mínimas, no toda la API subyacente.
¿Quién ejecuta esas herramientas?
Define executor, credenciales, timeouts, retries, idempotencia y cómo vuelve el resultado.
¿En nombre de quién actúa?
Usuario, organización o identidad propia del agente condicionan permisos, scope y auditoría.
¿Qué permisos y límites se aplican?
Separa policy de instructions: los límites críticos deben imponerse aunque el modelo proponga otra cosa.
¿Qué acciones necesitan una persona?
Identifica approvals, handoffs y excepciones antes de que una acción sensible produzca un efecto.
¿Qué ocurre si algo falla o la ejecución se reinicia?
Diseña timeout, retry, resume, stop, rollback cuando exista y escalado.
¿Qué evidencia demuestra que funciona?
Define trazas, outcomes, métricas y evals antes de depender del sistema en producción.
La salida de este análisis no debería ser una lista de tecnologías. Debería ser una distribución explícita de responsabilidades: qué decide el modelo, qué controla el software, qué datos son autoritativos y qué ocurre antes de producir un efecto.
Preguntas frecuentes
¿Cuáles son los componentes de un agente de IA?
Depende del sistema. Una arquitectura puede incluir modelo, instrucciones, orquestador, contexto, estado, memoria, RAG, tools, executor, identidad, policy, supervisión humana, runtime, observabilidad y evaluación. No todos son obligatorios ni tienen que ser servicios separados.
¿El LLM es el agente?
No necesariamente. El modelo es el componente de inferencia. El agente suele incluir además software que prepara contexto, mantiene estado, gestiona herramientas, aplica límites y procesa resultados.
¿Todo agente necesita memoria?
No. Si las tareas son independientes o no existe información que deba reutilizarse posteriormente, una arquitectura sin memoria persistente puede ser suficiente.
¿Qué hace un orquestador?
Gestiona el ciclo de ejecución: prepara contexto, llama al modelo, procesa tool calls, mantiene estado, aplica reglas de flujo, gestiona errores y decide cuándo continuar, detener o escalar.
¿Qué diferencia hay entre estado y memoria?
El estado representa dónde se encuentra una ejecución o proceso. La memoria conserva información seleccionada para reutilizarla más adelante. Una aprobación pendiente es estado; una preferencia duradera puede ser memoria.
¿Qué es el runtime de un agente?
Es el entorno operativo donde se ejecuta la lógica del agente y se gestionan tareas, sesiones, herramientas u otros recursos. Puede incluir workers, sandboxes, almacenamiento temporal, filesystem o acceso de red según la necesidad.
¿Dónde deben vivir permisos y guardrails?
Las instrucciones pueden orientar al modelo, pero los permisos críticos deberían aplicarse mediante controles de aplicación, identity providers, policy, scopes y validadores que no dependan únicamente de que el modelo obedezca un prompt.
¿Cómo sé si una arquitectura es demasiado compleja?
Si no puedes explicar qué requisito justifica una capa, un agente, una memoria o un servicio adicional, conviene cuestionarlo. La complejidad debería resolver una necesidad observable de capacidad, control, aislamiento, fiabilidad u operación.
Fuentes y lecturas recomendadas
Estas fuentes sostienen la separación entre modelo, orquestación, runtime, identidad, herramientas, contexto y observabilidad, además del criterio de mantener controles explícitos alrededor de decisiones probabilísticas.
- 01Microsoft — Components of an agent architecture (enlace externo)learn.microsoft.com
Describe cliente, orquestación, modelo, tool calling, APIs, índices y otras capas habituales en arquitecturas de agentes.
- 02Microsoft — Architecting agent solutions (enlace externo)learn.microsoft.com
Marco de arquitectura centrado en adecuación, confianza, trazabilidad y transparencia.
- 03Microsoft — Secure agents (enlace externo)learn.microsoft.com
Recomendaciones sobre identidad, mínimo privilegio, ownership, monitorización y revocación.
- 04Google Cloud — Choose agentic AI architecture components (enlace externo)cloud.google.com
Separa frontend, framework, herramientas, memoria, patrones, agent runtime, modelos y model runtime.
- 05OpenAI — Agents API overview (enlace externo)developers.openai.com
Distingue agent, environment, session y eventos como conceptos operativos.
- 06OpenAI — Agents API architecture (enlace externo)developers.openai.com
Describe harness de ejecución, environment y application server como responsabilidades separadas.
- 07OpenAI — A practical guide to building agents (enlace externo)openai.com
Presenta modelo, tools e instrucciones como fundamentos y desarrolla orquestación, guardrails e intervención humana.
- 08Anthropic — Building Effective Agents (enlace externo)anthropic.com
Distingue workflows y agents y recomienda aumentar complejidad únicamente cuando aporta valor.
- 09Anthropic — Effective context engineering for AI agents (enlace externo)anthropic.com
Explica cómo contexto, memoria, retrieval, compaction y subagentes pueden combinarse en tareas largas.
- 10Anthropic — Demystifying evals for AI agents (enlace externo)anthropic.com
Marco de tareas, trazas, outcomes y graders para evaluar sistemas agénticos.
Sobre el autor
Elvis Mendoza, fundador de Agentes Como Servicio. Trabaja en el diseño de producto, la arquitectura de soluciones, el diseño de agentes y flujos de trabajo y la construcción de software asistida por IA para conectar procesos, datos, herramientas y supervisión humana alrededor de necesidades empresariales concretas.
¿Qué parte de tu proceso debe decidir la IA y qué parte debería seguir controlando el sistema?
Antes de elegir un framework o modelo, conviene separar decisiones, fuentes de verdad, herramientas, permisos, estado y puntos de supervisión.
En Agentes Como Servicio diseñamos la arquitectura desde esas responsabilidades: introducimos criterio dinámico donde aporta valor y mantenemos controles explícitos allí donde el proceso necesita límites verificables.
Solicitar acceso