Tres protocolos, tres trabajos distintos
La forma más rápida de dejar de confundirlos es fijar una frase por cada uno:
- MCP conecta un agente con herramientas.
- A2A conecta un agente con otros agentes.
- AHP conecta el host de una sesión de agente con sus clientes.
No se solapan. Un mismo agente puede —y suele— hablar los tres a la vez, cada uno en su capa. Veámoslos uno a uno.
MCP — Model Context Protocol (agente ↔ herramientas)
MCP es el estándar que introdujo Anthropic para que un modelo/agente hable con el mundo exterior: una base de datos, una API interna, una cuenta de Stripe, un sistema de ficheros. Es la capa de «context and tools». El agente descubre qué herramientas hay disponibles y las invoca con un contrato uniforme, sin acoplarse a la implementación de cada una.
Qué hace: expone y consume herramientas y fuentes de datos de forma estandarizada.
Qué NO hace: no orquesta agentes entre sí, no gestiona sesiones, no razona por ti. Es la fontanería entre un agente y sus capacidades, nada más — y eso es una virtud.
En Foundry esto se materializa en el Toolbox MCP: el hosted agent accede a las herramientas gestionadas (Code Interpreter, Web Search, Azure AI Search, OpenAPI, conexiones MCP propias, e incluso A2A) a través de un endpoint MCP del proyecto, con librerías cliente estándar. La plataforma no te inyecta las herramientas sola: las cableas tú. Ese detalle importa, porque significa que el wiring de herramientas es parte de tu lógica — y por tanto, parte de tu IP.
A2A — Agent2Agent (agente ↔ agente)
A2A resuelve el problema del que MCP no se ocupa: cómo dos agentes independientes, construidos por equipos distintos, sobre frameworks distintos, alojados en redes distintas, se descubren y se delegan tareas sin exponerse el estado interno.
Nació en Google en abril de 2025 y pasó a la Linux Foundation en junio de ese año; en 2026 alcanzó la v1.0 estable, con Agent Cards firmadas y adopción en Copilot Studio, Azure AI Foundry y Bedrock. El descubrimiento arranca con una Agent Card publicada en una ruta conocida (/.well-known/agent-card.json) que anuncia quién es el agente, qué sabe hacer y cómo autenticarse contra él. La comunicación va sobre JSON-RPC + SSE.
Qué hace: descubrimiento, delegación de tareas y estado de tarea entre agentes autónomos, sin que ninguno tenga que enseñarle sus tripas al otro.
Qué NO hace: no te conecta a herramientas (eso es MCP), no define cómo escribes la lógica interna del agente, y —clave para la analogía— no expone tu implementación: justamente su diseño es que un agente delegue «hazme esto» sin revelar el «cómo».
La comparación canónica: un agente de inventario usa MCP para hablar con la base de datos de stock; cuando detecta que algo escasea, usa A2A para pedirle a un agente proveedor externo que reponga. MCP hacia abajo (herramientas), A2A hacia los lados (agentes). Se complementan.
En Foundry, un hosted agent puede exponer un endpoint A2A (preview), además del protocolo de invocaciones. Es decir: tu agente puede ser consumido por otros agentes como una pieza de un sistema mayor, sin publicar su código.
AHP — Agent Host Protocol (host de sesión ↔ clientes)
Aquí es donde casi todo el mundo se pierde, porque AHP opera en una capa que ni MCP ni A2A tocan. AHP no es sobre herramientas ni sobre agentes hablando entre sí: es sobre cómo se sirve y sincroniza una sesión de agente a varios clientes a la vez.
Es el protocolo que Microsoft construyó para VS Code. Define cómo un servidor de sesiones —el agent host— comunica con sus clientes. La sesión vive en un proceso propio, con estado inmutable y reconciliación ordenada, de modo que varios clientes (varias ventanas de VS Code) pueden conectarse a la misma sesión y verla sincronizada sin romper consistencia. El host tiene el estado; los clientes son vistas.
El matiz de diseño es fuerte: mientras el Agent Client Protocol alineó «cómo hablan editor y agente», AHP mueve la sesión a la categoría de recurso que vive en un servidor, no se trata de una cosa efímera atada a una ventana. Esa es la misma dirección de «varios agentes en paralelo, humanos supervisándolos».
Qué hace: hospeda harnesses de agentes de codificación (Copilot, Claude, Codex) en un proceso dedicado y sincroniza su sesión y estado a múltiples clientes.
Qué NO hace: no es un bus de propósito general para conectar cualquier agente externo, no habla con herramientas de negocio (eso es MCP), no delega entre agentes autónomos (eso es A2A). Es, hoy, la columna vertebral de sesiones del IDE.
Resumen
| MCP | A2A | AHP | |
|---|---|---|---|
| Conecta | agente ↔ herramientas | agente ↔ agente | host de sesión ↔ clientes |
| Pregunta que responde | ¿con qué recursos actúo? | ¿qué agente resuelve esta tarea? | ¿cómo veo y comparto esta sesión? |
| Transporte típico | MCP (cliente/servidor) | JSON-RPC + SSE | estado sincronizado sobre proceso host |
| Gobernanza | Anthropic / LF Agentic AI | Linux Foundation (v1.0) | Microsoft (VS Code) |
| En Foundry hoy | Toolbox MCP del proyecto | endpoint A2A (preview) | no expuesto |
| Toca tu IP | sí (wiring de tools) | no (delegación opaca) | sesión, no lógica |
Mi apuesta: llevar AHP a Foundry (hipótesis de trabajo)
Esta parte es especulación fundamentada, no documentación. Hoy un Hosted Agent de Foundry habla Invocations (WebSocket) y A2A; no habla AHP. AHP se queda del lado del IDE. El puente soportado entre VS Code y Foundry es el AI Foundry Toolkit.
Lo que yo estoy intentando con esta prueba de concepto es cerrar ese hueco: exponer un servidor AHP delante del – o dentro del – Hosted Agent, de modo que la sesión del agente en producción sea un recurso AHP más, consumible desde VS Code como si fuera local. ¿Qué compraría eso?
- Seamless real. La misma sesión, servida desde Foundry, vista desde una o varias ventanas del IDE con estado sincronizado. Se elimina la costura entre «orquesto el despliegue» y «trabajo contra el agente».
- IP protegida por construcción. Si el harness y el estado de sesión viven en el sandbox aislado de Foundry, y VS Code es solo un cliente delgado de AHP, la lógica nunca se materializa del lado del IDE. El editor renderiza una vista; el «cómo» se queda en Azure. Es la propiedad de AHP – el host tiene el estado, el cliente es vista – puesta al servicio de la confidencialidad.
Quiero ser muy honesto: AHP está diseñado para hospedar harnesses de coding agents, no para que un endpoint de Foundry actúe de servidor AHP. Haría falta un shim AHP, o que Microsoft permita apuntar el agent host a un endpoint de Foundry como harness. No es un camino soportado a día de hoy — es una dirección que la arquitectura hace plausible, y que encaja demasiado bien con el modelo «sesión como recurso servidor» como para ignorarla.
Hosted Agents vs agentes «escritos»: cuándo te obliga a picar código
Foundry te deja construir agentes de dos maneras muy distintas, y elegir mal es caro.
Un agente escrito (prompt-based) se define enteramente con prompt y configuración de herramientas en el portal. No hay código tuyo: describes comportamiento, enchufas tools, y la plataforma ejecuta. Rápido, cómodo, perfecto para asistentes conversacionales y flujos acotados.
Un Hosted Agent es tu código, empaquetado como imagen de contenedor, corriendo sobre infraestructura gestionada por Microsoft. Tú eliges el framework, controlas el runtime, y despliegas la imagen. Llamas a modelos del catálogo para razonar, pero la orquestación la escribes tú.
Cuándo el prompt no basta, te toca picar código y contenerizar. ¿Cuando necesitas?:
| Capacidad | Prompt-based | Hosted Agent (contenedor) |
|---|---|---|
| Comportamiento por descripción | Sí | Sí |
| Framework propio (LangGraph, Semantic Kernel, Agent Framework, custom) | No | Sí, sin reescrituras |
| Protocolos custom (webhooks, payloads no-OpenAI vía Invocations) | No | Sí |
| Control de compute (CPU/memoria del sandbox) | No | Sí |
Estado persistente ($HOME, /files entre turnos) |
No | Sí |
| Autónomos de larga duración (estilo OpenClaw/Hermes), rutinas en schedule | No | Sí |
| Lógica de negocio compleja en el bucle de razonamiento | Limitado al prompt | Sí, en tu código |
| IP fuera del prompt (reglas, orquestación, wiring de tools) | Vive en el prompt | Vive en el binario |
La línea divisoria es sencilla: en cuanto tu ventaja competitiva no cabe en un prompt —porque es orquestación, control de estado, selección de herramientas o reglas de negocio de verdad— has salido del terreno prompt-based y necesitas código. Y código que corre en producción necesita empaquetarse: contenedor.
Por qué contenerizar el agente es una buena decisión (y no solo por moda)
Contenerizar no es ceremonia. Cada propiedad del contenedor aporta algo concreto:
Proteges la IP. Es el hilo conductor de este repo. Tu lógica se compila a un binario, se empaqueta en una imagen, la imagen se firma y se sube a un ACR privado (private endpoint, sin acceso público), y corre en un sandbox VM-isolated con identidad Entra dedicada. El cliente que consume el agente nunca entra en Azure: habla con un endpoint. Ni con un proxy local cruza esa frontera, porque un proxy local solo ve el tráfico de tu propia máquina — no tu imagen ni el tráfico agente↔modelo, que es servidor-a-servidor dentro de tu tenant.
Libertad de framework sin lock-in. El runtime es agnóstico: Agent Framework, LangGraph, Semantic Kernel, Darp Agents o código propio se despliegan sin reescribir. La imagen no tiene dependencia dura con Foundry (se puede probar con un modelo local); Foundry aporta el hosting, no te secuestra la arquitectura.
Provenance verificable. Un contenedor firmado responde a la pregunta incómoda de la supply chain: ¿el binario que corre es el que generó mi pipeline? Con firma + verificación bloqueante pre-deploy, si la imagen no está firmada por tu cadena de confianza, no se despliega. La identidad del software, atada al artefacto.
Infra gestionada, código tuyo. Escalado, persistencia de estado, observabilidad y ciclo de vida los pone la plataforma; la lógica la pones tú. Te quitas la operación sin ceder el control del comportamiento.
Aislamiento y gobierno. Sandbox por sesión, identidad dedicada, RBAC de mínimo privilegio, red privada. El agente es una unidad gobernable, no un script suelto.
Si tu agente es un asistente conversacional acotado, un prompt-based te sobra. Si tu agente es producto -si su valor está en cómo razona, qué orquesta y qué reglas aplica- entonces esa lógica es IP, y la IP quiere un binario firmado en un registro privado, no un prompt en un portal. Contenerizar es lo que convierte «un agente que funciona» en «un activo que puedes proteger y gobernar».
La Prueba de Concepto (PoC)
El repositorio implementa exactamente esa arquitectura, con Bicep para la infra y un Hosted Agent en C#:
