Squad: AI Agent Teams That Live in Your GitHub Repo (1K Stars)

TL;DR

What: Open-source multi-agent team framework built on GitHub Copilot
Creator: Brady Gaster, PM Architect at Microsoft’s CoreAI division
Featured: Official GitHub Blog, March 19, 2026
Stars: ~1,000 ⭐ | Forks: 134 | License: Apache/MIT
Install: npm install -g @bradygaster/squad-cli → squad init
Team: Lead, Frontend, Backend, Tester, and Scribe agents — all living in your .squad/ folder
Status: Alpha — promising but expect breaking changes
Key insight: Agents persist across sessions, learn your codebase, and share decisions through plain markdown files committed to git

Quick Reference Table

Metric	Value
GitHub Stars	~1,000
Forks	134
License	Apache 2.0 / MIT
Creator	Brady Gaster (Microsoft CoreAI)
Language	TypeScript
Install	`npm install -g @bradygaster/squad-cli`
Compatible With	GitHub Copilot CLI + VS Code
Status	Alpha
Released	March 2026
Repo	github.com/bradygaster/squad

What Is Squad?

Squad is a multi-agent development framework that gives you a preconfigured team of AI specialists — a lead architect, a frontend developer, a backend developer, a tester, and a silent scribe — all running through GitHub Copilot. Unlike a single AI assistant switching between personas, each Squad agent operates in its own context window (up to 200K tokens), reads only its own knowledge files, and writes back what it learned. The whole team lives as plain files in a .squad/ directory inside your repository, committed to git like any other project configuration.

This is not a chatbot wearing different hats. When you tell Squad “build me JWT authentication with refresh tokens,” the lead agent analyzes requirements and creates a plan, the frontend agent starts building the login form, the backend agent sets up auth endpoints, and the tester writes test cases from the spec — all working in parallel. The scribe silently logs every decision to decisions.md, creating a persistent shared memory that survives across sessions. When you come back tomorrow, the team remembers what it decided yesterday.

Getting started takes two commands: squad init to scaffold the team in your repo, then copilot --agent squad --yolo to kick things off. That’s it. No Docker containers, no vector databases, no orchestration servers. The entire multi-agent system is a collection of markdown files and a CLI tool that coordinates GitHub Copilot’s agent infrastructure. It’s an opinionated, batteries-included approach to a problem that usually requires weeks of infrastructure work.

March 2026 is the month multi-agent development went mainstream. Claude launched agent teams that can spawn sub-agents dynamically. OpenAI’s Codex runs in cloud sandboxes with full environment access. Cursor shipped Composer 2 with significantly improved multi-file editing. Every major AI coding tool is converging on the same insight: one agent isn’t enough for real software projects.

But here’s the problem. Setting up multi-agent orchestration from scratch is painful. You need to define agent roles, design communication protocols, manage shared state, handle failures, and figure out how agents should hand off work. Most teams that attempt it end up building custom infrastructure that takes longer than the features they wanted to ship.

Squad bypasses all of that. Brady Gaster — a well-known PM Architect at Microsoft’s CoreAI division — packaged the entire pattern into two npm commands. The framework shipped with sensible defaults: a team structure that maps to how real dev teams work, a “drop-box” pattern for shared memory that uses markdown files instead of vector databases, and a reviewer protocol that prevents agents from reviewing their own code. It got featured on the official GitHub Blog on March 19, 2026, which catapulted it from a side project to ~1,000 stars in days.

The timing is perfect. Developers are hungry for multi-agent tools that actually work without requiring a PhD in agent orchestration. Squad’s approach — repository-native teams stored as committed files — feels like a natural extension of how we already use .github/, .vscode/, and .cursor/ directories. The community response has been immediate: 134 forks in the first week suggests people aren’t just starring it, they’re actively building on it.

Key Features

1. Repository-Native Teams

Your entire AI team lives as files in the .squad/ folder, committed to git alongside your code:

.squad/
├── team.md           # Roster — who's on the team
├── routing.md        # Who handles what type of work
├── decisions.md      # Shared brain — every decision logged
├── agents/
│   ├── lead/
│   │   ├── charter.md    # Identity, expertise, voice
│   │   └── history.md    # Project-specific learnings
│   ├── frontend/
│   │   ├── charter.md
│   │   └── history.md
│   ├── backend/
│   │   ├── charter.md
│   │   └── history.md
│   ├── tester/
│   │   ├── charter.md
│   │   └── history.md
│   └── scribe/
│       └── charter.md    # Silent memory manager
├── skills/           # Compressed learnings from past work
└── log/              # Session history

