Super Bowl Sunday, upstairs
We live near Seattle, so Super Bowl Sunday was not exactly a subtle event.
Friends were over. People were in Seahawks gear. The game was on. The room was full of people who either write code, used to write code, or have spent enough years around people who write code that they know the signs.
I was not doing a great job being present.
I kept slipping upstairs.
I had this thing running. It was still rough, still weird, still changing every few minutes. I would go upstairs, run another experiment, have it build something, watch what happened, then come back down and try to act like I was watching football.
At one point I had it build a Snake game.
This is not the most dignified origin story for a developer tool, but it is the true one.
One of the first people I showed it to was Shayne Boyer. He wasn’t there that weekend; he was home in Orlando. I aimed Squad at one of his projects, recorded a video of it working and thinking, and sent him the analysis it wrote. He started using it right away.
Then he started sending pull requests.
I knew it was something once Shayne started sending in pull requests.
His PR #2 opened on February 8, Super Bowl Sunday. The repo history backs up my memory of the weekend pretty well. The first commit was late Thursday night, technically. But Sunday was the day it caught fire: 41 commits, more than twice any other day in that first burst.
Between Squad working and the Seahawks winning, it was a pretty magical day.
That is a sentence I did not expect to write about software.
What came before Squad
Squad did not appear from nowhere. The week before, I had been building something narrower: a team of agents that worked as research assistants for product managers coming up to speed on their own product area. You could hand the team a question at night, let them work through it, and wake up to a briefing.
It already had a lot of the DNA that became Squad. The agents had charters. They had names. They wrote things down. There was a session log, and a sense that the team was not just using the product. In a strange way, the team was the product.
That project got big fast, probably too big. It was a domain-specific experiment that exposed a more general pattern. The useful thing was not the product-management focus; it was the shape underneath it: a team of project-aware agents with durable memory and clear roles.
Its last commit landed on February 5. Squad’s first commit landed about eleven hours later. That was the handoff.
The first commit already had the point
The first Squad commit was called “Squad v0: AI agent teams for any project.”
That was the idea.
Not an agent for a task. Not a chat that forgot everything the next time you opened it. A team that could live with the repo, learn the project, and keep enough memory around that you did not have to start over every session.
The day-one architecture was crude, but the core was there.
A thin coordinator routed work. Individual agents were spawned with only their charter and their history. Shared decisions lived in the repo. Personal history and shared decisions were separate things. Scribe existed from the beginning as the quiet memory manager.
The agents were disposable.
The memory was not.
That distinction still feels like the whole trick.
Squad is here for GitHub Copilot. I have never backed away from that, and I never will. The original README said it plainly: an AI team through GitHub Copilot. One file, one click, a working team that knows your project.
A lot changed after that first commit.
But the insight was right early.
The hard part was protecting it.
Structure beats scale
My first instinct, like a lot of people’s first instinct with agents, was to think about quantity.
More agents. More parallelism. More work in flight.
That is not wrong, exactly. It is just incomplete in the way most fun ideas are incomplete before reality gets involved.
David Pine helped sharpen the method early. He pushed the work toward discipline: capture what happened, inspect it, refine it, treat agents like systems under test instead of magic interns with YAML files.
He later became a public contributor with the docs Astro rewrite on March 9, but his influence on the way I thought about the system started earlier than that. The important part was not just that agents could fan out. It was that their work had to be coordinated, observable, and humane.
Tamir Dresher came in later too. His first public entry was a PRD on March 5, which is extremely on brand.
Tamir brought research rigor to a thing I had mostly been learning by building, breaking, and muttering at my laptop. One of the ideas he helped make concrete was that roles matter more than raw count. A bunch of identical agents does not buy you much. Distinct responsibilities do.
That lesson kept coming back.
Structure beats scale.
Or, at least, scale without structure mostly creates more interesting ways to fail.
Protecting the insight
Once people started using Squad, the system had to survive contact with actual projects.
That changed everything.
Append-only shared files sounded simple until parallel agents tried to write to them at the same time. Prompt instructions sounded like governance until an agent cheerfully interpreted them as suggestions. More memory sounded useful until the memory crowded out the agent’s ability to think.
I had to back into defenses.
Inbox patterns. Drop boxes. Scribe-mediated decisions. Hooks. Reviewer lockouts. Slimmer prompts. Memory classes. Boring names for boring things that matter.
This is where a lot of agent demos fall apart, I think.
The demo proves the insight.
The product has to protect it.
Squad’s original idea was that repo-backed memory could give disposable agents continuity. That still feels right. But continuity creates responsibility. If the memory is wrong, stale, noisy, or impossible to inspect, the system gets worse while looking more sophisticated.
Memory is a budget, not a hoard.
That sentence took me longer to learn than I would like to admit.
Open source made it real
Open source changed Squad from a thing I was building into a thing I was responsible for.
Shayne was the first big signal. PR #2 on Super Bowl Sunday, then a merged PR #5 two days later, then more. Jeff Fritz showed up in week one too, with issue #11 on February 11 and a docs PR shortly after.
That kind of early validation is intoxicating.
It is also dangerous.
Because once people use the thing, the work is no longer just the fun part. It is docs. Contracts. Naming. Triage. Version drift. Weird repos. Missing flags. Confusing wrappers. Users asking perfectly reasonable questions because the tool, the docs, and the agents’ understanding of their own ecosystem are not quite aligned.
Nothing teaches humility like an agent confidently describing a feature you have not actually shipped.
Dina Berry, Tamir, Pine, Shayne, Jeff, and others made the project better in public and in practice. They also made it harder for me to pretend Squad was just my weekend experiment.
That was good.
It was also heavier.
Becoming the maintainer
There is another part of this story that took me by surprise.
Years ago, during the SignalR era, I was an amplifier. An evangelist. An irritating fanboy, if we are being honest, which we should probably be.
David Fowler was one of the people carrying the actual engineering load.
I cared deeply about the product. I talked about it constantly. I pulled it into rooms. I sent feedback, feature requests, customer asks, and whatever else came with being excited about something that other people had to maintain.
That kind of advocacy can help a project grow.
It can also create pressure.
With Squad, the polarity flipped. I became the person carrying the thing. I became the maintainer watching scope expand, users arrive, docs drift, expectations form, and every good idea become another surface area someone would have to support.
That did something to my memory of the SignalR years.
Around late March, I reached back out to Fowler. I apologized for the pressure I had put on him back then, and thanked him for carrying more than I probably understood at the time.
He was generous about it.
That mattered to me.
The lesson was not that anyone had been wrong. The pressure was structural, not personal. Advocacy creates demand. Demand creates ambiguity. Ambiguity lands on maintainers.
I had to become the person under the weight before I fully understood the shape of it.
Squad is partly my attempt to change the economics of that pressure.
Not eliminate it.
That would be nonsense.
But maybe give the people carrying the work a little more help, a little more memory, and a little less starting over.
What’s next
This is the origin and the early lessons, not the definitive retrospective. I am still close enough to the beginning that I do not want to pretend I have the whole shape of it yet. This is the first of a series of Squad-story posts, and there is a lot left to write. I want to write about the lessons that only showed up once real projects were involved, the surprising things people built with Squad that I never planned for, and the unglamorous machinery underneath it all: memory, governance, hooks, roles, and the parts that make agent teams useful instead of merely impressive. There is a human side too, about maintaining a thing in public, that I am still figuring out.
Squad is here for GitHub Copilot. That has been true since the first commit and it stays true now, woven through everything I plan to write next.
For now, this is the origin as I understand it. Thanks for reading it. I built a team because I was tired of starting over, and then the team taught me why continuity is the expensive part. I am still working that out in public, one post at a time.