Capítulo 1 — La crisis de integración de la IA y el auge de la arquitectura agéntica

Primera entrega del recorrido capítulo por capítulo de LLM Primer IV: Designing AI Cognition with MCP. En el que el patrón dominante de 2024 — system prompt largo, un puñado de herramientas, una sola ventana de contexto a la que se le pide hacerlo todo — falla en una secuencia reconocible, y el fallo apunta a una capa de protocolo hacia la que el campo llevaba ya tiempo trabajando en silencio.

Por qué existe este capítulo

Durante cerca de dos años, la receta estándar para una aplicación basada en LLM fue ésta: escribe un system prompt largo, engánchale un puñado de herramientas, llámalo agente. La receta servía para las demos. También, previsiblemente, se rompía a medida que la superficie crecía. Los prompts pasaban de los seis mil tokens. Los inventarios de herramientas pasaban de los cuarenta. El equipo parcheaba, auditaba, hacía regresión y, en algún momento, notaba que añadir funcionalidades se había vuelto exponencialmente más caro que antes. El diagnóstico no era pereza ni mala ingeniería. Era una arquitectura que obligaba a hacer pasar cada preocupación por un único recurso compartido — el contexto del modelo — y un problema combinatorio más profundo escondido debajo.

Este capítulo recorre los modos de fallo en el orden en que los equipos se los encuentran, les pone nombre, y luego dibuja la salida arquitectónica. La salida es una capa de protocolo que permite a modelos y herramientas encontrarse sin pegamento hecho a mano, y una disciplina — la ingeniería de contexto — que trata la vista del modelo como un presupuesto a administrar más que como un campo de texto libre. Las dos ideas preparan el resto del libro.

1.1 El agente monolítico y por qué su system prompt acaba por romperse

La primera generación de aplicaciones LLM en producción tenía una forma arquitectónica sencilla. Un system prompt de varios miles de tokens describía rol, herramientas, restricciones, tono y casos límite. Funcionaba para superficies estrechas. A medida que el equipo añadía funciones párrafo a párrafo, el prompt se convertía en el artefacto más largo del repositorio, editado casi siempre por adición porque quitar cualquier cosa resultaba arriesgado.

Lo que ese prompt estaba haciendo internamente se entiende mejor a través de la atención. Un transformer calcula pesos de atención sobre cada token de su contexto, incluido cada token del system prompt. Un prompt de seis mil tokens no se lee por encima — se promedia. Cuanto más largo el prompt, más se reparte la masa de atención entre instrucciones irrelevantes para el paso actual. El fenómeno tiene nombres: dilución de contexto, colisión de instrucciones, deriva de capacidades. El equipo observa la regresión y no puede localizar la causa, porque la causa es la interacción entre tres reglas nuevas y una cláusula añadida hace dos sprints.

Aparece un fallo emparentado en la capa de herramientas. Con diez herramientas, el modelo elige bien; con cuarenta, la precisión en la selección cae, a veces de golpe. El equipo parchea añadiendo lenguaje desambiguador, lo que alarga el prompt, lo que diluye la atención aún más. El sistema ha entrado en un bucle de realimentación consigo mismo.

1.2 Especialización y la curva de mantenimiento que se dobla del lado equivocado

Bajo el problema del prompt hay uno más profundo. Los modelos de propósito general de frontera son generalistas fuertes, pero el rendimiento generalista es un promedio sobre una superficie enorme, y los promedios esconden acantilados. La revisión de contratos legales, la codificación médica estructurada, la conciliación financiera — cada una tiene vocabulario interno, reglas internas y una tolerancia al error que el entrenamiento general no optimiza. El instinto es especializar mediante el prompt; el coste es más presupuesto de atención consumido a cambio de menos retorno. La especialización genuina quiere su propio componente con su propio contexto enfocado, y el agente monolítico no tiene dónde meterlo.

El mantenimiento escala en la misma dirección equivocada. Un agente monolítico con cincuenta herramientas en cuatro dominios no tiene diez veces la carga de mantenimiento de uno con cinco herramientas y un dominio — tiene más, porque cada función interactúa con todas las demás a través del prompt compartido. La velocidad del equipo la marca el coste de mantener coherente la superficie existente, no el coste de construir capacidad nueva. El coste de inferencia escala con la longitud del contexto, así que la presión económica por encoger el prompt y la presión de ingeniería por alargarlo tiran en direcciones opuestas.

