Training / Copilot Studio Practitioner— GitHub Copilot Harness
Copilot Studio Practitioner— GitHub Copilot Harness
Split one agent into a front door and three specialists, share behaviour as a skill, fix the action that must not vary, and gate every release on evaluation.
By the end of eighteen hours, every participant has designed and built a working multi-agent system: a front-door agent routing to three specialists, a reusable skill shared across them, a deterministic workflow for the action that must not be improvised, and an evaluation suite running as a quality gate that blocks a degraded agent from shipping. The hard part is not building agents; it is deciding how many there should be. The first day is spent on that decision, and the other two on proving it.
Makers whose agent has outgrown itself, and who need a method for deciding what to split out, and when not to.
Teams building a shared agent estate, where skills are versioned, reused and owned.
Platform and enablement teams who need agent quality enforced by a gate rather than hoped for.
Technical leads and architects who must defend a multi-agent topology to a reviewer.
First-time builders, or single-agent authoring with instructions, knowledge and tools. Our Foundations — GitHub Copilot Harness course covers those.
Topics, trigger phrases or classic orchestration, which do not exist on this harness. Our Foundations — Standard Harness course covers them.
Generative orchestration, custom connectors, MCP servers or agent-to-agent delegation beyond Copilot Studio. Our Practitioner — Standard Harness course covers those.
ALM, security, data loss prevention, governance or estate-wide licensing. Our Copilot Studio Enterprise course covers those.
Organisations that cannot allocate Copilot Credits for training: four agents and repeated evaluation runs consume materially more than a single-agent course.
- Duration
- 3 days or 9 sessions × 2 hours
- Level
- Practitioner · GitHub Copilot Harness
- Delivery
- Remote or on-site
- Group size
- Up to 10
- Price
- Priced per team — ask us
We reply within one working day. No sales sequence.
What your team will be able to do
Outcomes, not topics covered.
By the end, each of these is something they have done rather than watched.
Decide when a capability belongs inside an agent and when it needs a separate one, and defend the decision.
Choose correctly between the four composition primitives: skills, connected agents, workflows and tools.
Explain how a primary agent routes to a connected specialist, and what travels with the delegation.
Design a specialist with the right scope, knowledge and tool access for its domain.
Package reusable behaviour as a skill, within the sandbox that stops it reaching outside.
Use a workflow to make the actions that must not vary deterministic.
Select a model per agent rather than per system, and iterate instructions against it.
Build test sets for each agent and for the routing between them.
Read relevance, completeness and abstention results, and act on what they show.
Automate evaluation through the Power Platform API and enforce a quality threshold before deployment.
Model the cost of a multi-agent system, including the overhead routing itself adds.
Monitor a fleet of agents rather than a single one.
What's covered
16 modules, a little under half of it building.
Labs run on your own tenant, and one multi-agent system is built up across all three days. Day one is mostly design, because how many agents there should be is the decision that cannot be cheaply undone. Four agents and repeated evaluation runs use materially more Copilot Credits than a single-agent course, so the allocation is agreed before booking. The one preview capability, evaluation authoring, is kept to one module and one lab. We publish what each day produces rather than a minute-by-minute timetable.
Day 1
Design
Leaves with: A topology you can defend, and a front door that delegates correctly
-
01
Why multi-agent, and when not to
What splitting an agent buys, what it costs, and why one well-scoped agent beats three badly-scoped ones.
-
02
The four composition primitives
Skills, connected agents, workflows and tools, the difference between in-agent and cross-agent work, and the sandbox that decides many cases.
-
03
Lab 1: Draw the topology
A design lab: decide the split, defend it to a partner, then build a front-door agent that declines cleanly.
Hands-on -
04
Routing and delegation mechanics
What a specialist receives when the primary delegates, what it does not, and why a vaguely described specialist is badly routed.
-
05
Lab 2: Build the first specialist and route to it
A contract review specialist, connected and tuned until routing is right in both directions, with the credit cost of one delegation read.
Hands-on
Day 2
Build
Leaves with: A four-agent system working end to end, with a shared skill and a fixed record write
-
06
Skills as versioned reusable packages
Shared wording rather than shared capability, what versioning means for ownership, and what the sandbox forbids.
-
07
Lab 3: Extract a shared skill and hit the sandbox wall
One escalation skill across two agents, a deliberate failure at the sandbox, and the external call routed through a tool instead.
Hands-on -
08
Workflows as deterministic tools
Taking the actions that must not vary away from the planner, and what the user sees when a fixed step fails.
-
09
Lab 4: Complete the system
Supplier data and compliance specialists, routing re-tuned across three, and a workflow for the record write.
Hands-on -
10
Model selection and prompt iteration
A model decision per agent, the Immersive Prompt Builder, and iterating one change at a time.
Day 3
Prove and operate
Leaves with: A test set for every agent and the routing, and a quality gate that stops a broken release
-
11
Evaluation at scale
Test sets per agent and for the routing, and reading relevance, completeness and abstention. The preview capability is contained here and in Lab 5.
-
12
Lab 5: Build and run test sets across the fleet
A set for every agent plus the routing, run together, and a planted routing failure found with the evidence.
Hands-on -
13
Automating evaluation
The evaluation API, asynchronous runs, and quality gates that block a release rather than report on it.
-
14
Lab 6: Wire a quality gate
Authenticate, run, set a threshold, then degrade an agent on purpose and prove the gate holds.
Hands-on -
15
Cost and observability at fleet scale
Why routing has a cost of its own, evaluation as a recurring cost, and tracing a poor answer to the agent that produced it.
-
16
Capstone and next steps
The system presented topology first, solutions and shared-skill governance introduced, and the first morning's split decision revisited.
Upcoming batches
No public batch scheduled yet.
Teams book this course on their own dates. Joining as an individual? Tell us and we'll let you know when the next batch opens.
Before the first day
What we need from you.
Prerequisites
- Working experience building agents on the GitHub Copilot harness: instructions, knowledge, tools, previewing and publishing. Our Foundations — GitHub Copilot Harness course is one route, not a requirement.
- No coding until Lab 6, which calls a REST API from a supplied scaffold. Comfort reading JSON helps.
- Copilot Studio access with the GitHub Copilot harness enabled, and permission to create and connect four agents and to create and run evaluations.
- A Copilot Credit allocation sized for a multi-agent course: consumption is materially higher than on a single-agent course.
- A Microsoft Entra ID access token for the evaluation API. This often needs an app registration held by a platform team, so raise it when scheduling.
- Network access to the supplied Northwind endpoints.
- Every participant completes an access check 48 hours before day one.
We send a checklist a fortnight ahead and will talk to your platform team directly if access needs arranging.
Next step
Tell us about your team.
Roughly how many people, what they build today, and when you'd want to run it. We come back with dates and a quote.
Check availability