Actualizado: 18 de mayo de 2026.
La arquitectura de agentes de IA es el diseño estructural que convierte un LLM en un sistema capaz de completar trabajo real — percibir entrada, razonar sobre ella, actuar en el mundo, aprender de los resultados y operar de forma segura. En 2026, los patrones se han asentado lo suficiente como para que podamos hablar de arquitectura de agentes como hablábamos de arquitectura web en 2008: hay convenciones que vale la pena conocer, y las desviaciones importan.
Esta guía cubre las seis capas que todo agente en producción tiene, las cinco arquitecturas canónicas y las preocupaciones operativas que la mayoría de los equipos descubre demasiado tarde.
Las Seis Capas de un Agente de IA
Todo agente en producción tiene estas seis capas — a veces colapsadas, a veces estrictamente separadas. Nombrarlas en voz alta es el primer paso para no construir un monolito enredado.
1. Percepción
Cómo recibe entrada el agente. Puede ser un mensaje de chat, un payload de webhook, la llegada de un email, un disparador programado, una mención de Slack o un evento de Kafka. La capa de percepción es el contrato: ¿qué forma de entrada se compromete a manejar el agente?
El error más común: difuminar el límite entre percepción y razonamiento. Mantén la percepción delgada — analiza, valida, enruta. Cualquier semántica ocurre en el razonamiento.
2. Razonamiento
La llamada al LLM (o secuencia de llamadas) que decide qué hacer. Esta es la capa de «pensamiento» del agente — el lugar donde ocurre la inferencia real del modelo, donde se seleccionan herramientas y donde se toma la decisión del siguiente paso.
Una capa de razonamiento limpia toma una decisión a la vez con entradas explícitas. Una capa de razonamiento desordenada entremezcla llamadas a herramientas, mutaciones de estado y efectos secundarios externos dentro del mismo prompt.
3. Planificación
Para tareas no triviales, los agentes necesitan descomponer. La capa de planificación toma un objetivo de alto nivel y lo divide en pasos. A veces la planificación es implícita en la capa de razonamiento (estilo ReAct — planifica un paso a la vez). A veces es explícita (Plan-Ejecutar — genera un plan completo, luego ejecuta).
Cuando la planificación es implícita, el agente puede adaptarse durante la tarea; cuando es explícita, es más fácil auditar y reanudar tras fallos.
4. Memoria
Lo que el agente recuerda. Tres niveles:
- Corto plazo: la conversación actual / ventana de contexto. Barato, rápido, efímero.
- Memoria de trabajo: recuperada durante la tarea mediante búsqueda vectorial, recuperación estructurada o llamada a herramienta. El patrón RAG vive aquí.
- Largo plazo: persiste entre ejecuciones, sesiones y usuarios. Datos de perfil, resultados previos, preferencias aprendidas.
La arquitectura de memoria es donde la mayoría de los sistemas de agentes se vuelven descuidados. El comportamiento por defecto — volcar todo al contexto — quema tokens y degrada el razonamiento. La política correcta depende del caso de uso, pero requiere decisiones explícitas, no valores por defecto.
5. Uso de Herramientas
Cómo actúa el agente en el mundo. Las herramientas son la capa de integración — APIs, bases de datos, productos SaaS, funciones personalizadas. La capa de uso de herramientas responde: ¿qué herramientas están registradas? ¿Quién puede llamarlas? ¿Con qué argumentos? ¿Cuál es la semántica de fallo?
En 2026, MCP (Model Context Protocol) se está convirtiendo en la interfaz universal de herramientas — los frameworks y plataformas consumen servidores MCP de forma nativa, haciendo que las definiciones de herramientas sean portátiles.
6. Supervisión (Oversight)
La capa que la mayoría de los equipos construye al final y lamenta no haber construido primero. Registros de auditoría de cada acción. Puertas de aprobación para decisiones de alto riesgo. Rutas de escalamiento a humanos. Infraestructura de replay para respuesta a incidentes.
Cuando algo sale mal (y a escala, algo saldrá), la capa de supervisión determina si puedes investigar, recuperar y prevenir la recurrencia — o si estás atascado explicándole a tu CTO por qué un agente autónomo hizo eso.
Las Cinco Arquitecturas Canónicas
1. ReAct (Razonar → Actuar → Observar)
El bucle de agente más simple. El LLM razona un paso a la vez, elige una herramienta, observa el resultado y vuelve a razonar. El bucle continúa hasta que el agente decide que ha terminado.
Fortalezas: Conceptualente limpio. Fácil de depurar paso a paso. Maneja bien situaciones dinámicas — el agente se adapta en cada iteración.
Trade-offs: Sin plan global, puede divagar en tareas largas. El costo de tokens crece linealmente con los pasos.
Mejor como: Default para la mayoría de sistemas de un solo agente.
2. Plan-Ejecutar
El agente genera un plan completo por adelantado, luego ejecuta los pasos. A menudo, un agente (o paso) «ejecutor» separado maneja cada elemento del plan.
Fortalezas: Auditable — puedes leer el plan antes de que se ejecute cualquier acción. Reanudable — si el paso 3 falla, sabes exactamente dónde reintentar. Paralelizable — los pasos independientes del plan pueden ejecutarse concurrentemente.
Trade-offs: Los planes se vuelven obsoletos si la realidad cambia durante la ejecución. Requiere buena capacidad de planificación del LLM; los modelos pequeños a menudo planifican mal.
Mejor para: Flujos de trabajo con estructura clara y alto riesgo.
3. Reflexión (Auto-Crítica)
El agente actúa, evalúa su propia salida contra un criterio y reintenta con la crítica como contexto adicional. El bucle continúa hasta que la salida pasa la crítica o se alcanza un presupuesto de reintentos.
Fortalezas: Se auto-mejora sin feedback humano. Útil para generación de contenido, código y otras tareas con criterios de calidad implícitos.
Trade-offs: La latencia se multiplica con los reintentos. El LLM crítico puede estar equivocado; podrías iterar hacia la respuesta incorrecta.
Mejor para: Tareas de generación donde la calidad es crítica.
4. Árbol de Pensamientos (Tree-of-Thoughts)
El agente explora múltiples caminos de razonamiento en paralelo, luego los evalúa y elige el mejor. Un árbol de decisiones en lugar de una sola cadena.
Fortalezas: Maneja bien la ambigüedad. Encuentra soluciones no obvias mediante exploración.
Trade-offs: El costo de tokens se dispara. La latencia es alta. A menudo es excesivo para tareas donde una sola cadena de razonamiento sería suficiente.
Mejor para: Investigación, ideación creativa y entornos adversariales.
5. Multi-Agente
Varios agentes especializados coordinados por un supervisor (o mediante conversación peer-to-peer) para completar una tarea compleja.
Fortalezas: Descompone tareas complejas. Diferentes agentes pueden usar diferentes modelos. Las subtareas paralelas aceleran el proceso.
Trade-offs: La propagación de estado entre agentes es la parte difícil. La depuración es significativamente más difícil que con un solo agente. El costo de tokens se dispara.
Mejor cuando: La tarea se descompone genuinamente en preocupaciones especializadas.
Arquitectura de Memoria en Detalle
Los agentes en producción necesitan políticas de memoria explícitas, no valores por defecto. La arquitectura correcta depende de:
- Continuidad de sesión: ¿el usuario espera que el agente recuerde la última conversación?
- Estado entre tareas: ¿el agente necesita rastrear hilos de varios días o semanas?
- Aprendizaje específico de usuario: ¿debería el agente recordar preferencias individuales?
- Cumplimiento normativo: ¿qué datos puedes almacenar, dónde y por cuánto tiempo?
Una arquitectura de partida razonable:
| Nivel | Implementación |
|---|---|
| Corto plazo | Ventana de contexto completa para la ejecución actual |
| Memoria de trabajo | Búsqueda vectorial sobre documentos relevantes, recuperada por paso (1–5 resultados, no 20) |
| Largo plazo | Registros estructurados (perfil de usuario, historial de tareas, preferencias) en una base de datos — recuperados por consulta, no volcados al contexto |
Arquitectura de Herramientas
Tres principios separan una arquitectura de herramientas limpia de un desastre enmarañado:
-
Cada herramienta hace una cosa bien. Una herramienta
hacer_cosas_crmes una pesadilla de mantenimiento. Herramientas separadascrear_contacto,actualizar_etapa_trato,agregar_notason depurables. -
Las herramientas devuelven resultados estructurados. JSON con campos explícitos de éxito/error, no texto libre que el siguiente paso tenga que analizar.
-
Las herramientas de alto riesgo requieren confirmación explícita. Reembolsos, emails masivos, operaciones destructivas no deberían estar a una llamada LLM de distancia de ejecutarse.
El estándar MCP está ayudando aquí — los servidores MCP exponen herramientas con esquemas estructurados, y la mayoría de los frameworks ahora los consumen de forma nativa.
Trade-offs de Producción
| Trade-off | Cuándo importa | Qué hacer |
|---|---|---|
| Latencia vs. profundidad de razonamiento | Agentes en tiempo real orientados al cliente | Usa modelos pequeños para el bucle, modelos grandes solo para decisiones difíciles |
| Mono-agente vs. multi-agente | Tarea compleja con sub-roles claros | Empieza con uno, descompón solo cuando los datos lo exijan |
| Planificación implícita vs. explícita | Flujos de trabajo de alto riesgo | Los planes explícitos son auditables y reanudables |
| Stateful vs. stateless | Interacciones repetidas con usuarios | Los agentes stateful necesitan arquitectura de memoria; stateless son más simples |
| Muchas herramientas vs. pocas | Más herramientas mejoran capacidad pero degradan la selección | Agrupa herramientas, recupera subconjunto relevante por paso |
Cómo Empezar
Si estás diseñando una arquitectura de agente desde cero:
-
Elige el patrón más simple que resuelva el problema. ReAct vence a Plan-Ejecutar vence a Multi-Agente para la mayoría de los puntos de partida.
-
Separa las seis capas explícitamente. Incluso en un agente pequeño, nómbralas. El código en un solo archivo está bien; las abstracciones confusas no.
-
Decide tus niveles de memoria por adelantado. ¿Solo corto plazo? Añade memoria de trabajo cuando la presión de la ventana de contexto comience a doler. Añade largo plazo cuando los usuarios se quejen de que el agente no los recuerda.
-
Construye la supervisión primero, no al final. Los registros de auditoría y las puertas de aprobación son más fáciles de añadir el día uno que de adaptar después del primer incidente.
-
Instrumenta antes de optimizar. Trazas, costos, latencia, tasas de éxito — no puedes mejorar lo que no mides.
Las mejores arquitecturas de agentes de IA en 2026 no son las más ingeniosas. Son las que tienen los límites más limpios, la cantidad correcta de memoria y una supervisión que te sentirías orgulloso de mostrarle a un auditor de cumplimiento.