The 5-Person AI Team
What the agent coordination I built means for small teams, regulated industries, and the organizations that will get this right
Nate Jones’s briefing on team structure in the AI era opens with a math problem.
The number of communication pathways between people in a group is n(n-1)/2. Two people: one pathway. Five people: ten. Ten people: forty-five. Twenty people: one hundred and ninety. At five people, every person can hold the full communication map in their head during a single conversation. At ten, that breaks down. At twenty, it’s a meeting problem. The meetings aren’t the disease; they’re the symptom.
Robin Dunbar established this from primate neocortex research in 1992. Military doctrine confirmed it independently — a U.S. infantry fire team is four people plus a leader because that’s the size a leader can direct when getting it wrong means people die. Jeff Bezos arrived at the same number from software engineering. Three disciplines. Same answer. Five.
What AI changes is not the optimal team size. What AI changes is the output per team — and therefore the penalty for getting the size wrong.
Companies like Lovable ($400M ARR, 45 employees, $2.2M revenue per person) and Midjourney (~$500M revenue, ~100 employees, $3-5M revenue per person) are running at productivity multiples that make the coordination cost of every additional person catastrophically expensive by comparison. When each person produces $2M per year, the coordination cost of person number six isn’t a manageable tax. It’s measured in millions of dollars of lost productivity. The penalty didn’t increase a little. It increased by the same order of magnitude as the productivity gain.
Jones’s framework for this is the scout vs. strike team model. Scouts are solo operators with AI tooling, full autonomy, and a defined exploration mission. Strike teams are five people with AI, executing against a defined objective where correctness matters. He argues, correctly, that the variable AI changed is not output quantity. AI made volume cheap. What’s now scarce, and what determines whether your organization succeeds, is correctness — whether the thing you shipped actually works, architecturally, strategically, technically.
The Agent Team as Strike Team
The dev tiger team I built has five active roles during a project session: Atlas (PM), Forge (engineering), Compass (content), Beacon (SEO), Prism (UI/UX). Each role brings distinct capability. Each agent operates on a model selected for that capability. The team communicates through a shared channel, routes work through the PM, and surfaces decisions that require human judgment.
This maps to Jones’s strike team model in one important way: correctness was prioritized over speed. When Atlas caught the brand voice violation, he didn’t ship it. When Forge’s SEO specs diverged from Beacon’s verbatim recommendations, Atlas flagged the discrepancy before the PR went to review. When CI failed, Forge posted root cause rather than pushing a speculative fix. Every error caught within the team loop before it reached my queue.
It diverges from the pure human strike team in an obvious way: agents don’t provide the same quality of creative judgment as specialists with deep domain expertise. Compass writes at a high standard, but she’s calibrating to brand guidelines I wrote. Beacon identifies SEO opportunities but applies frameworks against a codebase. The agents are excellent at execution against defined standards. They’re not replacing the humans who defined those standards.
The practical implication: agent teams work best in the execution layer — implementing against defined requirements, checking against established standards, handling the work that’s blocked on bandwidth rather than judgment. They extend what a small team can cover, not what a small team can invent.
What This Means for SMBs
For companies with 20 to 50 employees, the arithmetic looks like this. A typical company in this range has functional gaps — areas where they can’t afford dedicated headcount but where the work matters. SEO is a canonical example: important for pipeline generation, expensive to staff, often handled inconsistently by whoever has bandwidth. Content is another. Technical documentation. Security review of code before deployment.
These are exactly the workstreams where a well-configured specialist agent adds value without requiring the judgment depth that justifies dedicated human headcount. Beacon doesn’t replace an SEO director. He handles the execution work that would otherwise fall to a generalist or not happen at all.
The strike team model, applied to a small company: three to five senior humans whose judgment defines what “correct” looks like, augmented by agents that execute against those standards at scale. The humans review the agents’ work — not all of it, but enough to maintain quality calibration. The agents handle the bandwidth problem that prevents the humans from doing more of the judgment work they’re actually good at.
This is not “fewer people, same output.” It’s the same people, covering more ground, because the work that was blocked on bandwidth is no longer blocked.
The Regulated Industry Dimension
For organizations operating under compliance frameworks — HIPAA, FedRAMP, SOC 2, HITRUST, PCI DSS — there’s a critical dimension that doesn’t appear in most agent adoption discussions.
Your compliance frameworks don’t pause for AI adoption. An agent connected to patient records, financial data, or controlled information is not a productivity tool in the same category as a word processor. It’s part of your information security perimeter, your data processing chain, and your incident response scope.
HIPAA doesn’t have a carve-out for AI agents. If your agent processes protected health information — even incidentally, even in a logging or context retention system — you have PHI handling obligations. Your BAA coverage needs to extend to every service your agent calls. Your audit trail requirements apply to whatever the agent did with that data.
FedRAMP doesn’t have a carve-out either. If you’re a government contractor, the systems your agents connect to and the data they process need to be within your authorization boundary or you need a separate ATO pathway for the agent infrastructure.
The two failure modes I see regularly: reactive adoption (teams deploy agents using consumer tools without a compliance analysis, discover later that PHI was flowing through a system not covered by the BAA) and paralytic caution (blanket prohibition while informal shadow adoption spreads anyway). Same outcome, different path.
The functional answer for regulated industries is the same as for anyone doing this seriously: the compliance question comes before the technology evaluation. Determine which data the agent will touch and what frameworks govern that data. Determine which deployment models are compatible. Then evaluate the technology.
The Ambition Reframe
Jones makes a point I keep coming back to: the least interesting thing you can do with a 10x productivity multiplier is cut headcount.
If each person on a five-person team now produces what previously required a department, the right question is not “how many people can I let go?” The right question is “what was I unable to pursue when headcount was the constraint, that I can now pursue because it isn’t?”
For Jacobian, the agent team handles execution work that would have required hiring into roles I can’t justify at current scale — dedicated SEO, consistent content production, full-time developer support. That work is now covered. What that frees up is the judgment work: the compliance advisory engagements, the doctoral research, the Chimo AI platform development.
The agent team didn’t shrink my organization. It expanded what my organization can do at its current size.
What This Series Has Been Building Toward
I started with the agent landscape not because it’s interesting as market overview, but because the landscape context determines which adoption decisions make sense for which organizations. The three-axis framework is not analysis for its own sake — it’s the structure that lets you evaluate options honestly.
I described the setup in detail because the setup is the prerequisite and its real complexity is systematically underrepresented in coverage. You can’t govern what you don’t understand. You can’t secure what you didn’t build carefully.
I described Sunday night in detail because seeing what cross-agent coordination looks like in practice is different from reading about it in principle. Atlas catching the brand voice violation, Beacon surfacing the schema opportunity, Forge diagnosing CI root cause and fixing it, Prism’s recommendations converging with Forge’s independent selection — these are specific behaviors from a specific production session.
And I’m ending with the team structure question because it’s where the real leverage is, and it’s the question most organizations aren’t asking carefully enough yet.
The organizations that do this well are going to have a compounding advantage over the ones that adopt reactively or not at all. Not because the technology is magic, but because the organizations that understand it deeply enough to deploy it correctly are the same organizations that understand it deeply enough to govern it — and governance is going to be the differentiating capability as AI adoption becomes universal and the gap between compliant and non-compliant deployments becomes visible.
That’s the case for doing this deliberately. And it’s why I spent several weeks building something I could have bought a simplified version of, and then wrote five posts about what I found.
The team structure framework I'm drawing on here comes from Nate Jones's analysis of the AI-era organization — worth reading in full:
