Assign each integration a clear boundary

Learning objective

Specify discovery, messaging, tool-catalog, gateway, and knowledge-source integration components.

Core idea

An integration architecture must answer five different questions: which agent exists, how work reaches it, which tools it can select, where calls are governed, and where evidence comes from. A single endpoint can hide these responsibilities, but it doesn’t eliminate them.

Use a component for the boundary it actually enforces. An agent registry isn’t a durable work queue. A tool catalog isn’t document retrieval. A gateway can govern traffic without deciding the business sequence. A knowledge index supplies evidence without granting the caller permission to see every indexed document.

For a senior engineer, the useful output is an integration map with a contract and owner for each boundary. This lesson selects those components; hosting is covered in 1.2.1, identity in 1.2.3, and persistence in 1.2.5.

How it works

Discover agents separately from their identities

Microsoft directs organization-wide agent discovery and management to the Agent 365 registry. Microsoft Entra Agent ID remains the identity foundation. The registry convergence documentation distinguishes the complete inventory, including agents without an Entra agent identity, from the identity-focused view in the Entra admin center.

Use the registry to establish which agents your organization knows about and governs. Don’t assume an identity list is a complete application inventory. Conversely, appearing in a registry isn’t evidence that a caller is authorized to invoke an agent or read its data.

Runtime interoperability needs an endpoint contract as well. Foundry’s A2A integration discovers the target agent card from the configured A2A base path. For a Foundry target, configure the connection target as https://{account}.services.ai.azure.com/api/projects/{project}/agents/{agent}/endpoint/protocols/a2a, rather than supplying an agent-card URL. Foundry resolves the card path and negotiates the protocol version. Enable incoming A2A on the target, grant the calling identity Foundry Agent Consumer or higher on the target project, and use audience https://ai.azure.com; see 1.2.3 for identity assignments.

The GA tool type is a2a, represented by A2ATool or A2AToolboxTool, for A2A 1.0. The a2a_preview tool type targets version 0.3 and remains preview. Foundry targets support text modality and don’t support streaming responses through this integration. These constraints affect the endpoint you choose, even if the remote agent has richer capabilities elsewhere.

Separate direct collaboration from durable messaging

A2A connects agents through a standardized collaboration interface. It doesn’t substitute for the durable messaging requirement of an asynchronous business process.

Azure Service Bus supplies queues and topics with subscriptions. A queue distributes work to competing consumers, with one consumer processing a message. A topic supplies copies to independent subscriptions. Subscription rules use filters and optional actions to select and annotate the messages a subscription receives.

Use a queue for one worker per task, or a topic with separate subscriptions when audit and notification consumers each need the completion event.

Specify what the message carries. A task identifier, authorized tenant context, and reference to governed state often establish a cleaner contract than copying the whole conversation. That is an application design choice, not an automatic Service Bus data-minimization feature. Keep durable delivery and conversation orchestration as separate responsibilities.

Curate tools through Toolbox

Microsoft Foundry Toolbox supplies reusable collections behind an MCP-compatible endpoint. It centralizes authentication and lets consumers discover and invoke tools without building a separate connector for each backend. Its documented integrations include MCP, A2A, and OpenAPI surfaces.

The tool-search capability is preview. It hides tool definitions by default and exposes tool_search to locate relevant tools and call_tool to invoke a discovered tool by name. You can pin critical tools, add organizational discovery context, and auto-pin frequently used tools.

This mechanism matters when a large tool collection competes with conversation and grounding content for model context. Loading fewer definitions can reduce that competition. Tool search is still a selection mechanism: finding a tool doesn’t grant permission to use it. Configure authentication and policy at the tool boundary, not through a descriptive instruction saying the tool is restricted.

A curated tool collection and an organization-wide agent registry solve different discovery problems. Toolbox answers what this consuming agent can call. Agent 365 helps administrators discover and govern agents across the organization.

Put traffic governance at a gateway

Azure API Management’s AI Gateway tier is a distinct public-preview offering. It publishes models and MCP tools through a governed endpoint, applies policies, and emits telemetry. Its overview describes token rate limits, request rate limits, content safety, and IP filters.

