Choose protocols by the work exchanged

Learning objective

Select communication mechanisms for agents, tools, and services (A2A, MCP, APIs, and events).

Core idea

Choose communication from the contract between participants. An agent delegates work to another agent, invokes a tool operation, calls a service with a defined API, or publishes a fact for independent consumers. These exchanges can coexist in one architecture; a single protocol need not carry every interaction.

Agent2Agent (A2A) provides an agent interoperability contract. Model Context Protocol (MCP) provides a tool integration contract. Direct APIs preserve service-specific request and response semantics. Events decouple producers from consumers in time and can distribute a fact to multiple subscribers. The deciding question is what the recipient owns and how the sender learns the outcome, not whether both endpoints happen to use HTTP.

See 1.2.2 for the components that provide discovery, tool catalogs, gateways, and durable messaging. This lesson selects the exchange those components must support.

How it works

Delegate agent work through A2A

Microsoft Foundry Agent Service calls remote agents through its A2A integration; see 1.2.2 for a2a versus a2a_preview, protocol versions, SDK types, endpoint configuration, and target modality and streaming constraints.

The remote agent processes the request and returns a response. The calling Foundry agent uses that response and continues managing its conversation. This fits a specialist that owns an internal process and returns an outcome without exposing every internal tool to the orchestrator. The orchestrator still validates the specialist’s result against its delegation contract; see 1.1.3.

For a Foundry agent target, enable incoming A2A and grant the calling identity the Foundry Agent Consumer role or higher on the target project. An interoperable protocol does not bypass the target’s access requirements; permission to call the specialist remains separate from the specialist’s authority to perform its internal operations.

Check the target implementation before selecting this route. If the caller needs a modality or response pattern the target does not support, select another supported exchange rather than assuming the protocol name guarantees it. Record the required result format, completion condition, and error outcome in the delegation contract.

Invoke tools through MCP

Use MCP when an agent needs exposed tool operations rather than delegation to a separately responsible specialist. A Foundry MCP definition names a remote endpoint with server_url and distinguishes it with server_label. allowed_tools restricts the exposed operations; authorization and token audiences are covered in 1.1.7.

Foundry Agent Service accepts remote MCP endpoints. A local MCP server must be hosted so it provides a remote endpoint before this managed runtime can use it. That constraint belongs to Foundry Agent Service; it is not a claim that every MCP client requires a remote server.

Specify how the tool returns results and failures, and whether execution can exceed an interactive request. Foundry documents long-running MCP operations through MCP tasks as preview and requires a harness that supports those tasks. Do not design a production guarantee from ordinary MCP connectivity alone. A successful short tool call does not establish long-running task support.

Preserve service semantics through direct APIs

A direct API fits an established service operation with explicit inputs, authorization, and business results. You do not need to represent a deterministic account lookup as a remote autonomous agent. A custom function tool can be the model-facing adapter while application code calls the existing service API.

For Azure OpenAI function calling through Chat Completions, the application sends function definitions in tools. The model returns a proposed function call, the application calls its API or function, and the application supplies the tool result in a subsequent model request. The model does not execute your private API merely because its schema is present. See 0.4 for the control loop.

This route gives the application ownership of argument validation, service timeouts, response mapping, and execution evidence. Its cost is an adapter that you maintain. Use MCP when a reusable tool integration contract earns that cost; use A2A when the receiving agent owns delegated work. A direct REST service can sit behind either adapter without changing its own business contract.

Distinguish events from contracted messages

Microsoft distinguishes an event, a lightweight notification whose publisher does not prescribe how recipients handle it, from a message, which carries a publisher-consumer contract. Start with that distinction before selecting an asynchronous service. A status change that independent consumers can interpret is different from a financial instruction that must produce a tracked business outcome.

Azure Event Grid handles discrete events and reactive routing. Azure Event Hubs handles event streams, such as telemetry for analysis. Azure Service Bus handles high-value messages, including order processing and workflows. Microsoft’s comparison lists duplicate detection and transactions for Service Bus, but neither for Event Grid nor Event Hubs. Choose the service from the delivery and processing requirements, not because all three can carry data asynchronously.

For Service Bus queue-versus-topic selection and subscription filters, see 1.2.2. Here the deciding question is whether the interaction is an independent notification or a business message requiring a processing contract.

Choose delivery semantics explicitly. Service Bus Receive and Delete can lose work if the consumer crashes after receipt. Peek Lock separates receipt from completion; an abandoned message or expired lock becomes available again. A crash after applying an effect but before completing the message can cause redelivery. Name Service Bus duplicate detection in the design when duplicate messages cannot be tolerated, and add application-side duplicate checks for processing. Broker duplicate detection does not by itself make a non-idempotent downstream effect safe after a processing crash.

Neither queue acceptance nor event publication proves the downstream business action completed. Define a separate outcome record or completion event, with application identifiers that correlate it to the original job. Those identifiers and business deduplication rules are application contracts, not implicit guarantees of A2A or MCP.

Key distinctions and trade-offs

The following choices express different recipient responsibilities:

Request/response simplifies immediate error handling but couples the sender to the recipient’s availability. Durable messages absorb bursts and disconnects, but require visible pending states and independent completion tracking. Interoperability reduces custom integration work; it does not remove permission checks, business validation, or outcome ownership.

Architecture / decision scenario

An order assistant needs inventory lookup, a specialist shipping estimate, payment authorization, and independent audit and notification reactions. Inventory is exposed through remote MCP operations. Shipping belongs to another agent, so the orchestrator chooses A2A and validates the returned estimate. It enables incoming A2A on the Foundry target and grants its calling identity Foundry Agent Consumer; endpoint and capability selection follow 1.2.2.

Payment uses an existing API through an application-executed function tool. Its explicit authorization result, rather than generated prose, decides whether payment succeeded. For a lightweight order-status notification with independent reactions, choose Event Grid. For a high-value fulfillment message whose recipients must satisfy a business processing contract, choose Service Bus with duplicate detection and the queue or topic pattern from 1.2.2. Continuous agent telemetry for stream analysis belongs in Event Hubs rather than that fulfillment channel.

The fulfillment consumer uses Peek Lock, Service Bus duplicate detection, and application-side duplicate checks around business processing. It does not infer a duplicate-free external effect from broker support alone. The orchestrator distinguishes a completed payment from an accepted fulfillment message. If shipping instead requires a long-running interaction, the team evaluates supported asynchronous execution rather than silently assuming MCP tasks are a GA replacement for A2A.

Common exam traps

• Selecting A2A because a deterministic service is called by an agent.
• Assuming Foundry A2A targets stream or accept every modality.
• Treating a2a and a2a_preview as the same version and status.
• Assuming a function definition executes an API without application code.
• Treating Event Grid notifications, Event Hubs streams, and Service Bus business messages as interchangeable.
• Treating event acceptance as completed work or Peek Lock as duplicate-free execution.

What to remember

Match the protocol to the recipient’s responsibility and the outcome contract. Use A2A for agent delegation, MCP for tool integration, APIs for explicit service operations, and durable events for independent reactions. Check implementation support and delivery semantics before promising latency, streaming, or completed effects.

Knowledge check

References

• Microsoft, Connect to an A2A agent endpoint from Foundry Agent Service
• Microsoft, Connect agents to MCP server endpoints
• Microsoft, How to use function calling with Azure OpenAI
• Microsoft, Compare messaging services
• Microsoft, Azure Service Bus queues, topics, and subscriptions