Copilot Studio multi-agent design starts with the harness
Diesen Beitrag auf Deutsch lesen
Standard and GitHub Copilot harnesses expose different options for child agents, skills, A2A, MCP and connected agents.
TL;DR
Copilot Studio agents cannot move between the standard and GitHub Copilot harnesses without a rebuild. Standard supports child agents and documented A2A, while the GitHub Copilot harness supports skills, sandboxed file work and Copilot Studio-only connected agents. Harness choice also changes billing and available capabilities.
Original by Holger Imbery, on Holger Imbery - fieldnotes and insights. Read the original
This is our own summary, not a republication or full translation.
Why it matters
- Makers: Choose the harness before building, because moving an agent to the other harness requires a rebuild and changes the available orchestration patterns.
- Makers: Use child agents in the standard harness for typed inputs, triggers and separate tool limits; use skills in the GitHub Copilot harness for reusable instruction and file-processing packages.
- Admins/IT: Treat external access from skills as governed tools, since skill code has no outbound network path and skills do not authenticate.
- Leadership/Business: Budget for GitHub Copilot harness usage from authoring onward, because building, testing and evaluating are metered.
Frequently asked questions
Can I move a Copilot Studio agent from the standard harness to the GitHub Copilot harness?
No. Agents cannot be transferred between the standard and GitHub Copilot harnesses, so changing harness requires rebuilding the agent.
When should I use Copilot Studio child agents instead of skills?
Use child agents when typed inputs and outputs, triggers, validation, priorities or a separate tool limit are needed. Skills suit reusable instructions, scripts, templates and reference files in the GitHub Copilot harness.
Can a Copilot Studio skill call Microsoft Graph or an external REST API directly?
No. Skill code runs in a sandbox without an outbound network path. External systems must be reached through a configured, governed tool such as a connector, workflow or MCP server.