Agentes de IA en 2026: MCP, los límites de la memoria y el muro de la interoperabilidad

La Stanford Emerging Technology Review 2026 es inusualmente directa sobre la distancia entre las demos de agentes y los agentes en producción:

Los agentes de IA, idealmente, operan ejecutando tareas con una intervención y una supervisión humanas mínimas. … Pero, desde el punto de vista técnico, los agentes actuales presentan limitaciones importantes.

El informe pone nombre a cuatro: memoria, fiabilidad, interoperabilidad y eficiencia. Yo me he topado con al menos tres de las cuatro en producción, y lo mismo le ha pasado a cualquiera que esté desplegando sistemas agénticos en 2026. Quiero ser específico con cada una: dónde ha avanzado de verdad la industria y dónde siguen produciéndose los fallos.

1. Memoria: la longitud de contexto no es memoria

El planteamiento del informe es preciso: la memoria de trabajo de un agente está acotada por la longitud de contexto, y esa longitud — incluso en los mejores sistemas — «sigue sin ser suficiente para recordar todos los detalles necesarios para ejecutar muchas tareas de varios pasos, especialmente entre sesiones distintas».

En producción, esto se traduce en:

• El agente llega al paso 17 habiendo olvidado lo que aprendió en el paso 3, porque el razonamiento inicial se perdió al compactar el contexto.
• La continuidad entre sesiones («recuerda lo que decidimos ayer») no es una capacidad del modelo; es un sistema externo que te toca construir.
• Las ventanas de contexto largas dan más margen, pero no resuelven el problema de fondo — y empeoran la latencia y el coste.

Implicaciones de ingeniería:

• Trata la memoria episódica como infraestructura de la capa de aplicación, no como una funcionalidad del modelo. Los vector stores, los logs de eventos estructurados, los pipelines de resumen y las políticas de recuperación pertenecen a tu arquitectura, no al modelo.
• Distingue la memoria de trabajo de la semántica y de la episódica. Tienen patrones de acceso distintos, frecuencias de actualización distintas y modos de fallo distintos. Una única base de datos vectorial haciendo las tres cosas es mala señal.
• La compactación es una decisión de diseño, no un valor por defecto. Cuándo comprimir el contexto antiguo, qué resumir, qué descartar del todo: son políticas que moldean el comportamiento del agente. El resumen automático con heurísticas por defecto produce agentes que olvidan cosas importantes con un aplomo total.

2. Fiabilidad: deriva de objetivos, bucles infinitos, agotamiento de recursos

El informe señala tres modos de fallo concretos:

• Deriva de objetivos — el agente deja de perseguir su objetivo original y se distrae con algo menos relevante.
• Bucles infinitos — el agente se queda atascado repitiendo acciones sin avanzar.
• Agotamiento de recursos — el agente quema cómputo y memoria en reintentos y callejones sin salida.

Cualquiera que haya operado un agente autónomo en producción ha visto los tres. No son casos límite: son el comportamiento por defecto de un agente insuficientemente restringido en condiciones reales.

Qué funciona en la práctica:

• Seguimiento explícito del objetivo. El objetivo actual del agente debería ser un artefacto estructurado, no una cadena enterrada en el historial de prompts. Cada acción debería poder evaluarse contra él. La deriva se detecta cuando el objetivo está estructurado.
• Detección de bucles en la capa de orquestación. Guardas de máquina de estados, detección de ciclos sobre el grafo de acciones y límites duros al número de acciones por tarea. No confíes en que el modelo se dé cuenta de que está en bucle.
• Presupuestos de obligado cumplimiento. Límites duros de tokens, tiempo y dinero por tarea. Los presupuestos blandos se sobrepasan en silencio; los duros fallan haciendo ruido y costando poco.
• Checkpoints de reflexión. A intervalos fijos, el agente reevalúa su progreso frente al objetivo original. Si el progreso es cero, se escala a un humano o se aborta. Es lo más parecido a un «paso de aceptación» que tienen los sistemas agénticos, y hay que construirlo de forma explícita.

3. Interoperabilidad: MCP es un progreso real

El informe destaca el Model Context Protocol (MCP), presentado por Anthropic en noviembre de 2024 y adoptado desde entonces por OpenAI, Google DeepMind y Microsoft, como el estándar abierto que resuelve la integración segura y eficiente entre agente y sistema. Es el primer protocolo concreto que se menciona en el capítulo, y se ha ganado ese lugar.

Qué resuelve MCP de verdad:

• Una interfaz común para que los agentes lean archivos, ejecuten funciones, gestionen prompts contextuales y se conecten a herramientas, fuentes de datos y aplicaciones.
• Autenticación, declaración de capacidades y formato de mensajes estandarizados entre proveedores.
• Una salida de los formatos de tool-use a medida de cada proveedor que hacían imposible escribir código de agente portable.