1.3 El problema de integración N por M

Acepta el caso para la descomposición. Ahora tienes N componentes con modelo y M integraciones de herramientas. Sin un protocolo compartido, el coste de integración es N por M — cada modelo necesita su código adaptador hecho a mano para cada herramienta, con las manías de cada modelo multiplicadas cartesianamente por las manías de cada herramienta. Una nueva versión del modelo significa volver a probar cada herramienta. Una nueva herramienta significa escribir N adaptadores.

La historia de la informática tiene un nombre para esta forma y otro para el remedio. Antes de LSP (2016), cada editor necesitaba integración con cada lenguaje — editor por lenguaje. LSP introdujo un protocolo; la matriz se colapsó a coste aditivo. Antes de USB, cada categoría de periférico tenía su propio puerto y cada sistema operativo enviaba sus propios drivers. Después de USB, un host, un dispositivo, un protocolo compartido en medio. El Model Context Protocol es el mismo movimiento aplicado a modelos y herramientas. No elimina los adaptadores; los estandariza. La primera integración es más lenta; la centésima es mucho más rápida; la milésima es prácticamente gratis porque el utillaje se ha ido acumulando. Todo el juego está en la curva acumulativa.

Un protocolo con descubrimiento también colapsa una segunda matriz más silenciosa — la matriz de descripciones. El modelo ya no necesita tener cada herramienta enumerada en su system prompt al arranque; puede preguntarle al protocolo "¿qué hay disponible ahora mismo?" y recibir un catálogo estructurado desde la fuente autoritativa: el propio servidor.

1.4 De la ingeniería de prompts a la ingeniería de contexto

Un cambio de vocabulario sigue al cambio arquitectónico. En 2022-2023 la disciplina era la ingeniería de prompts — encontrar formulaciones que empujaran al modelo hacia el comportamiento deseado. En 2025 el prompt era una entrada entre muchas. El modelo ve además documentos recuperados, descripciones de herramientas, turnos previos, resultados de herramientas, notas en el scratchpad, fragmentos de memoria. Qué debería haber en ese contexto en cada paso ya no se contesta con redacción. Se contesta con una arquitectura que decide, por turno, qué debería estar mirando el modelo.

El término que ha cuajado es ingeniería de contexto. Trata la ventana de contexto como un presupuesto administrado. Los modelos modernos de contexto largo anuncian ventanas de un millón de tokens, pero el rendimiento se degrada de manera no lineal a medida que el contexto se llena — el fenómeno que algunos llaman "context rot". Un modelo al que se le entrega un contexto de un millón de tokens con la respuesta enterrada dentro suele rendir peor que el mismo modelo al que se le entregan diez mil tokens cuidadosamente seleccionados. El presupuesto que importa no es el tamaño de la ventana; es la densidad de señal útil dentro de lo que el modelo tiene de verdad delante.

MCP es, en parte, la infraestructura que hace practicable la ingeniería de contexto. El protocolo le da al host la maquinaria para preguntar qué herramientas y qué fuentes de datos están disponibles, para traer las relevantes en el momento adecuado, para negociar qué capacidades puede invocar el modelo. El host construye el contexto dinámicamente, por turno, en función de lo que la tarea actual de verdad requiere.

Lo que prepara el Capítulo 1

El diagnóstico tiene tres partes: los agentes monolíticos fallan porque los prompts largos diluyen la atención; la capacidad especializada no puede vivir dentro de un prompt compartido; debajo de ambas cosas está el problema de integración N por M. Cada modo de fallo apunta en la misma dirección — una capa bajo el modelo que medie cómo modelos y herramientas se encuentran, se describen y negocian lo que pueden hacer. El Capítulo 2 introduce esa capa: los tres roles que MCP define, el pequeño conjunto de primitivas conceptuales, y el ciclo de vida de la sesión que abre con una negociación explícita de capacidades.

Próximamente — Capítulo 2: Desentrañando el Model Context Protocol. Qué es MCP, qué quiere decir realmente la fórmula "USB-C para la IA", la división en tres roles Host, Cliente y Servidor, y por qué el descubrimiento dinámico y la mensajería bidireccional hacen que MCP se comporte de un modo distinto a una API REST en los casos que importan.