A while back I built GitHub Copilot Squad, a custom multi-agent setup for the GitHub Copilot coding agent. After using it on real-world tasks, I rebuilt it into a simpler version. This is the story of what I tried, what I learned, and what I ended up with.
The first version: 4 agents
The original idea was role separation. Don't let one agent plan, build, and review all at once. So I split it into four agents:
- Capybara: the router
- Otter: the implementer
- Owl: the reviewer
- Squirrel: a lightweight helper for simple questions
kevinkwee
/
github-copilot-squad
Custom multi-agent orchestration for GitHub Copilot coding agent with role-based routing.
GitHub Copilot Squad
A custom multi-agent orchestration setup for GitHub Copilot coding agent.
This repo defines a 4-agent team with clear roles:
- Capybara: router/orchestrator
- Otter: implementation agent
- Owl: reviewer/QA gate
- Squirrel: general assistant for simple/non-technical requests
The goal is to separate execution and review, so technical tasks go through an implementation + review loop before final output, with different models contributing different perspectives.
Why this exists
When using one agent for everything, prompts often mix planning, coding, and reviewing in one pass, and the context window can fill up quickly. This setup enforces role separation:
- Technical work is done by a builder agent (
Otter) - Quality is validated by a strict reviewer (
Owl) - Implementation and review can run on different models, giving a multi-perspective quality check
- Non-technical/simple requests are handled fast by a lightweight helper (
Squirrel) - Routing and iteration control…
The goal was to keep implementation and review as separate perspectives, so technical work goes through a build-then-review loop before it comes back to you.
What using it taught me
The separation sounded clean on paper. In practice, a few things bugged me:
-
A separate generalist implementer didn't add much. Spinning up a separate agent just to offload execution only pays off when that agent is specialized (a frontend expert, a specific-framework expert). My
Otterwas a generalist, just likeCapybara. Two generalists gave me handoff overhead, not more perspective. -
A fresh isolated context per request is expensive. Because
Otterwas a separate sub-agent, every request started in a fresh context. That meant more tokens and more time for it to re-read the codebase and re-analyze the problem, even for follow-ups that built directly on the previous work. - The context-window fear was overblown. My worry with merging the builder into the entry point was that the context window would fill up fast. After running it on real, multi-step tasks, it grew slower than I expected, and the benefit of warm, carry-over context outweighed the cost.
So I built a simpler version.
The simplified version
kevinkwee
/
github-copilot-squad-simplified
Simplified version of my GitHub Copilot Squad, a custom multi-agent orchestration for GitHub Copilot coding agent with role-based routing.
GitHub Copilot Squad (Simplified)
A simplified orchestration setup for the GitHub Copilot coding agent, and a leaner variant of github-copilot-squad. It ships in two modes:
-
Trio (default):
Capybara(entry point + implementer) +Owl(code reviewer) +Cat(comment/docstring reviewer). -
Duo:
Capybara+Owlonly, with no dedicated comment/docstring pass. The Duo behavior lives inCapybaraDuo.agent.md.
In both modes the goal is the same: keep implementation and review as separate perspectives, so technical work goes through a build → review loop before final output. What's removed (vs the original 4-agent squad) is the overhead of a separate execution agent and a separate lightweight helper.
Why this simplified version exists
The original squad offloads implementation to a dedicated builder agent (Otter), with Capybara acting as a pure router. After using it on real-world tasks, that separation turned out to be unnecessary for this…
I merged Otter into Capybara. Now Capybara is the entry point and the implementer. It receives the request, does the work, then hands off to Owl for review. I also dropped Squirrel (tbh it was useless, I never really used it irl 😂), so Capybara handles simple questions directly. Owl stayed as the reviewer.
It ships in two modes:
-
Duo.
Capybara+Owl(the lean version) -
Trio (default).
Capybara+Owl+Cat(more onCatin a moment)
For technical requests, Capybara implements, then loops with Owl until Owl approves. In Trio mode, it then loops with Cat until Cat approves, then returns the result.
Why I added a comment/docstring-only reviewer
For a while, Duo mode was enough. But I noticed something: agents sometimes write unnecessary, redundant, or inappropriate comments and docstrings, even when the rules already say not to. Owl's review covers this, but Owl also reviews the code implementation, so these prose issues sometimes got skipped.
So I added Cat, a reviewer that focuses ONLY on comments and docstrings. It runs after Owl approves, so the code is already correct. Cat's whole job is to groom the prose. Each review pass writes a report file, so there's a lightweight audit trail.
That's the Trio mode: Capybara and Owl (code review), then Capybara and Cat (comment/docstring review), then finish.
One thing that's not there yet
Both setups treat an AGENTS.md file as the source of truth for project-specific rules (stack, test commands, linter, naming, and the expected comment/docstring rules). The agent profiles stay generic and reusable. The project-specific detail lives in AGENTS.md, which is easier to update and maintain than editing the bundled agent profiles.
I haven't published an AGENTS.md example or template yet. I'll add one as soon as I have time to put a clean template together. Until then, you can write your own AGENTS.md describing your stack, your test command, your linter, and any hard constraints you want the agents to respect.
The animals
Because naming things is half the fun:
| Role | Animal | Why it fits |
|---|---|---|
| Entry point + Implementer | Capybara 🦫 | Calm and sociable. Comfortable doing the work itself and coordinating the review. |
| Code reviewer | Owl 🦉 | Sharp observation. Spots sneaky issues. |
| Comment/docstring reviewer | Cat 🐱 | Fastidious groomer. Grooms comments and docstrings until every word earns its place. |
Wrapping up
The short version: I started with 4 agents, found that one generalist implementer was enough, and ended up with a 2-agent setup with an optional 3rd for docstring grooming. The configs are just markdown agent profiles you can drop into VS Code Copilot Chat.
Top comments (0)