AI Agents en 2026: El Stack Completo Para Construir Agentes Que Funcionan de Verdad
Los AI Agents están en todos lados, y junto con ellos llegó un problema clásico: la gente está eligiendo herramientas antes de entender lo que el problema realmente necesita.
Imagina un equipo que pasa tres semanas configurando LangGraph para un chatbot de soporte, con 14 nodos en un grafo de estado, un checkpointer customizado grabando en Redis y lógica de retry para llamadas a herramientas que fallan una vez por semana. Al final del día, el agente responde preguntas sobre reembolsos y llama a una única API. Cincuenta líneas de código usando el SDK de OpenAI con dos servidores MCP habrían resuelto exactamente lo mismo. El problema no fue la elección de la herramienta en sí, sino no haber mapeado qué capas necesitaba realmente el problema antes de empezar a construir.
En noviembre de 2024, Letta publicó un diagrama del stack de agentes de IA que se convirtió en referencia estándar para buena parte de los equipos de ingeniería. Si ya viste esa imagen de capas de un agente en LinkedIn o fijada en algún canal de Slack, probablemente vino de ahí. El problema es que ese diagrama ya tiene 14 meses, y muchas cosas cambiaron desde entonces 🗺️
El MCP todavía no existía. La memoria se trataba como un subconjunto de la base de datos vectorial. Nadie estaba lanzando SDKs nativos de agentes desde los proveedores. Y la evaluación ni siquiera entraba en el mapa. En 2026, el stack tiene seis capas, y al menos tres de ellas no existían como categorías distintas cuando se dibujó el diagrama original. El artículo original que mapea este nuevo escenario fue publicado por Paolo Perrone en Substack The AI Engineer y republicado por O’Reilly con permiso del autor.
Antes del Stack, Existe el Loop
Antes de hablar sobre capas y herramientas, vale la pena entender qué es un AI Agent de verdad. Un agente se define por el ciclo pensar-actuar-observar: el modelo razona sobre una tarea, toma una acción como llamar a una herramienta o grabar en la memoria, observa el resultado y repite el proceso hasta que la tarea esté completada. Ese loop es la unidad atómica. Todo el stack existe para hacer que ese loop funcione de forma confiable, a escala, en producción.
Y aquí va una distinción fundamental: el stack de agentes no es el stack de LLM. Un chatbot necesita inferencia y quizás RAG. Un agente necesita gestión de estado en ejecuciones con múltiples pasos, acceso a herramientas gobernado por protocolos, memoria que persiste entre sesiones, loops de razonamiento autónomos y guardrails que restringen el comportamiento en tiempo real. Son problemas de infraestructura fundamentalmente diferentes.
Tres cosas rediseñaron el mapa entre 2024 y 2026. El MCP estandarizó la conectividad de herramientas, y la capa entera de protocolos es nueva por eso. Modelos de razonamiento como o1 y o3 cambiaron lo que los agentes pueden hacer de forma autónoma, con llamadas únicas sustituyendo algunas cadenas de múltiples pasos. Y la memoria se convirtió en un primitivo arquitectónico de primera clase, no un añadido improvisado sobre una base de datos vectorial.
Cómo Evaluar Cada Capa del Stack
A la hora de elegir herramientas en cada capa, tres preguntas cortan la confusión:
- ¿Cuánta gestión de estado necesitas? Un llamador de herramientas sin estado y un agente multi-sesión que aprende con el tiempo son problemas de ingeniería completamente diferentes. Las capas donde la gestión de estado es más difícil, como memoria y frameworks, son donde la mayoría de los equipos se atascan.
- ¿Cuánto vendor lock-in toleras? MCP es un estándar abierto, los SDKs de proveedores no lo son. Cada elección de herramienta aumenta o disminuye el dolor de tu próxima migración.
- ¿Cuál es la distancia entre demo y producción? Algunas capas, como model serving, casi no tienen gap. Otras, como eval y guardrails, tienen un abismo. La capa donde más sientes esa distancia es la que merece inversión primero.
Capa 1: Modelos e Inferencia
La primera capa del stack es cómo ejecutas el modelo que alimenta tu agente: llamando a una API, usando un proveedor gestionado de modelos open weight o haciendo self-host.
La capa de inferencia cambió más en tono que en sustancia. Modelos de razonamiento como o1, o3, DeepSeek R1 y Claude con extended thinking cambiaron lo que los agentes pueden planificar y ejecutar. Agentes que antes necesitaban cadenas con múltiples pasos ahora resuelven problemas en una sola llamada de razonamiento. Modelos open weight como Llama 3.3, DeepSeek V3 y Qwen 2.5 cerraron el gap de calidad de forma dramática, así que el consejo antiguo de siempre usar el modelo cerrado más grande ya no es el estándar. El patrón que está surgiendo es prototipar en closed source y hacer deploy en open weight.
En la práctica, esta capa se está comoditizando. Las diferencias entre modelos importan menos cada trimestre. La decisión real es el trade-off entre costo y latencia, no cuál modelo es el más inteligente. Las llamadas a API son stateless: mandas un request, recibes una respuesta, sin nada que gestionar. El riesgo de lock-in es alto para APIs cerradas porque cada modelo razona de forma diferente, y cambiar de proveedor significa reajustar prompts, adaptarse a modos de fallo diferentes y retestear toda tu suite de evaluación. Para open weight, el riesgo es bajo. El gap entre prototipo y producción es el menor de todas las capas.
Considera hacer self-host cuando el volumen de llamadas de tu agente haga que el pricing de API sea insostenible o cuando necesites latencia por debajo de 100ms que los round-trips de API no pueden entregar.
Capa 2: Protocolos y Herramientas
Esta capa trata de cómo tu agente llama a herramientas externas y APIs: a través de servidores MCP, automatización de navegador o protocolos agente-a-agente.
Reciba el mejor contenido sobre innovación en su correo electrónico.
Todas las noticias, consejos, tendencias y recursos que buscas, directamente en tu bandeja de entrada.
Al suscribirte al boletín informativo, aceptas recibir comunicaciones de Método Viral. Nos comprometemos a proteger y respetar siempre tu privacidad.
Esta capa no existía como categoría distinta en 2024. Cada framework tenía su propio schema JSON para definiciones de herramientas. Ahora MCP es el estándar, con 97 millones de descargas mensuales del SDK, adopción por OpenAI, Google y Microsoft, y donación a la Linux Foundation. El debate sobre protocolos terminó. MCP ganó 🏆
El Browser Use explotó en paralelo, alcanzando 78 mil estrellas en GitHub en menos de un año. Nadie estaba ejecutando agentes de navegador en producción en 2024. Y los agentes ahora pueden conversar con otros agentes: IBM lanzó el ACP y Google lanzó el A2A. Ninguno de los dos es estándar todavía, pero el problema que resuelven, agentes coordinándose con otros agentes, es real y creciente.
La seguridad es el problema abierto. Endor Labs analizó 2.614 servidores MCP y descubrió que el 82% eran vulnerables a path traversal y el 67% a inyección de código. La única cuestión que queda es cómo proteges tus servidores MCP antes de que alguien los explote. La OWASP publicó el MCP Top 10 en versión beta, que es el primer checklist real de seguridad para agentes conectados a herramientas.
La gestión de estado aquí es inexistente: tu agente llama a una herramienta, recibe una respuesta, listo. El riesgo de lock-in es bajo porque MCP es un estándar abierto. El gap entre demo y producción es medio: tu servidor MCP de demostración funciona hasta que alguien envíe una descripción de herramienta maliciosa.
Capa 3: Memoria y Conocimiento — Mucho Más Allá de la Base de Datos Vectorial
La idea de que la memoria en AI Agents se resume a embeddings y búsqueda por similitud quedó atrás. En 2024, memoria significaba elegir una base de datos vectorial y hacer RAG. En 2026, la memoria es un primitivo arquitectónico de primera clase con tres niveles distintos, y todos alimentan el mismo lugar: la ventana de contexto que tu agente ve en cada llamada.
Las ventanas de contexto se volvieron enormes. Gemini llegó a más de 1 millón de tokens, Claude a 200 mil. Pero ventanas más grandes no eliminaron la necesidad de memoria. Cambiaron el trade-off: ¿qué pones directamente en el contexto versus qué buscas bajo demanda?
Context Engineering Reemplazó a Prompt Engineering
En vez de escribir un prompt mejor, la disciplina central ahora es arquitectar qué información ve el agente en cada llamada. Los bloques de memoria surgieron como campos nombrados y estructurados en la ventana de contexto que el agente puede leer y sobreescribir en cada turno. En lugar de meter todo en el system prompt, el agente gestiona su propio estado: qué mantener, qué actualizar, qué descartar.
Los Tres Niveles de Memoria
La memoria de corto plazo, o in-context memory, es lo que vive dentro de la ventana de contexto durante una sola ejecución. Es la más rápida, la más cara en tokens y la más volátil. Cuando la conversación termina, desaparece. Para agentes que solo necesitan completar una tarea dentro de una única sesión, eso basta. Pero cuando el agente necesita retomar una conversación días después o recordar preferencias del usuario, la memoria in-context sola no alcanza.
En infraestructura, pgvector se convirtió en el estándar para equipos que no necesitan una base de datos vectorial dedicada. Es solo Postgres con una extensión. GraphRAG emergió como una segunda opción de retrieval: seguir relaciones entre entidades en vez de combinar embeddings, con Neo4j liderando ese espacio.
La memoria de largo plazo es donde las cosas se ponen interesantes. Herramientas como Letta, Mem0 y Zep empezaron a tratar la memoria persistente como ciudadano de primera clase, con operaciones de lectura y escritura explícitas, políticas de actualización y mecanismos de consolidación. El agente no solo recupera información, decide qué vale guardar, cuándo actualizar una memoria existente y cuándo descartar algo obsoleto. Esa capacidad de gestión activa es lo que diferencia a un agente que parece inteligente de uno que parece solo reactivo.
La mayoría de los equipos complica demasiado la memoria. Empieza con historial de conversación en Postgres y un system prompt estructurado. Agrega búsqueda vectorial cuando el historial supere los límites de contexto. Agrega gestión de memoria agentic solo cuando tu agente necesite aprender entre sesiones. El gap entre prototipo y producción es grande: la memoria de demo funciona porque las ventanas de contexto son lo suficientemente grandes, pero la memoria en producción se rompe cuando las conversaciones se alargan y el agente empieza a olvidar las partes importantes.
Capa 4: Frameworks y SDKs — Eligiendo Sin Perderse
El ecosistema de frameworks para AI Agents explotó. Cada gran laboratorio de IA ahora tiene su propio SDK de agentes. OpenAI tiene el Agents SDK, que evolucionó de Swarm. Google lanzó el ADK. Microsoft tiene Semantic Kernel y AutoGen. Hugging Face construyó smolagents. Hace dos años, LangChain era la única opción. Ahora eliges entre tres campos:
- SDKs de proveedores: rápidos para empezar, pero atados a un modelo
- Frameworks basados en grafos como LangGraph: portables, pero requieren más setup
- Sin framework: wrappers delgados sobre APIs de proveedores + MCP
Esta elección simplemente no existía en 2024.
LangGraph se consolidó como líder de orquestación basada en grafos con la versión 1.0 lanzada en octubre de 2025 y deploys en producción en Uber, JPMorgan, LinkedIn y Klarna. Mientras tanto, el campo del hazlo tú mismo creció. Equipos que probaron LangChain en 2024 y pelearon con la abstracción ahora están escribiendo wrappers delgados sobre APIs de proveedores + MCP. Sin framework significa control total, y eso funciona hasta que tu agente necesite gestión de estado o branching complejo.
Un punto importante sobre nomenclatura: LangChain y LangGraph no son lo mismo. LangChain es la capa de integración que se encarga de conectores de modelo, tool calling y templates de prompt. LangGraph es el motor de orquestación que gestiona estado, flujo de control y grafos. La mayoría de los equipos en producción usa los dos juntos, pero LangGraph es donde vive la lógica del agente.
El riesgo de lock-in en esta capa es el más alto de todo el stack. Tu código de orquestación no es portable. Un agente LangGraph reescrito para CrewAI es un codebase nuevo. Los SDKs de proveedores son peores porque quedas atado a un modelo también. La mayoría de los equipos elige framework de más. Si tu agente llama a un modelo y algunas herramientas, no necesitas LangGraph. Un SDK de proveedor y algunas llamadas a herramientas te llevarán a producción más rápido que cualquier grafo.
Capa 5: Evaluación y Observabilidad — La Capa Que Nadie Ponía en el Mapa
Si hay algo que el diagrama original no cubría y que hoy se trata como crítico, es la evaluación. Esta capa prácticamente no existía en 2024. Ahora es el gap. La encuesta State of Agent Engineering de LangChain descubrió que el 89% de los equipos con agentes en producción implementaron observabilidad, pero solo el 52% tiene evals. Ese gap de 37 puntos es donde muere la calidad en producción 📊
Evaluar un AI Agent es fundamentalmente diferente de evaluar un LLM aislado. Cuando testeas un modelo, pasas un prompt, recibes una respuesta y comparas con una referencia. Cuando evalúas un agente, estás lidiando con secuencias de decisiones, llamadas a herramientas externas, estados intermedios, memoria que evoluciona con el tiempo y resultados que a veces solo tienen sentido en el contexto de toda la trayectoria del agente.
Tres Dimensiones de Evaluación
El enfoque que está convergiendo separa al menos tres niveles:
- Checks rápidos en cada PR: ¿el agente llamó a las herramientas correctas?
- Suites de regresión nocturnas: usan un LLM para juzgar la calidad del output
- Monitoreo continuo en producción: alerta cuando el rendimiento del agente empieza a degradarse
También surgieron nuevos benchmarks específicos para agentes, incluyendo Context-Bench para gestión de memoria, Recovery-Bench para recuperación de errores y Terminal-Bench para agentes de código.
Herramientas como LangSmith, Braintrust y Arize están evolucionando rápidamente para cubrir estas dimensiones. Pero el punto más importante no es qué herramienta usas, es cuándo empiezas a pensar en esto. Los equipos que dejan la evaluación para el final invariablemente descubren que necesitan rearquitectar partes del sistema para que sea lo suficientemente observable como para ser evaluado. La mayoría de los prototipos tiene cero eval. No sientes el dolor hasta que los usuarios en producción encuentran las fallas por ti.
Capa 6: Guardrails y Seguridad
Los guardrails de agentes se convirtieron en una disciplina separada de los guardrails de LLM. En 2024, guardrails significaba filtros de input/output en un modelo. En 2026, tu agente llama herramientas, gasta dinero y toma acciones. Guardrails ahora significa autorizar llamadas a herramientas, imponer rate limits y validar lo que el agente realmente hizo.
El patrón de guardrails antes de la acción surgió de equipos que aprendieron por las malas. Ahora aplican autorización en la capa de ejecución de herramientas, no en la capa de output. Porque cuando filtras la respuesta, el agente ya mandó el email.
Esta es la capa menos madura de todo el stack. No existe un framework dominante ni estándares establecidos. Estás escribiendo código de políticas desde cero. NeMo Guardrails es lo más cercano a un framework, pero igual vas a escribir la mayoría de las reglas manualmente. El gap entre demo y producción es efectivamente infinito: tu demo no tiene guardrails porque nadie está intentando romperla. Producción sí los tendrá.
Y si estás ejecutando workflows multi-agente donde los agentes delegan unos a otros, la propagación de guardrails a través de las fronteras entre agentes es un problema abierto. Va a necesitar lógica de autorización customizada.
¿Qué Tipo de Agente Estás Construyendo?
Esta es la decisión que corta toda la confusión sobre frameworks. El tipo de agente determina en qué capas inviertes y qué herramientas elegir en cada una.
Herramientas que usamos a diario
Llamador de Herramientas Stateless
Responde preguntas de una base de conocimiento, consulta un pedido o verifica stock. Necesitas un SDK de proveedor, MCP y Postgres. Sin framework, sin base de datos vectorial. Esto es un proyecto de fin de semana.
Workflow con Múltiples Pasos
Procesa un reembolso de principio a fin, revisa un PR en cinco archivos o hace triaje y enrutamiento de tickets de soporte. Los pasos dependen unos de otros, las cosas fallan a mitad de camino y los humanos necesitan aprobar antes de que el agente actúe. Necesitas LangGraph, MCP y eval. Construye evals antes de hacer deploy porque estos agentes se rompen silenciosamente.
Agente Que Aprende
Recuerda tus preferencias entre sesiones, mejora en tu codebase con el tiempo o rastrea contexto de proyecto por semanas. Necesitas una arquitectura memory-first, base de datos vectorial y eval. La orquestación es la parte fácil. La parte difícil es decidir qué recordar, qué descartar y cómo evitar que el contexto antiguo contamine respuestas nuevas.
Sistema Multi-Agente
Agentes que delegan a otros agentes, dividen una tarea de investigación entre especialistas o ejecutan workstreams en paralelo. Necesitas el stack completo. Dos agentes pasándose contexto ya es difícil de depurar. Cinco es imposible sin evals a nivel de trace en cada handoff. Construye infraestructura de eval antes de construir el segundo agente.
Agentes de Código: Las 6 Capas en Acción
Los agentes de código como Cursor, Claude Code, Codex y Windsurf son la aplicación más probada del stack de AI Agents. Las seis capas trabajando juntas.
En la capa de inferencia, estas herramientas sirven cientos de millones de solicitudes diarias. Cursor enruta entre Claude, GPT-4 y sus propios modelos fine-tuned dependiendo de la tarea. En la capa de protocolos, servidores MCP conectan a editores, terminales, sistemas de archivos y Git, que es como el agente lee tu código y ejecuta comandos. En la capa de memoria, retrieval con awareness del codebase y reranking garantiza que el agente no lea tu repositorio entero, solo los archivos relevantes para esa edición específica.
En la capa de frameworks, estos son sistemas de orquestación customizados con loops de RL. No es LangGraph, no es SDK de proveedor. Flujo de control construido a medida para generación, revisión e iteración de código. En la capa de eval, Cursor reentrena su modelo de tasa de aceptación cada 90 minutos basándose en si los usuarios aceptan o rechazan las sugerencias. Eso es eval corriendo en producción, continuamente. Y en la capa de guardrails, ejecución en sandbox previene agentes descontrolados. El agente puede escribir y ejecutar código, pero dentro de un contenedor que limita lo que puede tocar.
El Panorama General: Deja de Construir Como si Fuera 2024
La mayoría de los equipos están construyendo como si todavía fuera 2024. Eligen LangGraph antes de saber si necesitan estado. Agregan base de datos vectorial antes de haber superado Postgres. Diseñan arquitecturas multi-agente antes de haber enviado un solo agente que funcione.
Un chatbot que llama herramientas y un sistema de investigación multi-agente prácticamente no comparten infraestructura. Tratar a los dos de la misma forma significa sobredimensionar el primero y subdimensionar el segundo.
Los equipos que superaron ese punto ejecutan evals en cada deploy, no una vez por trimestre. Sus guardrails están en la capa de llamada a herramientas, no en la capa de output. Su arquitectura de memoria fue diseñada intencionalmente, no heredada del default del framework. La mayoría de los equipos hace lo opuesto: cero evals, filtrado solo en el output y un system prompt que crece hasta que la ventana de contexto se ahoga.
El gap no es talento ni presupuesto. Es saber qué capas importan para tu agente específico en vez de medio-construir las seis.
El stack de AI Agents en 2026 es más maduro, más fragmentado y más exigente de lo que era 14 meses atrás. Cada capa tiene sus propias decisiones de diseño, sus propias herramientas en competencia y sus propios trade-offs que solo se hacen visibles cuando estás construyendo algo real. Y una tendencia clara está en el horizonte: los SDKs de proveedores ya están absorbiendo memoria, tool calling y eval básico en una sola API. Para inicios de 2027, la mayoría de los equipos probablemente no va a construir cada capa por separado. Recibirá un stack cada vez más opinado de su proveedor de modelo, y eso va a funcionar para el 80% de los casos. El otro 20%, agentes a escala donde los defaults se rompen, seguirán construyendo de forma customizada en cada capa. Pero incluso en esos casos, cuando algo falla en producción, necesitas saber qué capa falló. Mapear esas capas antes de elegir cualquier herramienta no es burocracia de ingeniería, es lo que separa a los sistemas que funcionan en producción de los sistemas que solo funcionan en la demo.
