Multi-Agent Architectures on Azure: Connected Agents, MCP, and Hosted Agents

There’s a pattern I keep seeing in the wild: an organisation builds a single AI agent, loads it up with a dozen tools and a page of instructions, and wonders why it’s doing everything badly. I call it the mega-agent anti-pattern. One memorable case was a contract review system that was supposed to summarise clauses, check compliance, compare drafts, and generate a risk report, all in one agent. The instructions were a mile long, the tool list was unwieldy, and debugging was a nightmare. The fix? Stop trying to make one agent do everything and start thinking about multi-agent architectures.

The good news is that Microsoft Foundry Agent Service now gives us three distinct patterns for building multi-agent systems, each suited to different levels of complexity and control. In this post, I’ll walk through all three: Connected Agents, the MCP tool, and Hosted Agents. I’ll also touch on the newer tools that make agents more capable (Deep Research, Browser Automation, Computer Use) and compare the whole lot against Copilot Studio’s multi-agent orchestration. Let’s dive in!

Pattern 1: Connected Agents (The Easy Button)

First cab off the rank, Connected Agents shipped at GA in May 2025 and, in my opinion, they’re the simplest way to build a multi-agent system on Azure today.

The concept is pretty straight forward. You have a primary agent that acts as the coordinator. When it receives a user request, it uses natural language reasoning to decide which specialist sub-agent should handle the task, then delegates accordingly. No custom orchestration framework, no hand-coded routing logic. The primary agent just figures it out.

Here’s what I love about this pattern:

  • No external orchestrator required. The primary agent routes tasks based on its instructions and the descriptions you give each connected agent.
  • Easy to extend. Need to add a translation agent? Just create it and connect it. You don’t have to modify the primary agent’s code.
  • Reusable agents. Each specialist agent can be connected to multiple primary agents across different workflows.

Going back to my contract review example, you’d create a primary “Contract Orchestrator” agent, then connect specialist agents for clause summarisation, compliance validation, and document comparison. Each one gets its own tools and focused instructions.

Here’s how you set it up in C#:

using Azure.AI.Projects;
using Azure.AI.Agents;
using Azure.Identity;

AIProjectClient projectClient = new(
    endpoint: new Uri("https://your-resource.ai.azure.com/api/projects/your-project"),
    credential: new DefaultAzureCredential());

// Create a specialist agent
AgentCreationOptions clauseAgentOptions = new("gpt-4.1")
{
    Name = "clause_summariser",
    Instructions =
        "Extract and summarise key contract clauses including " +
        "Termination, Payment Terms, and Indemnity. " +
        "Use plain language suitable for a non-legal audience."
};

Agent clauseAgent = await projectClient.Agents.CreateAgentAsync(clauseAgentOptions);

// Wire it up as a connected agent tool
ConnectedAgentToolDefinition connectedTool = new(
    new ConnectedAgentDetails(clauseAgent.Id, clauseAgent.Name)
    {
        Description = "Summarises contract clauses in plain English"
    });

// Create the primary orchestrator agent
AgentCreationOptions orchestratorOptions = new("gpt-4.1")
{
    Name = "contract_orchestrator",
    Instructions =
        "You are a contract review assistant. Route clause summarisation " +
        "tasks to clause_summariser. Route compliance checks to the " +
        "compliance agent.",
    Tools = { connectedTool }
};

Agent orchestrator = await projectClient.Agents.CreateAgentAsync(orchestratorOptions);

Note: Connected agents have a maximum depth of 2. Your primary agent can have multiple sub-agents as siblings, but those sub-agents can’t have their own sub-agents. If you need deeper nesting, you’ll want to look at Hosted Agents (Pattern 3 below).

Be warned: Connected agents currently can’t call local functions using function calling. If your sub-agents need custom functions, use OpenAPI tools or Azure Functions instead.

Pattern 2: MCP Tool Integration (The Interoperability Play)

The Model Context Protocol (MCP) tool landed in June 2025 and it’s a different beast entirely. Rather than coordinating multiple Foundry agents, MCP lets your agent connect to any remote server that implements the MCP open standard. This is huge for interoperability.

Think of it this way: Connected Agents keep everything inside the Foundry ecosystem. MCP opens the door to the entire universe of MCP-compatible tools, whether they’re hosted on GitHub, run on your own infrastructure, or come from third-party providers. Microsoft’s own Foundry MCP Server is cloud-hosted with Entra authentication baked in, so you can connect from VS Code, Visual Studio, or the Foundry portal with zero local process management.

Here’s a practical example connecting to the GitHub MCP server:

using Azure.AI.Projects;
using Azure.Identity;

string projectEndpoint = "https://your-resource.ai.azure.com/api/projects/your-project";

AIProjectClient projectClient = new(
    endpoint: new Uri(projectEndpoint),
    credential: new DefaultAzureCredential());

// Define an MCP tool pointing at GitHub's MCP server
var mcpTool = new McpToolDefinition(
    serverLabel: "github",
    serverUrl: new Uri("https://api.githubcopilot.com/mcp"),
    requireApproval: ToolApprovalMode.Always)
{
    ProjectConnectionId = "my-github-connection"
};

// Create an agent that can use GitHub via MCP
var agentDefinition = new PromptAgentDefinition("gpt-4.1")
{
    Instructions = "You are a helpful assistant that uses GitHub MCP tools to answer questions about repositories.",
    Tools = { mcpTool }
};

AgentVersion agent = await projectClient.Agents.CreateAgentVersionAsync(
    "repo-assistant", options: new(agentDefinition));