Qué no resuelve MCP:

• La interoperabilidad semántica. Dos servidores MCP pueden exponer cada uno una herramienta get_customer con esquemas, semántica y garantías de consistencia completamente distintos. El protocolo sube el problema un nivel; no lo hace desaparecer.
• La autorización con la granularidad adecuada. «Este agente puede llamar a esta herramienta» es un permiso de grano grueso. «Este agente puede llamar a esta herramienta solo con estas estructuras de argumentos, solo sobre datos que pertenecen a este usuario, solo en horario laboral» — esa es la frontera de seguridad real, y vive en tu aplicación, no en MCP.
• La coordinación entre agentes. MCP estandariza la comunicación agente-sistema. La coordinación agente-agente (workflows multiagente, delegación jerárquica, coordinación tipo mercado) sigue siendo un problema abierto.

La lectura correcta de MCP para un equipo de ingeniería: adóptalo, pero no lo confundas con tener la integración resuelta. Elimina una capa de dolor. Las capas más duras — diseño de esquemas, autorización, observabilidad de las llamadas a herramientas, trazas de auditoría de las acciones del agente — siguen siendo cosa tuya.

4. Eficiencia: la especialización es la frontera real

El informe es claro: el progreso está pasando de «modelos cada vez más intensivos en recursos» a exprimir mejor los recursos existentes — datos sintéticos, aritmética de menor precisión, destilación, curación de los datos de entrenamiento. Para quien construye agentes, la versión operativa es esta:

• Modelos pequeños especializados para subtareas. Enrutado, clasificación, extracción, resumen: nada de eso necesita un modelo frontera. Un modelo de 7B parámetros bien afinado suele superar al frontera en coste por tarea por un orden de magnitud o más, con calidad comparable en esa tarea concreta.
• Cadenas de razonamiento cacheadas. Una parte sorprendente del trabajo de un agente es razonamiento repetido sobre entradas parecidas. Cachea de forma agresiva a nivel de cadena, no solo a nivel de token.
• Orquestación híbrida. Un modelo frontera como planificador, modelos pequeños como ejecutores. Al planificador se le llama poco; a los ejecutores, constantemente. Esa es la arquitectura que escala.

Dónde rompen de verdad los agentes en producción

Si tuviera que escribir la guía de campo a partir de lo que he visto salir a producción y romperse, sería esta:

• Al agente se le dan herramientas, pero no restricciones. Puede hacer cualquier cosa; hace la equivocada muy rápido.
• La memoria es un saco único. Vector store, todo el conocimiento, sin esquema. La recuperación es ruidosa. El razonamiento se degrada.
• Las rutas de fallo no están gestionadas. La herramienta devuelve un error → el agente improvisa → la improvisación parece plausible → la auditoría descubre después el disparate.
• El coste es invisible. Sin telemetría de coste por tarea. Llega la factura. No se revierte nada.
• La evaluación va a ojo. Sin suite de regresión. Cada cambio de prompt es un acto de fe.

Ninguno de estos es un problema del modelo. Todos son problemas de ingeniería. El contraargumento honesto es que los modelos mejores absorberán parte de esto — y lo hacen: cada generación entra menos en bucle y retiene más contexto. Pero cada actualización de modelo que he visto aterrizar ha movido la frontera del fallo, no la ha eliminado. Las restricciones, los presupuestos y las trazas de auditoría hubo que construirlos igualmente.

Dónde encaja Conectia

Construir agentes que no fallen de estas formas concretas es una competencia de ingeniería distinta de construir funcionalidades de chat. Exige instinto de sistemas distribuidos (máquinas de estado, idempotencia, observabilidad), instinto de seguridad (autorización en la capa correcta, trazas de auditoría, sandboxing) y criterio específico de IA (cuándo añadir un paso de reflexión, cuándo restringir las llamadas a herramientas, cuándo devolver el control a un humano).

Los ingenieros que incorporamos desde Conectia están seleccionados exactamente para esta capa: diseño de sistemas y dominio de la IA evaluados a la vez, por CTOs en activo, sobre escenarios reales. Las lecturas de fondo relevantes son De la Automatización a la Autonomía: Hoja de Ruta para Agentes de IA Autónomos y Arquitectura de Gobernanza Verificable para IA Agéntica.

La manera en que el informe de Stanford plantea las limitaciones de los agentes es honesta de un modo que el material de la mayoría de proveedores no lo es. Trátalo como una checklist: ¿cuáles de las cuatro — memoria, fiabilidad, interoperabilidad, eficiencia — aborda de verdad tu arquitectura actual? Las que no aborda son las que fallarán en producción.