Two commands\u2014npm install -g @bradygaster\/squad-cli once globally, squad init once per repo\u2014and Squad drops a specialized AI team: a lead, frontend developer, backend developer, and tester directly against your repository.<\/p>\n
Instead of a single chatbot switching roles, Squad demonstrates repository native multi-agent orchestration without heavy centralized infrastructure.<\/p>\n
How Squad coordinates work across agents<\/p>\n
You describe the work you need done in natural language. From there, a coordinator agent inside Squad figures out the routing, loads repository context, and spawns specialists with task-specific instructions.<\/p>\n
For example, you type: \u201cTeam, I need JWT auth\u2014refresh tokens, bcrypt, the works.\u201d Then you watch the team spin up in parallel. The backend specialist takes the implementation. The tester starts writing the accompanying test suite. A documentation specialist opens a pull request. Within minutes, files are written and branches are created. These specialists already know your naming conventions and what you decided about database connections last Tuesday\u2014not because you put it in the prompt, but because agents load from shared team decisions and their own project history files committed to the repository.<\/p>\n
Instead of forcing you to manually test the output and prompt the model through multiple rounds of fixes, Squad handles iteration internally. Once the backend specialist drafts the initial implementation, the tester runs their test suite against it. If those tests fail, the tester rejects the code. Crucially, the orchestration layer prevents the original agent from revising its own work. Squad\u2019s reviewer protocol can prevent the original author from revising rejected work, and a different agent must step in to fix it. This forces genuine independent review with a separate context window and a fresh perspective, rather than asking a single AI to review its own mistakes. In workflows where reviewer automation is enabled, you review the pull request that survives this internal loop rather than every intermediate attempt.<\/p>\n
It\u2019s not autopilot, and it\u2019s not magic on session one. Agents will ask clarifying questions and sometimes make reasonable but wrong assumptions. You still review and merge every pull request. It is collaborative orchestration, not autonomous execution.<\/p>\n<\/p>\n
Architectural patterns behind repository-native orchestration<\/p>\n
Whether you use Squad or build your own multi-agent workflows, there are a few architectural patterns we\u2019ve learned from building repository-native orchestration. These patterns move the architecture away from \u201cblack box\u201d behavior toward something inspectable and predictable at the repository level.<\/p>\n
1. The \u201cDrop-box\u201d pattern for shared memory<\/p>\n
Most AI orchestration relies on real-time chat or complex vector database lookups to keep agents in sync. We\u2019ve found that this is often too fragile; synchronizing state across live agents is a fool\u2019s errand.<\/p>\n
Instead, Squad uses a \u201cdrop-box\u201d pattern. Every architectural choice, like choosing a specific library or a naming convention, is appended as a structured block to a versioned decisions.md file in the repository. This is a bet that asynchronous knowledge sharing inside the repository scales better than real-time synchronization. By treating a markdown file as the team\u2019s shared brain, you get persistence, legibility, and a perfect audit trail of every decision the team has made. Because this memory lives in project files rather than a live session, the team can also recover context after disconnects or restarts and continue from where it left off.<\/p>\n
2. Context replication over context splitting<\/p>\n
One of the biggest hurdles in AI development is the context window limit. When a single agent tries to do everything, the \u201cworking memory\u201d gets crowded with meta-management, leading to hallucinations.<\/p>\n
Squad solves this by ensuring the coordinator agent remains a thin router. It doesn\u2019t do the work; it spawns specialists. Because each specialist runs as a separate inference call with its own large context window (e.g., up to 200K tokens on supported models), you aren\u2019t splitting one context among four agents, you\u2019re replicating repository context across them.<\/p>\n
Running multiple specialists in parallel gives you multiple independent reasoning contexts operating simultaneously. This allows each agent to \u201csee\u201d the relevant parts of the repository without competing for space with the other agents\u2019 thoughts.<\/p>\n
3. Explicit memory in the prompt vs. implicit memory in the weights<\/p>\n
We believe an AI team\u2019s memory should be legible and versioned. You shouldn\u2019t have to wonder what an agent \u201cknows\u201d about your project.<\/p>\n
In Squad, an agent\u2019s identity is built primarily on two repository files: a charter (who they are) and a history (what they\u2019ve done), alongside shared team decisions. These are plain text. Because these live in your . squad\/ folder, the AI\u2019s memory is versioned right alongside your code. When you clone a repo, you aren\u2019t just getting the code; you are getting an already \u201conoboarded\u201d AI team because their memory lives alongside the code directly in the repository.<\/p>\n
Lowering the barrier to multi-agent workflows<\/p>\n
Our biggest win with Squad is that it makes it easy for anyone to get started with agentic development in a low-touch, low-ceremony way. You shouldn\u2019t have to spend hours wrestling with infrastructure, learning complex prompt engineering, or managing convoluted CLI interactions just to get an AI team to help you write code.<\/p>\n
![\"Brady](\"https:\/\/www.newsbeep.com\/uk\/wp-content\/uploads\/2026\/03\/c4c1d68f4766046384a4c7ee192c152e0bf240745b6b84a0baa656e9b0abd0b1.jpeg\")
<\/p>\n