Orchestrate multi-agent coordination Study Guide — GH-600

Orchestrate Multi-Agent Coordination

This domain tests your ability to design, operate, and maintain systems where multiple AI agents collaborate to complete complex tasks. It covers orchestration patterns, isolation strategies, conflict detection, observability, auditability, failure recovery, and lifecycle management of agents within active workflows. At 18% of the exam, it is the second-largest domain and rewards candidates who understand both architectural decisions and operational procedures for multi-agent systems built on GitHub Copilot Extensions, GitHub Models, and related Azure AI Foundry integrations.

Applying Orchestration Patterns to Coordinate Multiple Agents

Orchestration defines how agents are sequenced, who directs them, and how results are aggregated. The exam tests three canonical patterns:

Supervisor agents hold the plan, issue directives, and validate subagent outputs. Peer agents communicate through shared state (a message bus, a pull request, or a shared file) without a central authority. The exam distinguishes these: supervisors are responsible for conflict resolution; peer systems require explicit consensus mechanisms.

Worked scenario: A pipeline must generate code, run tests, and produce a security scan. Tests depend on generated code; the scan can run in parallel with tests. The correct pattern is sequential (generate → test) with a fan-out for scan + remaining test steps, then fan-in before the merge gate.

Common traps

• Choosing full sequential when subtasks are independent — exam distractors inflate latency unnecessarily.
• Confusing "supervisor" with "orchestrator" — in GitHub context, an orchestrator is the runtime that schedules agents; a supervisor agent is itself an AI agent with planning capability.
• Assuming parallel agents cannot share a GitHub repository — they can, but require branch isolation (see next section).

Configuring Agent Isolation for Parallel Execution

Agent isolation prevents parallel agents from corrupting each other's state. The exam focuses on three isolation dimensions: compute, storage, and version-control.

Branch-per-agent is the canonical isolation strategy for code-modifying agents. The pattern:

1. Orchestrator creates agent/codegen/run-42 and agent/formatter/run-42 from the same base commit.
2. Agents work independently.
3. Orchestrator merges (or detects conflicts) before proposing a single PR to main.

Thread isolation in Azure AI Foundry: each agent conversation occupies its own thread. Threads are not shared across agents by default. Sharing requires explicit thread handoff — passing the thread_id to the next agent.

GitHub Actions concurrency groups (concurrency: group: agent-${{ matrix.agent }}) prevent two runs of the same logical agent from overlapping, but they do not isolate different agents from each other.

The diagram above shows branch-per-agent isolation and the merge decision point.

Common traps

• Using a single branch for all parallel agents — causes merge conflicts and violates isolation.
• Confusing concurrency (prevents queue buildup) with isolation (prevents state collision).
• Thinking Azure AI Foundry threads are shared by default — they are not; sharing is opt-in via thread_id passing.