Transforming Solo Agents to Collaborative Teams: Choosing Multi-Agent Patterns in Microsoft Foundry

Creating an AI agent has become simpler, but developing a system where the agent can determine **who should act, what context to provide, when to signal task completion, and where human approval is needed** presents a greater challenge.

This is where multi-agent orchestration comes into play, and the term is intentionally borrowed from music. An orchestra isn’t just about cramming as many instruments as possible onto a stage. It consists of sections that each play their own part, adhering to one score and following a single conductor who directs the performance without playing an instrument, defining when the piece is complete. Keep this analogy in mind; every example in this post will reference it. The agents represent the sections, the workflow is the score, and the amber seal signifies the conductor.

Microsoft’s Foundry Agent Service acts as the managed platform that provides the necessary models, tools, identity management, runtime operations, monitoring, evaluations, and publishing capabilities. The Microsoft Agent Framework outlines the orchestration strategies to facilitate the collaboration of specialised agents on this platform.

The aim isn’t to create the largest number of agents possible but to achieve the most straightforward architecture that accomplishes tasks consistently, securely, and cost-effectively.

Foundry: The Platform Over Patterns

It’s essential to distinguish between the two. Foundry provides the operational framework, which includes:

• Models sourced from the Foundry catalog


• Prompt-based and hosted agents operating on a managed runtime


• Access to tools, including MCP servers and custom functions


• Identity verification via Microsoft Entra and role-based access control


• Monitoring, metrics, evaluations, and Application Insights


• Version control and publishing of agents

The orchestration strategy outlines how agents will allocate, route, review, and finalise tasks. The Agent Framework proposes five different patterns: sequential, concurrent, handoff, group chat, and Magentic. Additionally, you can create custom workflows by utilising executors, edges, routing rules, and events.

Begin with One Agent

Using multiple agents isn’t always the standard setup. Microsoft suggests starting with the least complex solution that adequately meets requirements. Often, a direct model call is sufficient for a specific transformation. For most enterprise tasks within a single domain, a solitary agent equipped with the necessary tools serves as the default configuration. Orchestration becomes essential when tasks span multiple domains, require parallel specialisation, need separate security measures, or when a single agent becomes overloaded with an excessive amount of instructions, tools, and information sources.

It’s much easier to justify having a distinct agent when it:

• Utilises a specific set of tools or knowledge


• Demands a distinct security boundary


• Has a reusable function or responsibility


• Needs independent evaluation


• Is managed by a different team

If these conditions don’t apply, adding another agent only incurs additional coordination costs without delivering any real value.

1. Sequential Orchestration

In sequential orchestration, work is handed off between agents in a predetermined sequence, with each agent processing the output from the preceding one. Microsoft refers to this as a pipeline or prompt chaining, indicating a linear delegation process, where the pathway is fixed and not subject to agent discretion.

Utilize this method when:

• There are clear dependencies between stages that must be executed in a specific order


• Each phase builds upon the last, improving its output


• The routing requires predictability


• A human approval checkpoint is necessary at a specified juncture

For instance, in handling a municipal records request, one agent might classify the request, another parses search criteria, a third checks compliance with policies, and a final agent drafts a response for human review. The workflow enforces these stages while allowing agents to operate with defined parameters.

2. Concurrent Orchestration

In concurrent orchestration, the same request is dispatched to multiple agents at the same time. Each agent works independently before their results are gathered, compared, or combined later. This method is often referred to as fan-out/fan-in, scatter-gather, or map-reduce, where the merging can be done using predefined rules, voting mechanisms, weighted combinations, or model-informed synthesis.

Use this pattern when:

• Tasks can be addressed independently and in parallel


• Multiple expert insights are advantageous


• A clear conflict resolution strategy is established


• Agents do not need to update shared mutable states

In public sector contexts, concurrent agents should focus on returning structured insights rather than each one contributing directly to the authoritative record. A coordinating workflow should validate and compile these inputs before they are committed to a system like Dataverse.

3. Handoff Orchestration

In handoff orchestration, an active agent routes the control of a task to a specialist once the relevant domain is identified. This process is often called routing, triage, transfer, or delegation. Only one specialist should manage the request at any given time, with a clear pathway set up for re-engaging staff if necessary.

A successful handoff must include vital details such as the reason for transition, the authorized context, who owns the subsequent steps, the delivery of the final response, contingencies if no specialist accepts the request, and escalation protocols. While traditionally reliant on connected agents, Microsoft plans to phase these out by March 31, 2027, in favour of the Agent Service and contemporary workflow tools.

4. Group Chat Orchestration

