# Arquitectura de agentes de IA: las piezas del sistema y cómo encajan > La arquitectura de agentes de IA pieza a pieza: modelo, orquestación, herramientas, memoria, evaluación, observabilidad y controles humanos. - Canonical: https://arkatai.com/arquitectura-de-agentes-de-ia/ - Site: Arkatai (https://arkatai.com) — agentic operations as a service - Language: es - Published: 2026-07-19 --- Cuando un directivo me pide que le explique la arquitectura de un agente de IA, empiezo por lo que no es: no es un modelo de lenguaje con un buen prompt. Un agente que ejecuta trabajo real es un sistema con varias piezas, cada una con una función distinta y un dueño distinto de su mantenimiento. El modelo razona y decide, la orquestación reparte el trabajo y ordena los pasos, las herramientas conectan con tus sistemas. La memoria y la recuperación aportan el contexto, las evaluaciones miden si lo hace bien, la observabilidad deja rastro de qué hizo y los controles humanos marcan hasta dónde puede llegar solo. Falla una y el sistema entero deja de merecer tu confianza. Esta página es el índice del cluster técnico: presento cada pieza en dos párrafos y enlazo al artículo que la desarrolla, para que un evaluador entienda el conjunto antes de bajar al detalle. El orden sigue más o menos el camino que recorre un caso desde que entra hasta que se cierra. ## El modelo: la pieza que se trata como utility El modelo de lenguaje es el motor de razonamiento: interpreta el caso, decide el siguiente paso y redacta el resultado. Es también la pieza más fácil de sustituir, y ese es justo el punto de diseño más importante. Los modelos de los distintos proveedores —los de Anthropic, OpenAI o Google como categoría— mejoran a un ritmo que ninguna empresa cliente puede seguir, y cambian de precio y de capacidad cada pocos meses. Una arquitectura sensata trata el modelo como utility: se selecciona por tarea según calidad, coste, latencia y riesgo, y se puede reemplazar sin rehacer el proceso. Eso obliga a una decisión doble. Por un lado, qué modelo asignas a cada tarea del flujo, porque no todas necesitan el más caro: extraer un dato de una factura y redactar una respuesta delicada a un cliente no piden lo mismo. Ese criterio lo desarrollo en [qué modelo de IA elegir](/que-modelo-de-ia-elegir/). Por otro, qué opciones tienes disponibles y cómo se comparan para uso empresarial, que es el mapa que dibujo en [LLM para empresas](/llm-para-empresas/). ## La orquestación: quién hace qué y en qué orden Un caso real rara vez se resuelve en un solo paso. Hay que leer una entrada, consultar dos sistemas, aplicar una regla, quizá pedir trabajo a otro agente especializado y consolidar el resultado. Orquestar es coordinar todo eso: repartir el trabajo entre agentes y herramientas, ordenar los pasos, gestionar los fallos y reintentos, y decidir cuándo interviene una persona. Sin orquestación tienes un modelo que responde. Con ella tienes un sistema que trabaja. La orquestación es una pieza lo bastante grande como para tener su propio artículo: qué significa exactamente y cómo se piensa está en [orquestación de agentes](/orquestacion-de-agentes/). Y como hay formas conocidas de estructurarla según el problema —pasos en cadena, trabajo en paralelo, un supervisor que reparte, un verificador que revisa—, he catalogado esas formas con su cuándo y su riesgo en [patrones de orquestación de agentes](/patrones-de-orquestacion-de-agentes/). ## Las herramientas e integraciones: cómo toca tus sistemas Un agente que solo conversa no sirve en operaciones. El valor aparece cuando actúa: consulta el ERP, escribe en el CRM, lee un correo, genera un asiento. Eso se hace a través de herramientas, que son las funciones concretas que el agente puede invocar, cada una con permisos explícitos de qué puede leer y qué puede escribir. La calidad de esta capa determina el techo del sistema, porque un agente es tan capaz como las acciones que le has dado y tan seguro como los límites de esas acciones. El problema clásico es que cada integración se construía a medida, una por una. La estandarización de esta capa mediante un protocolo común para conectar agentes con herramientas y fuentes de datos reduce ese coste y hace las integraciones portables entre modelos. Lo explico sin jerga en [MCP, el Model Context Protocol](/mcp-model-context-protocol/). ## La memoria y el conocimiento: de dónde saca el contexto El modelo por sí solo no conoce tu empresa ni recuerda lo que pasó hace dos pasos. La arquitectura resuelve esto con dos mecanismos distintos que conviene no confundir. La memoria y el contexto gestionan lo que el agente arrastra dentro de una tarea y entre tareas: el estado del caso, lo decidido hasta ahora, lo aprendido de interacciones anteriores. Ese mecanismo, y por qué la ventana de contexto no es memoria de verdad, lo trato en [memoria y contexto en agentes](/memoria-y-contexto-en-agentes/). El conocimiento de tu empresa es otra cosa: tus documentos, políticas, catálogos y datos, que el agente necesita consultar sin que quepan en el prompt. La técnica para eso es la recuperación: buscar el fragmento relevante en tu base documental y dárselo al modelo en el momento de decidir. Aplicada a datos empresariales, con sus problemas de permisos y frescura, es lo que cubro en [RAG empresarial](/rag-empresarial/). ## Las evaluaciones: cómo sabes que funciona Esta es la pieza que más gente se salta y la que separa una demo de un sistema en producción. Evaluar un agente es medir su calidad con casos de prueba de respuesta conocida, umbrales que definen "suficientemente bueno" y una revisión sistemática de los fallos. Sin evaluaciones no tienes forma seria de decir que el agente funciona. Tienes una impresión, y las impresiones no aguantan un comité. Las evaluaciones no son un examen único de arranque: se vuelven a pasar cada vez que cambia el modelo, el prompt o el proceso, porque cualquiera de esos cambios puede degradar algo que antes funcionaba. Cómo se montan, qué se mide y con qué umbrales es el contenido de [evaluación de agentes de IA](/evaluacion-de-agentes-de-ia/). Es también la pieza que da al comité la evidencia para relajar la supervisión humana sin apostar a ciegas. ## La observabilidad y las trazas: qué hizo y por qué Cuando un agente decide algo en producción, alguien va a preguntar por qué. La observabilidad es la capa que responde: registra qué recibió el agente, qué pasos dio, qué herramientas invocó, qué regla aplicó y qué resultado produjo. Es la diferencia entre "el sistema se equivocó" y "el sistema aplicó esta regla con estos datos y produjo este resultado, aquí está la traza". Sin ella no hay depuración posible ni auditoría defendible. Esta capa no es opcional en una operación seria: es lo que permite mejorar el sistema con evidencia en lugar de con opiniones, y lo que un auditor exigirá. La trato en detalle en [observabilidad y trazabilidad de agentes](/observabilidad-y-trazabilidad-de-agentes/). Se conecta con las evaluaciones —las trazas alimentan los casos de prueba— y con la gobernanza, que es donde estas evidencias adquieren consecuencias. ## Los controles humanos: hasta dónde llega solo Ningún agente serio opera sin límites. La arquitectura define en qué puntos una persona revisa, aprueba o toma la decisión, y qué casos escalan automáticamente por exceder el mandato del agente. Dónde se ponen esos puntos de control es una decisión de negocio, no técnica. Gobierna el riesgo real del sistema y se mueve con el tiempo, apretando donde los datos muestran fallos y relajando donde muestran fiabilidad. Hay una distinción que conviene tener clara desde el diseño: si la persona está dentro del bucle aprobando antes de cada acción sensible, o supervisando sobre el bucle y pudiendo intervenir. Ambas son legítimas según el riesgo del caso, y las separo en [human in the loop](/human-in-the-loop/). Es la pieza que convierte un sistema potente en un sistema que un comité puede aprobar. ## Dónde corre y cómo se construye Dos decisiones estructurales atraviesan toda la arquitectura. La primera es dónde se ejecuta: en la nube o dentro de tu perímetro. Afecta a coste, control, latencia y a qué exige tu regulación sobre dónde viven tus datos. El criterio para decidirlo, sin dogmas, está en [agentes on-premise o en la nube](/agentes-on-premise-o-en-la-nube/). La segunda es cómo se construye: con herramientas visuales de automatización o con agentes hechos a medida sobre tus reglas. Cada camino tiene un techo distinto, y confundirlos es una fuente frecuente de pilotos que no escalan. La comparación la desarrollo en [automatización no-code frente a agentes a medida](/n8n-vs-agentes-a-medida/). ## Cómo encajan las piezas La arquitectura no es la suma de estas piezas, sino cómo se conectan. El modelo decide con el contexto que le da la memoria y el conocimiento que le da la recuperación, y actúa a través de herramientas con permisos. La orquestación ordena todo eso y llama a una persona cuando toca, las evaluaciones dicen si el conjunto funciona y la observabilidad registra qué hizo. Quitar una pieza no deja el sistema más simple, lo deja roto de una manera que no verás hasta que un caso real lo revele. La parte que ninguna de estas piezas resuelve por sí sola es la específica de tu empresa: tus reglas, tus excepciones, tus permisos, tus integraciones. Esa definición es la que hay que codificar para que el sistema ejecute tu operación y no una genérica, un trabajo que argumento en [el modelo operativo como código](/modelo-operativo-como-codigo/). Y el marco que gobierna quién puede qué y con qué evidencia es la [gobernanza de agentes](/gobernanza-de-agentes/). Si quieres el nivel de arriba —qué son estos sistemas y cómo se adoptan antes de bajar a la arquitectura—, el punto de entrada es [agentes de IA para empresas](/agentes-de-ia-para-empresas/). ## Preguntas frecuentes ### ¿Qué componentes forman la arquitectura de un agente de IA? Un modelo de lenguaje que razona y decide, una capa de orquestación que ordena los pasos y reparte el trabajo, herramientas e integraciones para actuar sobre tus sistemas, memoria y recuperación para el contexto y el conocimiento, evaluaciones para medir la calidad, observabilidad para dejar traza y controles humanos para fijar los límites. Cada pieza cumple una función distinta y ninguna es prescindible en producción. ### ¿Se puede montar un agente solo con un buen modelo y un buen prompt? Para una demo, sí; para operar, no. Un modelo con prompt responde, pero no actúa sobre tus sistemas, no mide su propia calidad, no deja traza auditable y no tiene límites explícitos. Esas piezas son las que convierten un prototipo que impresiona en un salón en un sistema que un comité aprueba para producción. ### ¿Qué parte de la arquitectura hay que construir a medida? La infraestructura —modelo, orquestación, protocolos de integración, observabilidad— tiende a ser reutilizable y cada vez más estándar. Lo específico de tu empresa son las reglas, las excepciones, los permisos y las integraciones concretas: esa capa se codifica caso por caso porque describe cómo funciona tu operación, no una genérica. ### ¿Por dónde empieza un evaluador técnico que asesora a dirección? Por las tres piezas que más pilotos matan y menos se miran: evaluaciones, observabilidad y controles humanos. Si un proveedor no puede enseñarte cómo mide la calidad, cómo deja traza de cada decisión y dónde escala a una persona, el resto de la arquitectura da igual, porque no podrás defender el sistema ante tu comité ni ante un auditor.