A few important considerations with MCP:

  • Approval workflow. By default, every MCP tool call requires developer approval (ToolApprovalMode.Always). You can set it to ToolApprovalMode.Never for trusted servers, or provide a list of specific tools that skip approval. I’d recommend keeping approval on until you’ve thoroughly tested what the server returns.
  • Custom headers. You can pass authentication tokens and other headers per-run via tool resources. Headers aren’t persisted, so credentials stay scoped to individual runs.
  • Self-hosting local MCP servers. The Agent Service only accepts remote endpoints. If you have a local MCP server, you’ll need to host it on Azure Container Apps or Azure Functions first.
  • 50-second timeout. Non-streaming MCP tool calls time out at 50 seconds. If your server needs longer, optimise the server-side logic or break operations into smaller steps.

For a deeper dive into the security considerations of MCP, I’d recommend reading Microsoft’s Understanding and mitigating security risks in MCP implementations. It’s well worth the read, especially if you’re connecting to third-party servers.

Pattern 3: Hosted Agents (Bring Your Own Framework)

If Connected Agents are the easy button and MCP is the interoperability play, then Hosted Agents are the “I need full control” option. Currently in preview, Hosted Agents let you deploy your own containerised agent code (built with LangGraph, Microsoft Agent Framework, or completely custom code) directly to the Foundry Agent Service.

This is the pattern for teams that have already invested in a framework, need deeper orchestration than Connected Agents provide, or want to run complex multi-agent workflows with custom state management, parallel execution, and error recovery.

What Foundry handles for you:

  • Containerisation and deployment via Azure Container Registry
  • Autoscaling with configurable replica sizes (0.25 to 4 vCPUs, 0.5 to 8 GiB memory)
  • Identity management with project managed identity (or dedicated agent identity after publishing)
  • Observability with OpenTelemetry integration
  • Conversation orchestration and state management

The deployment workflow is pretty slick using the Azure Developer CLI:

# Install the agent extension
azd ext install azure.ai.agents

# Scaffold a new hosted agent project
azd ai agent init

# Provision infrastructure and deploy
azd up

# Test it
azd ai agent invoke "What is Microsoft Foundry?"

# Clean up when done
azd down

The framework support matrix currently looks like this:

Framework Python C#
Microsoft Agent Framework Yes Yes
LangGraph Yes No
Custom code Yes Yes

Note: Hosted Agents are in preview and don’t yet support private networking for network-isolated Foundry resources. Keep that in mind for production workloads with strict network isolation requirements.

The Supporting Cast: Deep Research, Browser Automation, and Computer Use

Beyond the three core multi-agent patterns, the Agent Service has picked up some seriously capable tools over the past few months that make individual agents much more powerful.

Deep Research (June 2025) uses the o3-deep-research model with Bing Search grounding to perform multi-step, autonomous web research. It plans a research strategy, gathers sources, analyses findings, and produces a structured, fully cited report. Every insight is traceable and source-backed. It’s currently available in West US and Norway East only, and requires a gpt-4o deployment in the same region for scope clarification. As covered by Visual Studio Magazine, this is genuinely impressive for automating research-heavy tasks.

Browser Automation (August 2025, preview) lets agents interact with real browsers via natural language prompts. Powered by Microsoft Playwright Workspaces, it runs in an isolated, sandboxed session within your Azure subscription. Great for automating bookings, form submissions, and product discovery. Think of it as RPA’s cooler, AI-powered cousin.

Computer Use (September 2025, preview) goes even further, enabling full desktop UI interaction. While Browser Automation works with web content via DOM parsing, Computer Use works with pixel-level screen interaction for applications that don’t have APIs or web interfaces.

Connected Agents vs. Hosted Agents vs. Copilot Studio: When to Use What?

This is the question I get asked the most, so here’s my decision framework.

Criteria Connected Agents MCP Tool Hosted Agents Copilot Studio
Complexity Low Medium High Low
Orchestration Natural language routing Tool-level integration Full custom control Sequential (generative)
Parallel execution No (sequential delegation) Per-tool Yes (framework-dependent) No (strictly sequential)
Framework lock-in Foundry native Open standard Bring your own Microsoft low-code
Max agent depth 2 levels N/A Unlimited Not specified
Best for Focused specialist delegation External tool ecosystem Complex workflows, existing frameworks M365 integration, citizen developers

As Ragnar Heil’s excellent comparison points out, the execution model is the critical difference between Foundry and Copilot Studio. Copilot Studio calls agents strictly in sequence, which means cumulative latency scales linearly. With 5 to 10 agents, that sequential execution can render synchronous applications unusable. Foundry’s Connected Agents and Hosted Agents support concurrent fan-out patterns that drastically cut response times.

In my opinion, the right answer for most organisations is: start with Connected Agents. If you hit the depth limit, need custom state management, or have existing LangGraph/Semantic Kernel code, graduate to Hosted Agents. Use MCP when you need to connect to external ecosystems. And use Copilot Studio when your primary interface is Microsoft 365 and your builders are citizen developers rather than pro-devs.

For more detail on how these platforms complement each other, the Microsoft Tech Community’s comparison post is a solid read.

Wrapping Up

Multi-agent architectures on Azure have matured significantly in 2025. Connected Agents give you native multi-agent coordination with minimal code. MCP opens the door to the broader tool ecosystem with an open standard. Hosted Agents let you bring your own framework and deploy it as a managed service. And the new tools (Deep Research, Browser Automation, Computer Use) make individual agents dramatically more capable.

As always, feel free to reach out with any questions or comments!

Until next time, stay cloudy!

Unknown's avatar

Published by James Westall

I'm a State Manager for Arinco, with a background specializing in securing Azure cloud and Artificial Intelligence. These days I spend most of my time exploring client problems and buried in pptx decks. I'm passionate about AI, cyber security, cloud native technology and DevOps practices. Hate buzzwords, and love a good rant…

Leave a Comment