Arquitectura y organización de los agentes de IA

En el artículo anterior cerramos con una pregunta: ¿qué parte del trabajo queremos que la IA entienda, prepare y ejecute con seguridad?

Para responder a esta pregunta, hace falta bajar un escalón. Porque entre un agente que sorprende en una demo y otro que sostiene operación real no hay un modelo más listo: hay una arquitectura.

Cuando construimos Forge entendimos que un agente serio se decide en cinco preguntas, no en una: cómo se organiza, dónde vive, qué modelos usa, qué recuerda y 1cómo se coordina con otros. Este artículo recorre esas cinco decisiones.

1. Arquitectura

Un agente de IA no es un modelo de lenguaje. Es un sistema construido alrededor de un modelo de lenguaje. La diferencia con un modelo de lenguaje grande (LLM) puro es estructural: el agente no se limita a responder, decide, planifica, actúa y aprende a lo largo de un proceso iterativo.

A nivel arquitectónico, casi cualquier agente serio se organiza en seis capas: un núcleo LLM, una capa de herramientas (tool calling), una capa de memoria y aprendizaje, una capa de razonamiento que aplica paradigmas como ReAct (reasoning and acting) o ReWOO (reasoning without observation), una capa de orquestación multi-agente y, envolviéndolo todo, una capa de gobierno y observabilidad.

El ciclo operativo del agente recorre tres etapas: inicialización y planificación (el usuario define un objetivo y un conjunto de herramientas, el agente descompone la tarea), razonamiento con herramientas (el agente identifica qué información le falta, recurre a APIs o a otros agentes, reevalúa su plan) y aprendizaje y reflexión (el agente integra feedback humano o automático y persiste lo aprendido).

La elección del paradigma de razonamiento es la primera decisión arquitectónica de fondo. ReAct intercala pensamiento y la acción en bucles cortos, ideal para entornos exploratorios. ReWOO planifica todo de antemano y separa la planificación de la ejecución, lo que permite revisar el plan antes de ejecutarlo. Este último enfoque es el que adoptan agentes en producción como Forge sobre GitLab, que genera primero un TECH_SPEC revisable por el equipo y solo después ejecuta el plan.

La arquitectura no es el modelo. Es todo lo que lo rodea.

2. Infraestructura

Un agente necesita infraestructura para tres cosas: ejecutar el modelo, ejecutar las herramientas y persistir el estado. La elección de cada una determina coste, latencia y riesgo.

• Ejecución del modelo: modelo gestionado por proveedores como Anthropic, OpenAI, Google o Azure, con pago por token y baja latencia, o modelos locales como Ollama, vLLM o despliegues propios, con coste fijo y control total. Cada vez más sistemas combinan ambos, reservando lo local para soberanía de datos u operación offline.

• Ejecución de herramientas: cuando un agente genera código o ejecuta acciones con efectos secundarios, hay que aislarlo. El patrón habitual es un contenedor con reglas estrictas, sin acceso a red durante la validación y verificación criptográfica de los webhooks que disparan al agente.

• Persistencia: historial de conversación, artefactos generados y base de conocimiento. La recomendación práctica es no inventar infraestructura que la plataforma ya provee. Si el agente vive sobre GitLab, GitHub o Jira, sus primitivas (issues, branches, comentarios) ya son una capa válida de mensajería y persistencia.

Esta última decisión es decisiva en términos de coste y mantenimiento: cada componente que se construye en lugar de reutilizar es código que hay que operar.

No inventes lo que la plataforma ya te da.

3. Modelos

El LLM es el motor cognitivo del agente, pero la decisión real no es qué modelo usar, sino cómo combinarlos. Hay tres estrategias habituales:

• Modelo único: todo el flujo depende  del mismo LLM. Es la opción más simple, perfecta para prototipos. El riesgo es que el modelo se convierte en un único punto de fallo y de coste.

• Especialización por tarea: distintos modelos para distintas fases del agente. Un modelo potente para razonamiento complejo (planificación), un modelo para la generación de código, un modelo local pequeño para inferencia offline y otro como respaldo. Reduce coste y mejora la calidad punto a punto.

• Diversidad como salvaguarda: en sistemas críticos, depender de un solo proveedor puede crear un punto único de fallo. Distribuir los nodos críticos entre modelos o proveedores diferentes reduce el riesgo operativo. Si todos los agentes usan el mismo modelo fundacional y ese modelo cae, alucina o sufre un ataque, todo el sistema cae a la vez. Esta estrategia se apoya en un patrón complementario: el failover automático, donde el sistema detecta cuando un proveedor está caído y enruta a otro. Es el equivalente a un balanceador, pero entre LLMs.

A la hora de elegir, conviene mirar cuatro ejes:

• Calidad: si la tarea exige razonamiento profundo.

• Coste: por número de llamadas y tamaño del contexto.

• Latencia: si el usuario espera una respuesta inmediata.

• Soberanía: si los datos pueden salir o no de la infraestructura.

No existe un modelo mejor en abstracto. Existe el modelo correcto para cada nodo del agente.

4. Memoria

Sin contexto, un agente responde de forma genérica. Sin memoria, cada interacción empieza de cero. La memoria es lo que permite que el agente aprenda, se adapte y no repita errores. En la práctica conviven cuatro tipos:

• Memoria de contexto (corto plazo): la conversación actual, lo que está en la ventana del LLM. Limitada por el tamaño de contexto del modelo. Se gestiona resumiendo, truncando o estructurando la solicitud de entrada.

