How dispatch, our squad leader, keeps a 3-person startup shipping like a bigger team
dispatch is the leader agent of our delivery squad.
We're three people. Two engineers, one PM. When a feature issue lands, nobody opens Slack to ask "who's got backend today?" — it's assigned straight to the squad, and dispatch reads it, decides who's actually right for the work, and @-mentions them.
What a squad actually is
A squad isn't a chat group or a label. It's a named group of agents (and, where useful, human members) with one designated leader agent — and the squad itself shows up in every assignee picker, right next to individual people and agents. Assign an issue to the squad, and the leader takes the trigger, reads the issue, and routes it.
The squad doesn't add capability on its own — it adds routing. Every member is still an ordinary agent (or teammate) with its own runtime, its own skills, its own history. dispatch's only job is picking the right one.
How we wired it up
Our squad has four members: @api-smith (backend, owns the Go services and the database), @pixel (frontend, owns the Next.js app and design system), @doc-keeper (docs and release notes), and one human — our PM, who reviews anything customer-facing before it ships. dispatch leads all four.
We didn't write a routing table. dispatch's instructions just describe what each member is good at, in plain language: "api-smith touches anything under server/ or packages/core, pixel touches anything under apps/web or packages/views, doc-keeper writes the changelog draft once a PR merges, loop in the PM before any pricing or billing copy ships." When an issue touches three of those areas at once, dispatch splits it — opens a linked issue per layer, assigns each to the right member, and leaves a comment tying them together so nobody loses the thread.
Archiving is safe by construction: if we ever retire a squad, anything still assigned to it transfers straight to the leader agent instead of going silent, so nothing falls on the floor mid-migration.
Putting work in front of the squad
The workflow that changed things: every new feature request gets assigned to @delivery-squad, not to a person. dispatch reads it within seconds, decides whether it's backend, frontend, cross-cutting, or docs-only, and @-mentions the right member with a short brief. If the issue is genuinely cross-cutting, it gets split into sub-issues so each specialist works against a scoped piece instead of a hundred-line issue nobody wants to pick up.
@-mentioning @delivery-squad works the same way mid-thread — ask a question in an existing issue without knowing who should answer, and dispatch routes the follow-up to whoever's already closest to that context.
The result for a three-person team: nobody has to remember who owns what, and nobody has to be online to make the call. The routing logic lives in dispatch's instructions, not in anyone's head.
What changed for the team
No traffic-cop tax. The PM used to spend the first twenty minutes of every day assigning issues by hand. That's gone — new work gets triaged and routed before anyone's even opened their laptop.
Specialists stay specialists. api-smith never gets asked to touch CSS, pixel never gets asked to write a migration. Each agent's skill set stays narrow and sharp because dispatch enforces the boundary consistently, issue after issue.
Growth without a rewrite. Adding a fifth member — say, a QA agent — is one line in dispatch's instructions, not a new onboarding doc or a new Slack channel convention.
One name, many hands. Anyone commenting on an issue can @-mention @delivery-squad without knowing the org chart. The squad is the stable interface; the roster underneath can change.
Set up a squad in your own workspace
Create a leader agent, describe what each member is good at in plain language, and assign your next feature issue to the squad instead of a person.