Capítulo 13 — Frameworks e integración con la nube
Decimotercera entrega del recorrido capítulo por capítulo de LLM Primer IV: Designing AI Cognition with MCP. En el que nadie construye MCP de producción desde el protocolo crudo, la pregunta honesta de 2025-2026 se convierte en sobre qué framework estandarizar, y la respuesta depende menos de funcionalidades que de en qué nube vive el resto del sistema.
Por qué existe este capítulo
Cuando un equipo ha cableado autenticación, transporte, estado de sesión, reintentos de error, logging estructurado y la docena de detalles más pequeños que separan una demo de un servicio operable, lo que empezó como "hablamos MCP sobre HTTP" se ha convertido en un pequeño framework propio — habitualmente peor que los que ya existen. La pregunta de ingeniería es sobre cuál de los frameworks públicos estandarizar, qué hace bien cada uno y cómo se conectan con los servicios cloud que guardan el estado. Este capítulo recorre el paisaje metódicamente: Strands con Amazon Bedrock; los servicios de AWS que lo rodean para estado y recuperación; Microsoft Agent Framework, LangChain y Semantic Kernel como las otras opciones de producción; y los patrones de integración hacia los que han convergido las arquitecturas de referencia. El objetivo no es coronar un ganador sino describir para qué sirve cada framework de verdad.
13.1 Strands Agents y Amazon Bedrock
Strands es el framework de agentes open-source que AWS lanzó en 2025 y que ahora corre dentro de Amazon Q, AWS Support y el asistente de AWS Glue. El encuadre es deliberado: Strands es model-driven, lo que significa que el bucle que decide qué hacer a continuación es el propio bucle de tool-calling del modelo, no un planner-graph que el framework imponga por encima. El trabajo del framework es hacer ese bucle fiable en producción — gestionar invocaciones de herramientas, manejar estado de sesión, enchufar servidores MCP como fuentes de herramientas de primera clase a través de MCPClient y enrutar todo a través del catálogo de modelos hospedados de Bedrock. La capa de modelo es enchufable — API de Anthropic, OpenAI, Ollama, LiteLLM — pero Bedrock es el valor por defecto y la historia de auditoría.
La historia multi-agente es donde Strands se gana su reputación de producción. Tres patrones de composición se mapean limpiamente con las formas de orquestación de capítulos anteriores: Agents-as-Tools (la forma más simple, un agente envuelto como una herramienta que otro agente puede llamar); Swarm (peer-to-peer con memoria de trabajo compartida); y Graph (topología determinista donde el modelo rellena cada nodo). Los patrones se anidan en producción. El impuesto operativo se paga en observabilidad, y Strands lo paga emitiendo spans de OpenTelemetry por cada invocación de agente, cada llamada de herramienta y cada llamada de modelo — así una composición de cuatro niveles se reconstruye desde los logs sin instrumentación por nivel. Bedrock añade la historia del límite de acceso: IAM controla qué modelos puede invocar un agente dado; CloudTrail registra el uso. Bedrock Guardrails maneja el filtrado de contenido en la pasarela, Knowledge Bases da recuperación gestionada, y AgentCore — el conjunto de primitivas de AWS de 2025 — formaliza memoria, identidad y preocupaciones de runtime para equipos que quieren un runtime totalmente gestionado en vez de auto-alojado.
13.2 AWS como capa de estado
Un agente que corre durante horas y recuerda lo que pasó ayer necesita almacenamiento que sobreviva al proceso. El patrón que ha asentado en producción: estado de runtime (sesión actual, ledger de tarea, llamadas a herramientas en vuelo) en DynamoDB para acceso rápido por clave; estado de artefactos (documentos generados, trabajo intermedio) en S3 con una estructura de clave prefijada por sesión que da fronteras IAM naturales y versionado gratis; estado semántico (memoria a largo plazo, conversaciones previas) en un vector store — OpenSearch Service para memoria de trabajo caliente, el más reciente S3 Vectors para memoria fría o de archivo. La separación en dos niveles entre S3 y DynamoDB no es optimización prematura. Mantiene el item de DynamoDB bajo los 400 KB, evita amplificación de lectura en cada paso, y permite a cada capa escalar de forma independiente.
La elección de la capa de estado determina el modo de fallo del sistema entero. Un agente cuyo estado está sólo en memoria de proceso lo pierde todo al reinicio. Un agente cuya memoria es durable pero cuyo índice está desincronizado recuerda referencias a documentos que ya no encuentra. Los despliegues de producción tratan esto como contratos de consistencia separados: transacciones DynamoDB para atomicidad de estado, lectura fuerte tras escritura en S3 para el contrato de artefacto, una tubería de indexación que publica documentos en S3 antes de hacer upsert de sus vectores para que la recuperación no apunte a algo que aún no existe. La frontera de seguridad merece el mismo cuidado. La guía propia de AWS para Strands recomienda credenciales por sesión vía STS en vez de reusar el rol de runtime para llamadas a herramientas con datos de usuario final — AgentCore Identity automatiza esto — para que la identidad a nivel AWS detrás de una acción destructiva sea el usuario final real, no un rol de agente compartido. En entornos regulados ésa es la única respuesta aceptable.
13.3 Microsoft Agent Framework, LangChain y Semantic Kernel
El lado de Microsoft y open-source del paisaje se asentó de manera distinta. Microsoft Agent Framework llegó a finales de 2025 como la fusión explícita de Semantic Kernel y AutoGen — el modelo de plugin de SK e integración con .NET con los patrones multi-agente de AutoGen y la DX Python-first. La integración MCP está integrada a través de MCPStdioTool y MCPStreamableHTTPTool; Azure AI Foundry es el hogar hospedado, equivalente de Bedrock en el mundo AWS. La diferencia distintiva frente a Strands es que el grafo de conversación entre agentes es un objeto explícito y reproducible — lo que importa enormemente para evaluación, porque una conversación fallida se puede volver a correr con un prompt modificado y compararse turno a turno. El coste es más estructura que la que Strands impone; el intercambio correcto en despliegues maduros, el equivocado en trabajo exploratorio.
LangChain en 2026 es un animal distinto al de 2023. La abstracción original de chains se ha vuelto secundaria; la superficie primaria es LangGraph para orquestación y LangSmith para observabilidad y evaluación. Las fortalezas son amplitud — cada modelo, base de datos y herramienta parece tener un adaptador — y la madurez de evaluación de LangSmith. La debilidad que los profesionales nombran con honestidad es la superficie: las abstracciones de alto nivel del framework son excelentes para el primer noventa por ciento del trabajo, y el diez por ciento final habitualmente se hace pelando capas hasta que el equipo entiende lo que cada una hace. Los equipos que planifican esta transición envían más rápido que los que pelean con las abstracciones. Semantic Kernel sigue siendo el framework para equipos .NET; el modelo de plugin [KernelFunction] encaja limpiamente con hosts de servicio .NET. Un patrón que ha emergido transversalmente: agente delgado, MCP grueso — las capacidades viven detrás de la frontera del protocolo, los frameworks se vuelven proxies delgados, y el mismo servidor MCP lo consumen Strands en AWS, Microsoft Agent Framework en Azure y LangChain en el portátil del desarrollador sin trabajo de porting. Ésa es la trayectoria que el protocolo se diseñó para habilitar.
13.4 Los patrones de integración en producción
Tres patrones se han asentado en las arquitecturas de referencia de 2025-2026. El patrón gateway-y-capa-de-estado pone una pasarela gestionada de modelos (Bedrock, AI Foundry, LiteLLM) delante de la capa de modelo y una capa de estado durable separada detrás. La pasarela es donde viven auth, rate limiting, filtrado de contenido y auditoría; la capa de estado es donde vive la durabilidad. Este patrón es el valor por defecto de producción; los nuevos despliegues deberían adoptarlo salvo que tengan razón específica para no hacerlo, porque los equipos que se saltan la pasarela y llaman al proveedor de modelo directamente se arrepienten en un trimestre. El patrón service mesh MCP trata a los servidores MCP como microservicios y los expone a través de una mesh que maneja mTLS, reintentos y circuit breaking — que merece la pena sólo a escala (más de diez servidores) o en entornos regulados que requieren atestación a nivel de red. El patrón managed-everything entrega runtime, memoria, identidad y registro de herramientas a un servicio gestionado de agentes en la nube (Bedrock AgentCore, Azure AI Foundry Agent Service, Vertex AI Agent Builder); gana para automatización interna y copilots donde el agente no es el producto primario, y pierde para equipos donde el agente es el producto y las palancas operativas importan. Dos patrones que no ganaron, y vale la pena nombrar como ejemplos negativos: todo-en-el-contexto-del-LLM (agentes cuya memoria es un system prompt en crecimiento) y framework-como-orquestador (un DAG rígido con el modelo rellenando los parámetros de los nodos). Ambos mueren en producción por las razones que el Capítulo 9 recorrió, y la lección que el campo absorbió es que el balance correcto entre estructura del framework y libertad del modelo se desplaza más hacia el modelo a medida que el modelo se vuelve más capaz.
Lo que prepara el Capítulo 13
Los frameworks y los servicios cloud permiten a los equipos enviar agentes basados en MCP sin reescribir la pila de protocolo cada vez. Lo que no les dicen, por sí mismos, es si el sistema resultante realmente funciona — si el agente resuelve las tareas para las que se construyó, cómo se comporta bajo carga, dónde están los acantilados de rendimiento, y cómo comparar honestamente dos arquitecturas competidoras. El Capítulo 14 enfrenta esa pregunta de frente: recorre el MCP-Universe Benchmark, los dos modos de fallo sistémico que el benchmark sacó a la luz (degradación de contexto largo y exploración de herramientas desconocidas), y el lado del throughput donde la brecha entre un pool de sesiones compartido y el patrón ingenuo de sesión por petición es aproximadamente un orden de magnitud.
Próximamente — Capítulo 14: Benchmarking, testing y rendimiento. MCP-Universe sobre servidores reales, las mitigaciones de contexto largo y herramientas desconocidas que funcionan, la brecha de diez veces en throughput entre sesión por petición y pools de sesión compartidos, y hacia dónde sigue la serie.