In group chat orchestration, several agents engage in an ongoing dialogue with a chat manager coordinating the conversation to reach a resolution. This resembles a roundtable discussion and is ideal for maker-checker reviews.

The process typically involves a maker creating an artifact, checkers assessing it against predefined criteria, the maker making revisions, and concluding with either an approval or a limited number of iterations to avoid loops. Any unresolved matters are escalated to a human for resolution. Microsoft advises setting clear criteria, defining iteration limits, and implementing fallback plans, noting that complexity increases with the presence of more than three agents.

In local government, this system can facilitate review and advice processes, where agents identify policy conflicts, accessibility issues, or missing references, ultimately allowing an authorized staff member to make the final call.

5. Magentic Orchestration

Magentic orchestration is suited for unstructured tasks where the sequence of events can’t be predetermined. A managerial agent formulates a plan, assigns specialists, oversees progress, identifies stalls, and adapts the plan as needed. This approach is also known as dynamic, adaptive, or task-ledger orchestration.

The Magentic-One system from Microsoft Research maintains a Task Ledger for facts and plans, along with a Progress Ledger for assignments and statuses, adjusting plans as needed when progress is delayed. However, it’s vital not to default to this system simply because it’s the most autonomous. It is not the right tool for straightforward, time-sensitive, or well-defined tasks, as its adaptive planning can make costs and behaviours more challenging to predict.

Why Hybrid Approaches Often Prevail

Many local government operations incorporate a blend of deterministic and nondeterministic tasks. For instance, during a permit review, agents might need to interpret documents, extract conditions, navigate policy, and clarify their findings. This process also includes compulsory review stages, approval authorities, notification duties, and records maintenance that should never rely solely on agent discretion.

• Foundry agents handle interpretation, classification, research, and recommendations


• The Agent Framework manages the reasoning process


• MCP or controlled tools present confined data and actions


• Dataverse maintains the authoritative state of the processes


• Power Automate or Logic Apps facilitate deterministic integration operations


• Human reviewers make significant decisions


• Application Insights and Foundry evaluations monitor the entire process

At MGP Inc., we generally advocate this hybrid architecture for local government clients embracing Microsoft Foundry. Agents conduct limited reasoning, deterministic workflows govern processes, authoritative states remain within controlled systems, and staff retain approval authority over key decisions.

This architectural approach aligns with Microsoft’s recommendations regarding least privilege access, enduring state management, human involvement, security trimming, output verification, and comprehensive observability.

Governance: Integrated, Not Tacked On

Introducing additional agents amplifies the number of model calls, tool interactions, context transfers, and potential points of failure. A well-structured Foundry architecture should encompass four critical areas.

Identity and Authorisation

Each agent is granted only the models, knowledge, and tools necessary for their responsibilities. No connected or hosted agent should circumvent the authorisation limits set by the requesting user.

State and Context

Avoid routing full conversation histories by default; only share what’s critically needed for the next stage. Externalise long-running states to ensure seamless execution rather than replaying previous steps. Regularly compile and prune as transitions accumulate.

Reliability

Transitions must incorporate timeouts, retries, output verifications, checkpoints, circuit breakers, and graceful degradation measures. A flawed result from one agent must not become a trusted input for another.

Observability and Evaluation

A single trace should connect the dots, linking the user request, parent and child agents, model calls, tool calls, approval checkpoints, and final outcomes. Cost considerations should be included in this view, as each added agent entails additional model calls that contribute to expenses.

Final Thoughts

The optimal Foundry architecture seldom involves the highest number of agents. Instead, it leverages the fewest agents necessary, assigns each a unique responsibility within limited authority, aligns the pattern to the work involved, and envelops deterministic controls around any actions tied to people, records, finances, or public services.

Each orchestration pattern arranges the sections in unique ways. Sequential orchestration sequences them linearly, while concurrent allows them to function simultaneously and brings the results together. Handoff orchestration hands off tasks to the relevant specialist as determined by the piece. Group chat fosters collaborative rehearsal until the final output meets the established criteria. Magentic orchestration provides the flexibility to adjust the plan mid-performance. Foundry serves as the venue: providing the stage, acoustics, lighting, and documentation of the performance.

The future is not about a single agent doing everything; it’s about a governed team of specialists that understands **how to work collaboratively, when to ask for help, and where their authority stops**. The sections play their parts, while the conductor makes the calls.

Useful Microsoft Resources

• Overview of the Foundry Agent Service


• Exploring Agent Framework orchestration patterns


• AI agent design patterns (Azure Architecture Centre)


• Utilising agents within workflows


• Patterns for multi-agent systems


• Magentic-One: A Generalist Multi-Agent System (Microsoft Research)