Orchestrate multi-agent coordination

Picture one issue split across three agents working as parallel sessions, each in its own Git worktree (a second checkout of the repository on its own branch), while a GitHub Actions workflow runs their checks. Almost every question in this domain hands you one signal from a picture like that and asks what it proves, and the answer is that each mechanism settles exactly one question. A worktree keeps each agent's file edits apart, but it does not sandbox commands, set GitHub Actions token permissions, or decide which job runs first; a sessionEnd hook (a Copilot agent handler, not a Git hook or webhook, that runs when a session terminates) with reason complete reports how the session stopped, not whether the assignment was delivered; and a custom-agent profile (the file defining a custom agent's tools and instructions) can load cleanly while an unrecognized tool name in it is simply ignored. The trap is rarely an invented feature and usually a genuine one pointed at the wrong question, so name the question first and the mechanism second.

Take the first three steps in order, because each builds on the previous one; the lifecycle step wraps around all three, since an agent must exist before it can be coordinated. Operate and manage multi-agent workflows covers the coordinate step: choosing between delegation to subagents (worker agents a coordinator invokes, each with its own context), a handoff that passes the ongoing task and its history to the next specialist, and parallel sessions in separate worktrees, then ordering, isolating, and reconciling what they produce. Configure observability for multi-agent behavior covers the observe step: the records each worker leaves behind, such as named artifacts (files a workflow run uploads for later jobs or reviewers), hook payloads, chat and session records, and run logs, and which of them answers a given audit question. Detect and respond to multi-agent failures covers the recover step: reading those records to tell a run that failed, stopped short, or stalled from one that is only waiting at a gate such as a pending workflow approval, then repairing at the smallest unit, while Manage agent lifecycles within workflows covers the lifecycle step: adding an agent through the source that supplies it (the place its definition lives, such as a repository, an organization, or an installed extension), updating it without disturbing work already in flight, and retiring it or its sessions without destroying the record.

The default this domain rewards is coordination you can point to rather than coordination you infer: order jobs with a declared dependency such as needs instead of hoping one finishes first, identify a worker from the record the platform writes instead of reconstructing it from the agent's own written summary, and accept a result on its changed files and test results instead of its completion message. The same instinct governs repair and cleanup: rerun only the failed jobs and the jobs that depend on them with gh run rerun --failed rather than replaying the whole run, remember that Stop session on a Copilot cloud agent task ends the GitHub Actions run but preserves commits already pushed, and archive a VS Code worktree session, which keeps its branch, before reaching for delete, which is irreversible. Between two workable options, pick the one that leaves the evidence standing and can still be reversed.