This means your team configuration is versioned, branch-able, and reviewable in pull requests. Want to see how the team’s knowledge evolved over the past month? git log .squad/ tells you everything.

2. Parallel Agent Execution

Agents work simultaneously on independent tasks. When you give a high-level instruction, the lead breaks it down and routes subtasks to specialists who execute in parallel:

🏗️ Lead — analyzing requirements, creating task breakdown...
⚛️ Frontend — building login form with React...
🔧 Backend — setting up auth endpoints with Express...
🧪 Tester — writing test cases from spec...
📋 Scribe — logging decisions to decisions.md...

This isn’t sequential prompting. Each agent gets its own context window and works independently, only synchronizing through the shared drop-box files.

3. Drop-Box Shared Memory

Instead of a vector database or real-time message bus, Squad uses decisions.md as asynchronous shared memory. Every architectural choice, technology decision, and implementation detail gets logged there in plain markdown. Agents read this file at the start of their work to understand the current state of the project.

This is deliberately low-tech — and that’s the point. It’s inspectable, editable, and version-controlled. If an agent made a bad decision, you can edit decisions.md directly and the team will respect the correction on the next run.

4. Context Replication, Not Splitting

Most multi-agent systems try to split context across agents — each one gets a piece of the codebase. Squad takes the opposite approach: each agent gets the full repository context in its own window (up to 200K tokens). A thin coordinator routes tasks, but specialists see everything. This avoids the “agent doesn’t know about the other file” problem that plagues context-splitting approaches.

5. Session Persistence

If an agent crashes or your terminal disconnects, Squad resumes from checkpoint. The .squad/log/ directory tracks session history, and each agent’s history.md file captures what it learned. Close your laptop, come back Monday morning, and the team remembers Friday’s decisions.

6. Issue Triage

squad triage

This command auto-watches your GitHub repository for new issues and routes them to the appropriate team member based on labels and content. A frontend bug gets assigned to the frontend specialist. A performance issue goes to the backend agent. It’s like having a project manager that never sleeps.

7. Interactive Shell

squad

Just typing squad drops you into an interactive shell where you can talk to the team directly, check status, assign tasks, or review what each agent has been working on.

Architecture & How It Works

Squad’s architecture rests on three core patterns that set it apart from typical AI coding assistants.

The Drop-Box Pattern

Traditional multi-agent systems use message queues, shared databases, or real-time synchronization to coordinate agents. Squad uses a simpler metaphor: a shared drop-box. The decisions.md file acts as an asynchronous bulletin board. Agents write their decisions there after completing work, and other agents read it before starting theirs.

This is intentionally not real-time. The lead agent writes a plan, commits it to decisions.md, and then the specialist agents pick it up on their next cycle. It’s closer to how distributed systems work than how chat rooms work — and that’s a feature, not a bug. Asynchronous coordination is more resilient than real-time sync, and it means the system degrades gracefully when agents are slow or unavailable.

Context Replication Over Context Splitting

Many multi-agent frameworks try to be clever about dividing the codebase. Agent A handles the frontend directory, Agent B handles the backend, and they exchange messages about shared interfaces. This sounds efficient but breaks down fast — Agent A needs to understand the API contract that Agent B is building, and vice versa.

Squad replicates the full context into each agent’s window. The thin coordinator (the lead agent) decides who works on what, but every specialist sees the entire repository. This is more expensive in terms of tokens, but it eliminates an entire class of coordination bugs where one agent doesn’t know what another agent changed.

Explicit Memory in Prompt

The most interesting architectural choice is how Squad handles memory. Instead of fine-tuning, RAG pipelines, or vector embeddings, Squad puts memory directly in the prompt through committed markdown files. Each agent’s charter.md defines its identity and expertise. Its history.md captures project-specific learnings. Both files are committed to git and included in the agent’s context window at runtime.

This means memory is:

Inspectable — you can read exactly what the agent “knows”
Editable — correct wrong assumptions by editing a markdown file
Versioned — git blame shows when and why knowledge changed
Portable — export your team config to another repo with squad export

