Capítulo 8 — Distribuciones arquitectónicas de despliegue

Octava entrega del recorrido capítulo por capítulo de LLM Primer IV: Designing AI Cognition with MCP. En el que dos sistemas con orquestación idéntica resultan comportarse de manera muy distinta en producción, porque la pregunta "dónde corre el modelo en realidad" tiene tres respuestas y cada una fija un techo distinto de latencia, coste y seguridad.

Por qué existe este capítulo

Los Capítulos 6 y 7 especificaron cómo se coordinan los agentes. Guardaron silencio sobre una pregunta que decide tanto del comportamiento real del sistema: ¿dónde corre cada agente, y cómo se reparten modelos de lenguaje, servidores MCP y herramientas a través de la red? Las decisiones arquitectónicas de este capítulo tocan cada petición y cada euro. Tres distribuciones ampliamente distintas han emergido en el ecosistema MCP a lo largo de 2025 y entrada ya 2026, y ninguna de las tres es universalmente correcta. Cada una está optimizada para una combinación distinta de restricciones, y la elección tiene consecuencias que los ingenieros deberían poder articular antes de tomarla.

8.1 El agente de IA reutilizable: modelo empaquetado con el servidor

La primera distribución empaqueta un modelo de lenguaje junto con un servidor MCP y expone la combinación como una única capacidad de caja negra. El cliente llama "revisa este pull request" como si fuera una herramienta; por debajo, un bucle agéntico completo corre del lado del servidor, invocando al modelo, llamando a herramientas internas y devolviendo sólo la salida final. El patrón surgió cuando organizaciones que construyeron agentes especializados — de investigación, de revisión de código, de análisis financiero — quisieron exponerlos a muchas aplicaciones host distintas sin que cada una tuviera que entender los entresijos.

Las fortalezas son reales. La encapsulación deja a los autores del agente cambiar de modelo o reestructurar la orquestación sin ningún cambio visible para los clientes. La reutilización entre aplicaciones host significa que un solo agente sirve a Claude Code, a una app empresarial y a un chatbot orientado al cliente a través de la misma interfaz. Los costes son igual de reales. La opacidad dificulta la depuración: cuando el agente toma una decisión equivocada, el cliente no ve por qué. La latencia se apila porque el bucle del servidor corre en cada llamada. Y el doble presupuesto es estructural: el operador del agente paga sus invocaciones de modelo y el cliente paga las propias, y el coste total por interacción puede ser más alto de lo que ninguna de las dos partes percibe al principio.

La variante multi-tenant — un solo proceso de agente sirviendo a muchas organizaciones cliente — mejora de forma sustancial la economía operativa al amortizar los costes fijos entre tenants. También introduce la fuga de datos entre tenants como modo de fallo de primera clase. Varios incidentes publicados en 2025 involucraron exactamente esto, y los operadores deberían diseñar la tenancia dentro del runtime en vez de fiarse de la revisión de código para atrapar fugas entre peticiones.

8.2 Pureza estricta de MCP: el modelo en el cliente

La segunda distribución pone el modelo estrictamente en el cliente. Los servidores MCP exponen sólo datos y herramientas — nada de inferencia. El host corre el modelo, toma las decisiones de orquestación y llama a los servidores para reunir contexto y ejecutar acciones. La motivación es la razón de ser original del protocolo: MCP existe para resolver el problema de integración N por M proporcionando una interfaz uniforme entre modelos y herramientas, y los servidores que corren sus propios modelos reintroducen el problema que el protocolo vino a resolver.

Las fortalezas son control y transparencia. Cada llamada al modelo es observable para la instrumentación del cliente. El cliente elige el modelo por petición, puede caer hacia atrás entre proveedores y asume todo el coste de modelo directamente — sin doble presupuesto porque no hay un segundo modelo en la cadena. Para industrias reguladas donde los logs de auditoría del cliente deben capturar la cadena de razonamiento completa, la pureza estricta satisface el requisito sin ambigüedad.

Los costes son igual de claros. Cada pieza de inteligencia hay que reimplementarla en cada cliente, lo que es una carga real para organizaciones con muchas aplicaciones host. Algunas capacidades — investigación multi-paso, refinamiento iterativo — son incómodas de factorizar como herramientas de un solo disparo, y exponerlas empuja la orquestación compleja al cliente o viola en silencio la pureza dejando que el servidor corra su propio modelo. Y el cliente tiene que ser capaz de correr orquestación, lo que en la práctica significa apoyarse en Strands, LangChain, Semantic Kernel o Microsoft Agent Framework en vez de escribir el bucle desde cero.

8.3 Híbrida: orquestación del lado cliente con ejecución del lado servidor

La tercera distribución parte la diferencia. El cliente orquesta y corre la inferencia primaria; ciertos servidores MCP corren sus propias invocaciones de modelo para subtareas especializadas. El ejemplo más claro es una herramienta de investigación profunda de larga duración. Un cliente que necesite plegar un resultado de investigación dentro de un workflow más amplio no quiere gestionar cada paso de la investigación él mismo; quiere llamar "investiga X y dime qué encontraste" y recibir una síntesis. La investigación es multi-paso, multi-fuente, y se beneficia de su propia orquestación interna.

El patrón híbrido funciona cuando la frontera se traza en una costura significativa — una subtarea con entradas y salidas claras, lo bastante autocontenida como para que la inteligencia del servidor pueda completarla sin coordinación del cliente, y lo bastante especializada como para que correrla como caja negra bata a correrla a través del orquestador general. Investigación, análisis de código, síntesis documental encajan en el perfil. La conversación general no.

El coste es la complejidad arquitectónica. Hay ahora dos sitios donde corre inteligencia, la observabilidad tiene que cruzar la frontera, y la atribución de coste se sitúa entre los dos patrones puros. Una disciplina útil es limitar el número de servidores inteligentes y mantener cada uno enfocado en una capacidad bien definida. Dos o tres son operables; doce se convierten en una federación que ningún equipo entiende. Los despliegues híbridos también tienden a evolucionar hacia uno u otro extremo del espectro con el tiempo, y los arquitectos deberían ser honestos sobre si su híbrido es un diseño estable o un estado transitorio.

Lo que prepara el Capítulo 8

Los tres capítulos de la Parte III han recorrido el espacio de diseño de sistemas multi-agente desde la perspectiva del mecanismo. Lo que aún no cubren es el sustrato por debajo: el contexto que cada invocación de modelo recibe y la memoria que persiste entre invocaciones. La eficacia de un agente depende de lo que pueda ver al actuar y de lo que pueda recordar de lo que ha hecho antes. La ventana de contexto es finita. La arquitectura de memoria hay que diseñarla. Los patrones de gestión de presupuesto de atención, uso de scratchpad, memoria episódica y semántica son el sustrato que convierte un conjunto coordinado de agentes en un sistema que hace trabajo útil a lo largo de horas, días o más.

Próximamente — Capítulo 9: Administrando el presupuesto de atención. Por qué una ventana de un millón de tokens es un valor techo más que un punto de operación, qué se come el presupuesto, y cómo MCP, RAG y fine-tuning encajan cada uno con una forma distinta de hueco.