AI applications are increasingly moving from single agents to systems where multiple specialized agents work together. For example, one agent can handle customer support while another handles billing, document processing, or technical questions.
The Agent2Agent (A2A) protocol provides a standard way for agents to communicate with each other. Microsoft Foundry supports A2A 1.0, allowing Foundry agents to connect with compatible remote agents.
This article explains the basic architecture, authentication considerations, setup concepts, and practical considerations when connecting Microsoft Foundry agents through A2A.
What Is A2A?
A2A allows one agent to communicate with another agent without knowing how the remote agent is internally implemented.
A simple architecture looks like this:
User
|
v
Main Agent
|
+-- A2A --> Billing Agent
|
+-- A2A --> Support Agent
|
+-- A2A --> Document AgentThe main agent decides when another agent is needed and sends a task to that agent.
The remote agent performs its own processing and returns the result.
This creates a clear separation between different agent responsibilities.
Why Use A2A?
Without an agent-to-agent protocol, developers may need to expose every capability as a traditional API or function.
With A2A, an agent can delegate a complete task to another specialized agent.
For example:
Customer Agent
|
v
"Check my refund status"
|
v
Billing Agent
|
v
Refund Information
|
v
Customer AgentThe customer agent does not need to understand the internal implementation of the billing agent.
It only needs to know what capability the billing agent provides and how to communicate with it.
Microsoft Foundry A2A Support
Microsoft Foundry supports A2A 1.0 for agent-to-agent communication. A2A 0.3 is also available for existing integrations that require that version.
For new integrations, A2A 1.0 is the appropriate starting point.
A typical architecture looks like this:
Foundry Agent A
|
| A2A
v
Foundry Agent B
|
+-- Tool
+-- Database
+-- APIAgent B can have its own tools and services without exposing its internal implementation to Agent A.
How the A2A Connection Works
The basic process is:
Create or identify the remote A2A agent.
Configure the required connection.
Configure authentication.
Add the A2A capability to the calling agent.
Allow the calling agent to discover the remote agent.
Send a task to the remote agent.
Process the returned result.
The communication can be represented as:
Calling Agent
|
v
A2A Connection
|
v
Remote Agent
|
v
Remote Tools
|
v
ResultThe remote agent remains responsible for completing the requested task.
Understanding the Agent Card
An A2A agent can publish information describing its capabilities through an agent card.
A simplified example could look like this:
{
"name": "BillingAgent",
"description": "Handles billing and refund requests",
"skills": [
{
"name": "refund-status",
"description": "Checks the status of a refund"
}
]
}The agent card helps the calling agent understand what the remote agent can do.
This is useful because the calling agent does not need to know the remote agent's internal code, database structure, or implementation details.
Connecting a Foundry Agent
In Microsoft Foundry, the remote agent connection contains information required to communicate with the target agent.
The conceptual architecture is:
Calling Agent
|
v
A2A Connection
|
v
Remote Agent EndpointThe calling agent can then use the A2A capability when it needs functionality provided by the remote agent.
The exact SDK configuration can change as the Foundry SDK evolves, so production applications should use APIs compatible with the SDK version being used.
A simplified conceptual example is:
var agent = await agents.CreateAgentAsync(
model: modelDeployment,
name: "SupportAgent",
instructions:
"Help customers with support questions.");
var a2aTool = new A2ATool(
connectionId: "billing-agent-connection");
await agent.EnableToolAsync(a2aTool);The important concept is that the calling agent receives an A2A capability through a configured connection.
Authentication for A2A
Agent-to-agent communication should have clear authentication and authorization rules.
The basic flow is:
Agent A
|
| Identity / Credentials
v
A2A Endpoint
|
v
Agent BDepending on the scenario, Microsoft Foundry supports authentication approaches such as Microsoft Entra ID and other supported authentication mechanisms.
For Azure-based applications, Microsoft Entra authentication can be useful because access can be controlled through identities and permissions.
Authentication should be configured according to the security requirements of the application.
Shared Identity and User Identity
An important design decision is whether the remote agent should see a shared application identity or the identity of the individual user.
With a shared identity:
User A \
User B ---> Main Agent ---> Billing Agent
User C /the billing agent may see the main application or agent identity.
With user identity propagation, the remote agent can make authorization decisions based on the user's identity where the architecture supports it.
This matters when different users have different permissions.
Choosing the A2A Version
When connecting agents, make sure both sides support the same protocol version and configuration.
For new Microsoft Foundry integrations, A2A 1.0 should generally be preferred.
Existing applications may still depend on A2A 0.3.
Before connecting the agents, verify:
Protocol version
Authentication method
Transport support
Endpoint configuration
Agent capabilitiesThis avoids compatibility problems during deployment.
Handling Remote Agent Failures
A remote agent introduces a network boundary.
For example:
Main Agent
|
v
A2A Request
|
+---- Network Delay
|
+---- Remote Processing
|
+---- Remote Tool Calls
|
v
ResponseThe remote agent may be unavailable, slow, or return an error.
The calling application should handle these cases explicitly.
A simple C# pattern is:
try
{
var result = await CallRemoteAgentAsync(request);
return result;
}
catch (TimeoutException)
{
return "The remote agent did not respond in time.";
}In a production application, retry policies should be carefully designed. Unlimited retries can increase latency and create unnecessary load.
Keep Agent Responsibilities Clear
A2A works best when each agent has a clear purpose.
For example:
Support Agent
|
+-- Customer questions
Billing Agent
|
+-- Payments
+-- Refunds
Document Agent
|
+-- Document analysis
+-- Document extractionAvoid creating several agents that perform almost identical tasks.
Clear boundaries make the system easier to understand and troubleshoot.
Avoid Long Agent Chains
A system can quickly become complicated if agents call other agents repeatedly.
For example:
Agent A
|
v
Agent B
|
v
Agent C
|
v
Agent DEvery additional hop can add latency and another possible failure point.
A simpler architecture is usually easier to operate:
+--> Billing Agent
|
Main Agent --+--> Support Agent
|
+--> Document AgentUse additional agent hops only when they provide a clear architectural benefit.
Monitor A2A Calls
A2A requests should be included in application observability.
Useful metrics include:
A2A request count
A2A success rate
A2A failure rate
A2A latency
Timeout count
Retry count
Remote agent nameA trace can look like this:
Agent Run
|
+-- Model Call
|
+-- A2A Billing Agent
| |
| +-- Database Tool
|
+-- Model Call
|
+-- Final ResponseThis makes it easier to determine whether a slow response came from the main agent or a remote agent.
Troubleshooting A2A Connections
Agent Cannot Be Discovered
Check the remote endpoint and agent card configuration.
Authentication Fails
Verify the configured identity, credentials, permissions, and authentication method.
Protocol Version Is Not Supported
Confirm that the calling and remote agents support the selected A2A version.
Request Times Out
Check network connectivity and the execution time of the remote agent.
Unexpected Response
Check the remote agent's capabilities and response handling.
Too Many Retries
Review retry configuration and make sure a temporary failure is not creating a retry loop.
Common Mistakes
Treating a Remote Agent Like a Local Function
A remote agent introduces network latency and additional failure scenarios.
Giving Agents Too Many Responsibilities
An agent with too many unrelated capabilities becomes harder to maintain.
Ignoring Authentication
Every remote agent should have clearly defined access rules.
Creating Long Agent Chains
Multiple agent-to-agent hops increase system complexity.
Not Monitoring A2A Calls
Without telemetry, it becomes difficult to identify which agent caused a slow or failed request.
Best Practices
Define a clear responsibility for every agent.
Use A2A 1.0 when starting a new Foundry integration.
Configure authentication explicitly.
Use least-privilege access where possible.
Set appropriate timeout limits.
Handle remote failures gracefully.
Monitor A2A latency and failure rates.
Keep agent chains as simple as practical.
Test authentication and timeout scenarios before production.
Document the capabilities exposed by each agent.
Advantages
Allows specialized agents to work together.
Provides a standard communication model between compatible agents.
Keeps agent implementations separate.
Makes it possible to reuse specialized agents.
Can simplify larger multi-agent architectures.
Disadvantages
Remote calls introduce additional latency.
Authentication requires additional configuration.
Debugging becomes more complex as the number of agents increases.
Protocol compatibility must be considered.
Long agent chains can become difficult to operate.
Conclusion
Microsoft Foundry's A2A support provides a way for agents to communicate and delegate tasks to other specialized agents.
A typical architecture can look like this:
User
|
v
Main Foundry Agent
|
+-- A2A --> Billing Agent
|
+-- A2A --> Support Agent
|
+-- A2A --> Document AgentThe main agent can focus on coordinating the task while specialized agents handle their own responsibilities.
When building an A2A-based system, focus on clear agent boundaries, authentication, protocol compatibility, error handling, timeouts, and observability.
A well-designed multi-agent system should not simply contain more agents. Each agent should have a clear purpose and provide a capability that makes the overall application easier to build and maintain.
Join the conversation! Your thoughts help the community grow.