For this tier, applications authenticate with a runtime key in the api-key header. Administrators use Microsoft Entra ID for management. A runtime key is gateway-scoped and reaches every model and tool in that gateway. A key per application helps attribution, but doesn’t create per-tool authorization. Don’t design separate sensitive tool boundaries under the assumption that these keys have narrower scope.

The gateway routes model requests by the model field and tool requests by tool name, using configured backend credentials. Keep this distinction from downstream identity and resource authorization. The public-preview tier has no SLA; choose it only when that support boundary fits the workload. Its documented preview regions are East US 2 and Sweden Central, subject to availability.

Retrieve knowledge through an explicit source contract

The Foundry Azure AI Search tool retrieves indexed documents to ground responses with citations. Its Python definition includes AzureAISearchTool, AzureAISearchToolResource, and AISearchIndexResource. The index resource binds project_connection_id, index_name, and query_type to the desired search target.

Use the index tool for an explicitly selected index. For retrieval across multiple configured knowledge sources, Foundry IQ connects an agent to an Azure AI Search knowledge base through {search_endpoint}/knowledgebases/{name}/mcp, using a RemoteTool project connection (preview). The knowledge base orchestrates retrieval; LLM-based query planning and answer synthesis are preview. For supported per-user permission trimming, pass the user token in x-ms-query-source-authorization.

Choose authorization separately. Azure AI Search’s security-filter pattern is generally available for custom identity systems and push-model indexes. It uses a filterable identity field and search.in; a trusted application derives the principal strings and applies the filter on every query. Native POSIX-like ACL/RBAC scopes, SharePoint ACL integration, and Purview sensitivity-label enforcement are preview. Select the mechanism and support status your data source requires; see 1.2.4 for the filtering trust boundary.

Key distinctions and trade-offs

These boundaries should remain explicit in the design:

Architecture / decision scenario

A procurement platform has a sourcing agent, specialist risk agent, audit consumer, and knowledge assistant. Administrators maintain the organization inventory through Agent 365. The risk agent enables incoming A2A; the sourcing identity receives Foundry Agent Consumer on the risk agent’s project. The sourcing agent’s a2a connection uses the A2A base path and https://ai.azure.com audience, accepting the text-only, nonstreaming contract.

Long-running sourcing work enters a Service Bus queue. Completion events go to a topic with separate audit and notification subscriptions. The agents consume a curated Toolbox collection; tool search remains a separately accepted preview dependency.

For a controlled pilot, AI Gateway tier centralizes model and MCP traffic in a supported preview region. Because each runtime key reaches the whole gateway, the team doesn’t place a privileged payment tool behind it while assuming application keys isolate that tool.

The knowledge assistant uses the index tool for one index or the preview Foundry IQ connection for multi-source knowledge-base retrieval. A custom identity system selects GA security filters; native ACL or label enforcement requires accepting preview support. The trusted retrieval service supplies authorized principal context before evidence enters the model.

Common exam traps

• Treating an agent identity inventory as the complete organization registry.
• Using a queue when multiple independent consumers each need an event copy.
• Assuming tool discovery grants tool authorization.
• Confusing AI Gateway tier runtime keys with administrator Entra sign-in.
• Claiming gateway-scoped keys restrict an application to one tool.
• Treating grounded citations as proof of document authorization.

What to remember

Specify discovery, delivery, tool selection, traffic governance, and evidence retrieval separately. Bind each to its actual contract, then check identity scope, protocol support, preview status, and region availability. A shared endpoint simplifies access but doesn’t erase the boundaries behind it.

Knowledge check

References

• Microsoft, Agent Registry convergence with Microsoft Agent 365
• Microsoft, Connect to an A2A agent endpoint from Foundry Agent Service
• Microsoft, Azure Service Bus queues, topics, and subscriptions
• Microsoft, What is Toolbox in Microsoft Foundry?
• Microsoft, AI Gateway tier (preview) overview
• Microsoft, Connect an Azure AI Search index to Foundry agents
• Microsoft, Security filter pattern
• Microsoft, Connect agents to Foundry IQ knowledge bases
• Microsoft, Document-level access control