Incoming A2A on hosted agents returns HOSTED_AGENT_NOT_SUPPORTED: please support it, or add a passthrough mode

[iago (izamoch)]

Technical Feedback

Describe the precise feedback.
A hosted agent (Agent Framework, Responses protocol 2.0.0) with incoming A2A enabled on its endpoint serves its agent card (agentCard/v1.0 returns 200), but every A2A message is rejected by the gateway before reaching the container:

{"jsonrpc":"2.0","id":"1","error":{"code":-32099,
 "message":"The requested A2A operation is not supported for this hosted-agent target.",
 "data":[{"@type":"type.googleapis.com/google.rpc.ErrorInfo","reason":"HOSTED_AGENT_NOT_SUPPORTED",
 "domain":"ai.azure.com","metadata":{"detail":"... Use a prompt agent as the A2A target."}}]}}

Reproduced on 2026-10-07 in Sweden Central. Same error in every case, and no session is ever created in the container:

• SendMessage (v1.0) and message/send (v0.3), using the A2A-Version header, the a2a-version query parameter and card-based negotiation.
• A freshly deployed version, with A2A and the card applied afterwards (REST PATCH and azd ai agent endpoint update).
• The version declaring a2a as a container protocol, with the container serving A2A JSON-RPC itself.
• A brand-new agent that never had A2A configured.
• The responses + invocations setup from the Foundry blog post of 2026-08-24 ("Enabling A2A endpoint and Agent Card for a Hosted Agent"), with all three protocols on the endpoint.

Docs and samples are inconsistent:

• "Enable incoming A2A on a Foundry agent" listed hosted agents as supported until MicrosoftDocs/azure-ai-docs@d0b87d1 (2026-08-26), which removed them without a changelog note.
• The sample foundry-samples/samples/python/hosted-agents/agent-framework/a2a/01-delegation still exposes a hosted executor over incoming A2A.

There is no endpoint setting to change this: A2AProtocolConfiguration has no fields.

Versions: azure-ai-projects 2.8.0, azure-ai-agentserver-core 2.2.0, agent-framework-foundry-hosting 1.0.0b261002, azd 1.35.0.

Desired Outcome

We need to expose a hosted agent (custom orchestration code, one model) to an external A2A v1.0 JSON-RPC client, keeping what hosted agents provide: sessions, agent identity, guardrails (rai_config), tracing and versioning.

Any of these would unblock us:

1. Re-enable incoming A2A for hosted agents that implement the Responses protocol.
2. Add a passthrough mode, for example a flag in A2AProtocolConfiguration: when the version declares a2a as a container protocol, the gateway forwards A2A traffic to the container and lets it handle tasks and context.
3. At least, document the limitation explicitly (the reason, and whether it is temporary or permanent) and update the a2a/01-delegation sample.

Current Workaround

Describe the current workaround.
None that keeps everything inside Foundry without trade-offs:

• Prompt agent in front of the hosted agent (what the error suggests): two models in series, which doubles cost and latency. Not acceptable for our workload.
• Rewriting the orchestrator as a prompt agent and moving the non-model work to a hosted agent on the Invocations protocol, called through OpenAPI tools: one model, but we lose our Agent Framework orchestration, and per-user isolation depends on the model passing a session id back.
• Serving A2A JSON-RPC through the Invocations protocol of the hosted agent: it reaches the container, but it needs a non-standard URL and a client-supplied agent_session_id, and the agent card can't be published (GET subpaths are blocked by the gateway).

We are moving to a thin A2A adapter outside Foundry (Azure Container Apps) that calls the hosted agent's Responses endpoint. It works, but it adds infrastructure that a passthrough mode would make unnecessary.