Coordinated AI agents inside your repo: how Squad is changing the game
AI agents have become coding companions for a lot of people, but anyone who has actually used them knows how things play out in practice.
You write a prompt, the model half-understands it, you refine, adjust, and in the end you spend more time steering the AI than actually building software. It feels productive at first, but as the project grows, that dynamic starts to drag. Every manual tweak you make is time that could be spent on more strategic decisions — on architecture, user experience, real delivery quality.
That works up to a point, but when the project starts scaling, the question changes. It is no longer how do I write a good prompt, but how do I coordinate design, implementation, testing, and review without losing the thread along the way. The problem stops being technical and becomes organizational, and that is exactly where most current tools show their limitations.
Multi-agent orchestration shows up as a natural answer to this problem, except it has always come with a steep price: hours of configuration, layers of infrastructure, vector databases, complex frameworks — all of that before delegating a single task. Anyone who has tried to set up a system like this knows the friction is real and that the setup effort often outweighs the benefit you were hoping for in the first place.
That is where Squad comes in with a different approach. The project is open source, runs on top of GitHub Copilot, and drops a specialized AI team right inside your repo without requiring you to build anything heavy underneath. Two commands and you already have a team made up of a lead agent, a frontend developer, a backend developer, and a tester ready to work alongside you. Just like that. 🚀
What is Squad and how does it work in practice
Squad is an open source framework for collaborative development with AI agents that was designed to eliminate the entry-level complexity that usually scares off anyone who wants to experiment with multi-agent orchestration. Instead of requiring you to configure pipelines, install heavy dependencies, or deeply understand how to connect different models to each other, Squad works directly in the environment you already use: GitHub Copilot inside VS Code or a compatible environment.
Installation is absurdly straightforward. You run npm install -g @bradygaster/squad-cli once globally and then execute squad init inside the repository where you want to use it. Done. No docker compose, no endless environment variables, no vector database to configure. The agent team is initialized right there, in the context of your project.
The core idea is that each agent has a clear and well-defined specialty. There is a lead agent responsible for coordinating the overall flow, interpreting the bigger task, and distributing work among the others. There is the frontend agent, focused on visual components, interfaces, and user experience. The backend agent handles logic, APIs, and data structure. And the testing agent makes sure what was produced actually works before it reaches your hands. Each of these roles exists independently, but they all work connected within the same repository, which keeps the project context preserved throughout the entire execution.
In practice, the flow starts with you describing what you need — whether it is a new feature, a bug fix, or a broader refactoring task. The lead agent interprets the request, breaks it down into smaller pieces, and delegates to the right specialists. Each agent executes its part with access to the repository context, which means they are not working in a vacuum. They understand the project structure, respect existing patterns, and produce code that fits what you have already built, instead of generating something generic that you will need to manually adapt later.
How Squad coordinates work across agents
You describe the work in natural language. From there, the coordinating agent inside Squad figures out the routing needed, loads the repository context, and triggers the specialists with specific instructions for each task.
Receive the best innovation content in your email.
All the news, tips, trends, and resources you're looking for, delivered to your inbox.
By subscribing to the newsletter, you agree to receive communications from Método Viral. We are committed to always protecting and respecting your privacy.
Let us walk through a concrete example. Imagine you type something like: Team, I need JWT authentication with refresh tokens and bcrypt. From that request, Squad puts the agents to work in parallel. The backend specialist takes on the authentication logic implementation. The testing agent starts writing the corresponding test suite. A documentation specialist opens a pull request with the relevant information. Within minutes, files are written and branches are created.
The most interesting part is that these specialists already know the naming conventions in your project and know what was decided about database connections days ago. Not because you put that in the prompt, but because the agents carry shared team decisions and their own project history files that are committed to the repository.
Independent review between agents
Instead of forcing you to manually test the output and walk the model through multiple rounds of corrections, Squad handles the iteration internally. When the backend specialist finishes the initial implementation, the testing agent runs its suite against the code. If the tests fail, the tester rejects the code.
Here is a detail that makes all the difference: Squad’s review protocol prevents the original agent from reviewing its own work. A different agent needs to take over the fix. This forces a genuinely independent review, with a separate context window and a fresh perspective, instead of asking the same AI to review its own mistakes. In workflows where automated review is enabled, you review the pull request that survived this internal cycle, not each intermediate attempt.
Important to be clear: this is not autopilot. Agents will ask clarifying questions and sometimes make reasonable but incorrect assumptions. You still review and merge every pull request. It is collaborative orchestration, not autonomous execution.
Why multi-agent orchestration changes the game
When you work with a single AI agent, the context is always limited. The model needs to understand the problem, plan the solution, write the code, think about tests, and still maintain coherence with the rest of the project — all at the same time. This creates a natural bottleneck because any model has limits on attention and depth. The result tends to be code that works in isolation but does not play well with the rest of the codebase, or shallow tests that do not cover the cases that actually matter.
Multi-agent orchestration solves this by splitting responsibilities so that each agent can focus on one thing and do it really well. It is the same principle that makes human teams work: a designer does not need to know how to write database migrations, and a DBA does not need to know every accessibility detail in interfaces. Specialization increases both quality and speed at the same time because each part of the problem gets dedicated attention from someone built to handle it.
What Squad brings to this picture is precisely the accessibility of this approach. Before, implementing a functional multi-agent system meant choosing a framework like AutoGen, CrewAI, or LangGraph, understanding how to orchestrate calls between agents, defining shared memory, handling failures and retries, and still integrating all of that with your development environment. It was doable, but clearly out of reach for anyone who simply wanted to be more productive day to day. Squad compresses all of that into an experience that fits in two terminal commands.
Architecture patterns behind repo-native orchestration
Whether you are using Squad or building your own multi-agent workflows, there are some architectural patterns that emerged during the development of repo-native orchestration. These patterns move the architecture away from black-box behavior and toward something inspectable and predictable at the repository level.
The drop-box pattern for shared memory
Most AI orchestrations rely on real-time chat or complex vector database lookups to keep agents in sync. In practice, this tends to be too fragile. Synchronizing state between active agents in real time is a thankless task.
Squad uses a different approach called the drop-box pattern. Every architectural decision — like choosing a specific library or a naming convention — is added as a structured block to a decisions.md file versioned in the repository. The bet is that asynchronous knowledge sharing within the repo scales better than real-time synchronization.
By treating a markdown file as the shared brain of the team, you get persistence, readability, and a perfect audit trail of every decision made. Because this memory lives in the project files and not in an active session, the team can also recover context after disconnections or restarts and pick up right where it left off.
Context replication instead of context splitting
One of the biggest obstacles in AI-driven development is the context window limit. When a single agent tries to do everything, working memory gets packed with meta-management, which leads to hallucinations and inconsistent responses.
Squad solves this by ensuring the coordinating agent functions as a lean router. It does not do the work itself — it just triggers the specialists. Because each specialist runs as a separate inference call with its own wide context window (up to 200K tokens on compatible models), you are not splitting one context across four agents. You are replicating repository context across them.
Running multiple specialists in parallel gives you multiple independent reasoning contexts operating simultaneously. This lets each agent see the relevant parts of the repository without competing for space with the other agents’ thoughts. In practice, it is like having four people looking at the same project, each with full focus on their area of responsibility.
Explicit memory in the prompt versus implicit memory in the weights
An AI team’s memory needs to be readable and versioned. You should not have to guess what an agent knows about your project.
In Squad, each agent’s identity is primarily built from two files in the repository: a charter (who it is) and a history (what it has already done), plus the shared team decisions. These files are plain text and live in the .squad/ folder of the project.
Because this memory lives in the repository alongside the code, it is versioned right next to everything else. When you clone a repo that uses Squad, you are not just getting the code. You are getting an AI team already integrated into the project, because its memory lives directly in the repository. It is like the agents’ onboarding comes baked into the git clone. 🧠
Collaborative AI development inside the repository
One of the most interesting things about Squad is the fact that all the collaboration happens inside the repository. That might sound like a technical detail, but it makes a huge difference in the quality of the output. When AI agents have real access to the file structure, the change history, and the conventions already established in the project, they can make decisions far more aligned with what you actually need instead of delivering generic solutions disconnected from context.
This model of collaborative development also changes the relationship between the developer and the AI. Instead of being the operator who keeps tweaking prompts until you get something usable, you become the one responsible for the strategic direction of the project while the agent team handles coordinated execution. You decide what to build, set priorities, review what was delivered, and validate quality. The agents do the heavy lifting of implementation, testing, and integration. This division is much closer to how a real human team works than the traditional AI-assisted model.
Another relevant aspect is that, being open source, Squad allows the community to contribute new specialized agents, adjust existing behaviors, and adapt the framework for specific contexts. This means the project has the potential to grow in directions that not even the original creators anticipated, especially considering the fast pace at which the AI agents space is evolving. For teams working with specific stacks or more niche domains, that flexibility could be what turns Squad from an interesting tool into a central piece of the workflow.
Lowering the barrier to entry for multi-agent workflows
Squad’s biggest achievement so far is making it easy for anyone to get started with agentic development in a simple, no-ceremony way. The premise is that you should not need to spend hours fighting with infrastructure, learning complex prompt engineering, or managing complicated CLI interactions just to have an AI team helping you write code.
This accessibility is especially important when you consider that many developers still have not had any contact with multi-agent systems. Squad works as a practical entry point into this world, letting you see orchestration happening in real time inside an environment you already know. It is learning by doing, without needing a course on agent architectures before taking the first step.
What to expect from a project at this stage
Squad is still a young project, and it is important to have that expectation well calibrated before jumping into production use. Like any open source tool early in its lifecycle, you may run into unexpected behaviors, limitations in more complex use cases, and documentation that is still being built at a rapid pace. That is not a flaw — it is the nature of open development, and it is part of what makes this kind of project worth following.
For anyone evaluating whether it is worth exploring now, the most honest answer is: it depends on the context. If you have personal projects, studies, or proofs of concept where you can experiment without pressure, Squad offers a very accessible window into understanding how multi-agent orchestration works in practice. You will learn a lot just by watching how the lead agent delegates tasks, how the specialists respond, and where the system still stumbles. That learning has value regardless of whether you adopt the tool long term or not.
For use in professional projects with deadlines and stakeholders involved, the safest path is to test it in parallel, keep an eye on the official repository to track the pace of updates, and evaluate based on concrete results in your specific context. The potential is clearly there. The question is when the tool’s maturity will catch up with the ambition of the vision — and everything points to that path being traveled pretty fast. ⚡
Squad was created by Brady Gaster, Principal PM Architect in the CoreAI Apps and Agents area at Microsoft, and is publicly available on GitHub for anyone who wants to test it, contribute, or simply follow the project’s evolution.