The Reviewer Protocol

Here’s a detail that shows real thought about software quality: when tests fail in Squad, the agent that wrote the failing code is not allowed to fix it. A different agent must step in to review and repair. This forces genuine independent review — the same principle behind code review in human teams. The fixing agent brings fresh context and often catches assumptions that the original agent baked in without questioning.

How Squad Compares to Alternatives

Feature	Squad	Claude Agent Teams	OpenAI Codex	Cursor Composer 2
Setup	2 commands	Built-in	Cloud sandboxes	Built-in
Persistence	Git-committed files	Session-based	Per-task	Session-based
Agents	Lead, FE, BE, Tester	Dynamic sub-agents	Single agent	Single agent
Memory	Explicit (markdown)	Context window	Fresh per task	Context window
Cost	GitHub Copilot sub	Claude subscription	API pricing	Cursor subscription
Open Source	Yes (MIT/Apache)	No	No	No
Parallel Execution	Yes	Yes	Yes	No
Self-Review Prevention	Yes	No	No	No
Customizable Roles	Yes (charter.md)	Limited	No	No
Audit Trail	Full (decisions.md + git)	Conversation history	Task logs	Conversation history

Squad’s biggest differentiator is persistence. When you close Claude or Cursor, the agent’s knowledge disappears. With Squad, everything is committed to git. Your team’s knowledge compounds over time. The tradeoff is that Squad requires GitHub Copilot specifically — you can’t plug in Claude or GPT-5.4 as the underlying model.

Getting Started

Prerequisites

Node.js 18+
Git
GitHub CLI (gh auth login)
GitHub Copilot subscription (Individual, Business, or Enterprise)

Step-by-Step Setup

# 1. Install the CLI globally
npm install -g @bradygaster/squad-cli

# 2. Create a new project (or use an existing repo)
mkdir my-app && cd my-app && git init

# 3. Initialize your team
squad init

# 4. Start working with your team (CLI)
copilot --agent squad --yolo

# Or use the interactive shell
squad

After squad init, you’ll see the .squad/ directory with your full team configuration. You can customize any of the charter files before your first session.

CLI Commands

Command	What It Does
`squad init`	Scaffold team files in `.squad/`
`squad status`	Show team status and recent activity
`squad triage`	Auto-watch and route GitHub issues
`squad copilot`	Launch Copilot with Squad agent
`squad doctor`	Diagnose configuration problems
`squad nap`	Pause agent activity
`squad export`	Export team config for sharing
`squad import`	Import a team config from another project

Example Session

Once your team is running, you interact with it naturally:

You: "Team, I need JWT auth — refresh tokens, bcrypt, the works."

🏗️ Lead: Breaking this down into parallel tasks...
  → Frontend: Login/register forms + token refresh logic
  → Backend: Auth routes, JWT signing, bcrypt hashing, refresh token rotation
  → Tester: Auth flow tests, token expiration tests, security edge cases

⚛️ Frontend: Building login form with token storage...
🔧 Backend: Setting up /auth/login, /auth/register, /auth/refresh endpoints...
🧪 Tester: Writing 12 test cases covering happy path and edge cases...
📋 Scribe: Logged — "JWT auth with refresh tokens, bcrypt for password hashing,
            httpOnly cookies for token storage" → decisions.md

The team coordinates automatically. The backend agent creates the API contract, the frontend agent builds against it, and the tester validates both. If tests fail, a different agent steps in to fix the issue — not the one who wrote the failing code.

Who Should Use Squad (and Who Shouldn’t)

Good fit:

Teams already paying for GitHub Copilot who want more structure from their AI tooling
Full-stack projects that need coordinated work across frontend, backend, and testing
Teams that want a persistent audit trail of every AI-made decision
Projects where AI memory across sessions matters (long-running development, not one-off scripts)
Organizations exploring multi-agent patterns without building custom infrastructure

Not a good fit:

Solo developers writing small scripts or utilities — Squad’s team overhead is overkill
Projects not using GitHub or git as their primary workflow
Teams that need model flexibility — Squad is locked to Copilot’s underlying models
Production-critical autonomous pipelines — this is alpha software, treat it accordingly
Teams that need real-time agent collaboration — Squad’s drop-box pattern is async by design

