Microsoft published a walkthrough of enabling an A2A endpoint and agent card for a Foundry-hosted agent, and the design decision at the centre of it is who owns the transport. Your container listens on port 8088 and serves two things: a native POST /invocations and a POST /responses that Foundry uses as the landing zone for agent-to-agent traffic. The A2A client speaks JSON-RPC over HTTPS with an Entra bearer token to Foundry’s data plane, which validates identity, terminates the A2A protocol, and bridges the call to your Responses handler. The instruction that follows is explicit about what not to build: “adding application-level A2A routes to a Foundry-hosted container” is named as a common mistake, because “Foundry already owns that transport layer.”
The mechanism for getting there is two configuration planes that must both agree. The control plane — azure.yaml and azd — declares the agent version, the image, and the protocols the container implements: responses and invocations. The data plane — the agentEndpoint block — declares what callers can reach, and a2a appears only there, because the platform speaks it on your behalf. “A protocol declared on the agent version but omitted from the endpoint is not available to callers. The reverse is also true. Both declarations are required.” The agent card is authored in the same file — a description, a version, and a list of skills with ids, names, descriptions and tags — and Foundry publishes it for discovery. The operational advice is the production kind: keep GET /readiness shallow so a model outage does not recycle a healthy container, and return every failure behind one envelope of detail, correlationId and errorCode.
The catalog’s Azure AI Foundry record holds eight API pages, and the walkthrough sits on top of one of them: the Azure AI Foundry REST API is the control-plane surface those endpoint update commands drive, and the Chat Completions API is the model call the hosted agent makes underneath its verdict. Foundry scores 44.2, developing on the Kin Score, with discoverability at 83.3 and contract governance at 0.0, and Agent Readiness reads 20.7, agent-aware — spec_presence, agentic_access, mcp_server and auth_clarity lit.
agent_card is unlit, and this post is the reason to look at that dimension carefully rather than take it at face value. Every card in our A2A index is served from a host its operator controls, because a card cannot be derived and that is the one agent surface nobody can manufacture for you. Foundry inverts the arrangement: the operator authors the card in YAML and Microsoft serves it from Microsoft’s host, inside the operator’s Entra tenant. That is a real card, under a real identity, published by a platform rather than the party it describes — the same shape as an MCP server whose tools are a platform’s design, and it deserves the same honesty about who built the door. delegated_identity is also dark, on a walkthrough whose every request carries an Entra token for a specific caller. Both are declarations Foundry could make; this article is most of the text.