Foundry-to-Foundry A2A: child agent writes a SendMessage payload as text instead of calling its configured agent

Question

Foundry-to-Foundry A2A: child agent writes a SendMessage payload as text instead of calling its configured agent

Onni Kyster Anastacio 0

I'm testing a small native hierarchy of prompt agents in Microsoft Foundry: a coordinator calls two managers, and one manager should delegate to another agent through A2A.

The coordinator, using gpt-4.1-mini, successfully invoked both managers. The manager using gpt-5-mini then returned text saying "Now sending", followed by a SendMessage payload for its configured downstream agent. It did not return the requested work.

What the saved configuration and traces show: • The manager has an A2A 1.0 tool targeting the downstream Foundry agent, with an authenticated project connection configured. • Its runtime input includes its saved instructions to delegate through that connection and not treat a written handoff as sent. • Its recorded model output contains only assistant text, with finish_reason "stop". • Its invocation span lists generic metadata: [{"type":"remote_tool","name":"remote_tool"}]. I can't see the expanded downstream SendMessage schema. • Correlated traces show the coordinator's successful calls to both managers, but no downstream tool-execution or agent-invocation span in the returned set. No 401/403, timeout or tool-depth error was recorded. • Attempts to retrieve child response history returned 404 through both project and agent-specific Responses endpoints, although the child invocation/model spans exist.

There was also a separate handoff problem: the coordinator shortened the original request and omitted constraints, then described unfinished work as pending after its root response had completed. I don't consider that evidence of active background work.

My questions:

Is this native Foundry-to-Foundry multi-hop A2A pattern supported?
How can I inspect the expanded tool schema and tool_choice passed to the child model, rather than generic remote_tool metadata?
Is there a read-only way to distinguish discovery or authorization failure before schema exposure from the model choosing text despite receiving a usable tool?
How should child response history be retrieved when traces contain response IDs but both Responses read routes return 404?

I'm not claiming that nesting is unsupported or that permissions caused this. I'd like to understand the calling interface from existing evidence before running another paid reproduction or changing the configuration.

0 comments

1 answer

Your answer

Answer 1

Hello Onni Kyster Anastacio,

Greetings! Thanks for raising this question in the Q&A forum.

From the evidence you collected, the manager's model returned plain text with finish_reason: "stop" and no tool-execution span exists downstream. That points to the model choosing to write the handoff as text, or to the A2A tool not being exposed to the model in a usable form. Those two cases look the same in the current traces. I could not find documentation that publishes the expanded tool schema in traces, or a nesting depth limit, so please treat the points below as the documented behavior plus a way to isolate the cause.

Supported pattern (your question 1). Calling another Foundry agent through the A2A tool is a documented pattern. Use the generally available a2a tool type (A2A protocol 1.0) for new work, since a2a_preview (0.3) stays preview. For a Foundry agent target, the connection target must be the target's A2A base path https://{account}.services.ai.azure.com/api/projects/{project}/agents/{agent}/endpoint/protocols/a2a with audience https://ai.azure.com, incoming A2A must be enabled on the target, and the calling identity needs the Foundry Agent Consumer role or higher on the target project. The docs do not explicitly describe or limit coordinator to manager to child chains, so a multi-hop chain is not explicitly confirmed either way. Also confirm the connection auth type fits who is calling. App-only calls to a Foundry agent should use agentic-identity with audience https://ai.azure.com, while user-entra-token depends on an incoming user context that may not exist when the manager is itself invoked by another agent.

Separate model behavior from tool exposure (your questions 2 and 3). The docs do not show a way to view the expanded tool schema sent to the model. A practical read-only check is to call the manager directly, not through the coordinator, with tool_choice set to required, which is what the official samples do:

response = openai.responses.create(
    tool_choice="required",
    input="<the exact request the coordinator sent>",
    extra_body={"agent_reference": {"name": "<manager-agent>", "type": "agent_reference"}},
)
print(response.output)

If the A2A tool call appears (or you get a clear error), the tool is exposed and the earlier text was the model's choice. If it still returns plain text or fails, the problem is on the tool or connection side. The coordinator's call cannot force the manager's tool_choice, so this direct test is the cleanest way to split the two cases. As a second check, temporarily switch the manager model to the one used in the docs samples and compare, since your coordinator on gpt-4.1-mini delegated successfully.

Check discovery and authorization without running the model. Confirm the target agent card is reachable with the same identity the connection uses. The docs say Foundry resolves the default agent card path for you, and the "Verify the agent card" section of the incoming A2A article shows the exact URL to use. Example:

TOKEN=$(az account get-access-token --scope https://ai.azure.com/.default --query accessToken -o tsv)
curl -H "Authorization: Bearer $TOKEN" "https://<account>.services.ai.azure.com/api/projects/<project>/agents/<agent>/endpoint/protocols/a2a/.well-known/agent-card.json"

A valid card means the endpoint is enabled and reachable for that identity. A 401 or 403 means a role or audience problem. Also check the Foundry Agent Consumer role assignment and the connection's target and audience in the portal under Tools.

Tighten the manager instructions and handoff. Since the model wrote a "Now sending" message, add an explicit rule that the model must call the A2A tool before answering and must pass the full original request with all constraints. Foundry also recommends reviewing tool descriptions and instructions in the tool best practices article. For the coordinator losing constraints, pass the original request verbatim in the delegation instruction instead of letting the model summarize it.

Child response history returning 404 (your question 4). I could not find a documented route that returns history for a response ID produced by a nested tool call, so I can't confirm the cause of the 404. For Foundry agent targets, the A2A tasks and contexts are retained for 60 days from the most recent write, so ask whether the child run is recorded as an A2A task or context instead of a Responses record. For inspection today, rely on the Foundry portal Traces view and your Application Insights data using the trace and response IDs you already have.

Consider a deterministic design if the hierarchy must be reliable. If you need guaranteed delegation, the docs point to Workflows for orchestrating multiple Foundry agents declaratively. That removes the dependency on the model choosing to call a tool.

Open a support request if steps 2 and 3 show the tool is exposed but not executed. In the Azure portal choose Help + support > Create a support request and include the project endpoint, agent names and versions, the response IDs, trace IDs, timestamps, and the 404 responses. This is the right path to get the expanded schema and the missing downstream span checked on the service side.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.