Honest Limitations

Every trending tool deserves honest criticism. Here’s what you should know before adopting Squad:

Alpha software. The CLI, configuration format, and agent protocols may change between releases. Don’t build critical workflows on it yet.
Copilot lock-in. You need a GitHub Copilot subscription ($10-39/month). You can’t swap in Claude, GPT-5.4, or local models. If Copilot’s underlying model is weak at your specific task, you’re stuck.
“Not autopilot.” Brady Gaster is explicit about this in the README. You still review and merge every PR. Squad accelerates development; it doesn’t replace developers.
Agents hallucinate decisions. Like any LLM-based system, agents sometimes make reasonable-sounding but wrong architectural choices. The decisions.md file helps you catch these, but you need to actually read it.
No published benchmarks. Unlike Cursor Composer 2 (which publishes SWE-bench scores) or Claude Code (which has public evals), Squad has no quantitative performance data. Community impressions are positive but anecdotal.
The reviewer protocol adds latency. Preventing self-review is great for quality, but it means fixing a failing test requires spinning up a second agent. For rapid iteration, this can feel slow.
Token costs add up. Context replication means every agent gets the full repo. For large codebases, this can burn through Copilot’s token allocation faster than expected.

What’s Next for Squad

The roadmap in the repository suggests several upcoming features:

Plugin marketplace — squad plugin marketplace for sharing custom agent skills and team configurations across projects
Upstream sources — A way to subscribe to team configs from other repositories, keeping your local squad updated with community improvements
Sprint ceremonies — A ceremonies.md file that introduces lightweight agile rituals for the AI team (standups, retros, planning)
Skills migration — Moving from .squad/skills/ to .copilot/skills/ for tighter integration with GitHub Copilot’s native skill system
Community growth — With 134 forks in the first week, contributors are already submitting custom team configurations, new agent roles, and integration plugins

The pace of development suggests this project has serious momentum. Whether it becomes the standard way to do multi-agent development on GitHub or gets absorbed into Copilot itself remains to be seen — but either outcome validates the patterns Squad introduced.

FAQ

Can Squad work without GitHub Copilot?

No. Squad is built specifically on GitHub Copilot’s agent infrastructure. The CLI invokes Copilot under the hood to power each agent. Without an active Copilot subscription, squad init will work (it just creates files), but you won’t be able to run the team.

Does Squad work with VS Code?

Yes. You have two options: use Squad through GitHub Copilot Chat in VS Code by selecting the Squad agent from the agent picker, or use the CLI with copilot --agent squad --yolo. Both approaches work with the same .squad/ configuration. The interactive shell (squad) also works from VS Code’s integrated terminal.

Is Squad free?

Squad itself is open source under Apache 2.0 / MIT dual license — completely free. However, it requires GitHub Copilot to function, which costs $10/month for individuals, $19/month for business, or $39/month for enterprise. If you’re already paying for Copilot, Squad adds no additional cost.

How does Squad compare to Claude’s agent teams?

The fundamental difference is persistence. Claude’s agent teams are session-based — when the conversation ends, the agents’ knowledge is gone. Squad stores everything in git-committed markdown files, so the team’s memory survives across sessions, branches, and even team members. Squad uses explicit markdown for memory; Claude uses context windows. Squad is open source; Claude’s agent system is proprietary. The tradeoff: Claude’s agents can use Claude’s stronger reasoning capabilities, while Squad is limited to Copilot’s underlying models.

What languages does Squad support?

Squad is language-agnostic. The agents work with whatever your project uses — React, Node.js, Python, .NET, Go, Rust, or anything else. You describe what you’re building and the team adapts. The charter files let you customize each agent’s expertise for your specific stack. Common setups seen in the community include React + Node, .NET + Azure, Python + FastAPI, and Next.js + Prisma.

Can I customize the team roles?

Absolutely. Team members are defined in charter.md files inside .squad/agents/. You can modify any existing specialist’s expertise, voice, and behavior. You can also create entirely new roles — a DevOps agent, a security reviewer, a documentation writer — by adding new agent directories with their own charter files. For more complex customization, squad.config.ts gives you programmatic control over team structure, routing rules, and the coordination protocol. Some community members have shared specialized team configs for data engineering, mobile development, and ML pipelines.