• Memoria episódica: registro de interacciones pasadas, organizadas como eventos. Útil para «la última vez que pasó esto, hicimos esto otro». Se almacena en bases relacionales o documentales.

• Memoria semántica: conocimiento abstracto sobre el dominio. Patrones, reglas, hechos. Se materializa típicamente como una base vectorial consultable por similitud (RAG, Retrieval-Augmented Generation). Por ejemplo, algunos agentes de generación de código usan una base vectorial como ChromaDB para que el código producido siga los patrones del propio repositorio: no se entrena con el código del cliente, lo consulta en tiempo de ejecución.

• Memoria de procedimiento: cómo se hacen las cosas. Plantillas, planes, instrucciones o procedimientos estandarizados. Suele vivir como flujo declarativo (YAML, JSON) que el agente sigue paso a paso.

La memoria semántica es especialmente importante en agentes empresariales. Un agente de desarrollo puede recuperar patrones del repositorio para generar código alineado con la arquitectura existente. Un agente legal puede consultar cláusulas y versiones. Un agente de atención puede recuperar políticas y contexto del cliente.

Pero una memoria mal diseñada puede empeorar el sistema: más tokens, información irrelevante, sesgos antiguos o respuestas contaminadas. Por eso hacen falta criterios de actualización, caducidad, permisos, fragmentación, recuperación y evaluación.

La memoria es un activo y un pasivo a la vez. Hay que gobernarla.

5. Orquestación

Cuando el agente deja de resolver una única interacción uno y empieza a ejecutar procesos, aparece la orquestación.  Orquestación significa decidir qué ocurre primero, qué viene después, qué hacer si falla una herramienta, cuándo reintentar, cuándo escalar a una persona y cuando detener el proceso.

Hay tres patrones de habituales:

• Pipeline secuencial: un paso alimenta al siguiente. Simple, auditable y fácil de monitorizar. Es el patrón que adoptan, por ejemplo, sistemas donde un agente planificador genera una especificación, la commitea como artefacto y un segundo agente ejecutor la implementa.

• Coordinador central: un agente «director» reparte tareas entre agentes especialistas y recompone los resultados. Útil cuando la descomposición de la tarea no se conoce de antemano.

• Colaboración entre pares: varios agentes se comunican entre sí, debaten y convergen. Frameworks como AutoGen o crewAI lo facilitan. Más potencial, más coste, más riesgo de bucles.

Una novedad importante que se introdujo en el año 2025 es la consolidación de protocolos estándar entre agentes: MCP (Model Context Protocol) para conectar agentes con herramientas y datos, A2A (Agent2Agent) para comunicación directa entre agentes y ACP (Agent Communication Protocol) para interoperabilidad entre plataformas. Sin estos protocolos, cada integración era un puente a medida. Con ellos, los agentes empiezan a parecerse a microservicios con APIs estándar.

El riesgo principal de cualquier orquestación es perder control: bucles infinitos, herramientas llamadas de forma innecesaria, costes crecientes o acciones no deseadas. La mitigación pasa por límites de reintentos, condiciones de parada, aprobaciones humanas y trazabilidad por paso.

Autonomía no es ausencia de control. Es control bien delegado.

6. Framework, custom o plataforma

A la hora de construir un agente, la primera decisión arquitectónica es qué reutilizar y qué construir a medida Hay tres vías habituales:

Vía framework

Librerías como LangChain, LangGraph, AutoGen o crewAI aportan abstracciones listas para prompts, gestión de memoria, integración con herramientas y patrones multi-agente. Son útiles para validar rápido una hipótesis, construir MVPs o acelerar pruebas internas.

Vía custom

Construir el agente desde cero, sin framework. Implica más trabajo, pero ofrece más control sobre seguridad, rendimiento, trazabilidad, permisos, costes e integración con sistemas internos. Es una opción habitual cuando el agente ejecuta procesos core o datos sensibles.

Vía plataforma

En lugar de elegir entre framework y custom, apoyarse en una plataforma agentica gestionada, donde parte del runtime lo ofrece el proveedor: ejecución, herramientas, permisos, observabilidad o integración nativa con un ecosistema concreto.

La decisión no debería ser ideológica. No se trata de framework sí o no. Se trata de elegir el camino que cubra los requisitos reales del caso.

Conclusión

La arquitectura agéntica no es un patrón único. Es una familia de decisiones conectadas sobre infraestructura, modelos, memoria, orquestación, herramientas y gobierno.

Tres ideas resumen el enfoque:

• El agente vive en la arquitectura, no en el LLM. El modelo es solo el motor; la arquitectura está en herramientas, memoria, orquestación, observabilidad y sandbox.

• La diversidad reduce fragilidad. Diversidad de modelos, de herramientas, de fuentes de datos y mecanismos de validación.

• La trazabilidad debe crecer con la autonomía. Cuanta más autonomía se le da al agente, más explícita tiene que ser su trazabilidad: cada paso registrable, cada decisión auditable y cada interrupción posible.

Con la arquitectura definida aparece la siguiente capa del problema: la calidad del dato. Una arquitectura limpia no garantiza buenos resultados si el contexto que recupera el agente es incompleto, si la memoria contiene información desactualizada o si las fuentes no están bien gobernadas.

Y ahí empieza el próximo debate:

¿Cómo aseguramos que lo que el agente sabe, recuerda y consulta es realmente lo correcto?

De eso hablaremos en el siguiente artículo: calidad del dato, contexto y RAG.

By: Alvaro Díaz-Ligüeri Ascaso

---

¿Necesitas ayuda para implementar IA en tu empresa? puedes escribirnos a info@serquo.com