How to Build an AI Team (Coordinator + Specialists)

The 2026 published accounts of AI teams overlap enough to assemble a pattern from. Grok Bot's tutorials teach the chief-of-staff convention: one pinned coordinator Bot, specialists per lane. Allie K Miller says she runs 34 agents under one chief-of-staff agent and six functional directors, managing by escalation rather than supervision. Tom Blomfield's loop model contributes the other half: quality gates, a learning step, and humans providing direction at the edges. On the build side, where this site works, the coordinator-and-specialists architecture goes by a plainer name: a graph whose nodes are loops. Combining those overlapping accounts is our editorial synthesis, and it yields five parts: coordinator, specialists, shared memory, quality gates, human at the edges.

The overlap across independent accounts is the evidence this page rests on, and the most common early mistake we see is building the org chart before there is a single working agent. What follows is the build order we use, from running a fleet in production.

The Five Parts

• Specialists. One agent, one job, one written contract: what it does, what done means, what it must never do, when it stops and asks. The contract is the difference between a specialist and a prompt.
• A coordinator. Routes incoming work to specialists, holds cross-job context, escalates to you. In Grok Bot this is the chief-of-staff Bot; in Miller's telling, her chief-of-staff agent fields everything and delegates; in a built system it is an orchestrator node.
• Shared memory. Artifacts every agent reads before working and writes after: findings, decisions, state. This is what makes the team more than its members; agent memory is the deep dive.
• Quality gates. An executable check, or an adversarial reviewer that is not the producing agent, between output and the world. Blomfield's recommendation: the gate can often be a second adversarial model rather than a person. Ours: self-evaluation is a trap.
• The human edge. You set direction, decide what deserves to exist, and take escalations. Across the reviewed accounts, judgment stays at defined human boundaries, though the mechanism differs: Grok Bot uses approvals, Miller describes escalation-only management, and built loops use executable gates with escalation rules.

The Build Order We Use

1. Hire one specialist and make it boring. One recurring job, contracted, scheduled, gated. Do not proceed until it has run for a while without surprising you; a team of flaky agents is flakiness with an org chart. This unit is loop engineering, and it is deliberately unglamorous.
2. Give the team its memory before its second member. The shared store is cheapest to establish early, and it is what makes each new specialist cheaper than the last, because agent two starts with everything agent one learned.
3. Add specialists one job at a time. The temptation is to design the whole company of agents up front. Resist it: every agent you add is a contract to maintain and a new way for state to leak, so each one should be pulled into existence by a real job, not pushed by the org-chart fantasy. (Dylan Harris's graph-engineering formulation of the same rule: the goal is the smallest graph that improves quality.)
4. Appoint the coordinator last. Until several specialists genuinely need routing between them, you are the chief of staff, and you are better at it than an agent with nothing to coordinate. When the routing load is real, add the coordinator as its own contracted node, and give it the narrowest job that solves the actual problem: routing and escalation, not doing.
5. Watch the team, not just the work. A notable role in Miller's setup is an agent whose only job is watching the other agents for friction and missing access. The build-side equivalent is instrumentation: run logs, failure counts, and a periodic review of where agents got stuck. Teams degrade quietly; something has to be looking.

Six Published Rosters, and What Recurs Across Them

Since this page first ran, the people building teams on Grok Bot published their rosters in long form. Six describe a roster in enough detail to compare (all six are linked below and listed in this page's sources). They are the authors' descriptions of their own setups, not systems we have audited, and one is a docs-derived plan rather than a run log; we say which. They disagree on size and agree on most of the rules.

• Four Bots, one board (Akshay Pachaar): Piper the project manager, the only Bot allowed to write the board file, whose "most useful behaviour is rejection"; Bay on backend; Fin on frontend, who "never guesses at a response shape" and files a blocked task instead of a workaround; Tess the tester, who "never fixes what she finds. A Bot that patches its own findings stops reporting them." He caps the roster at four because "every extra specialist adds a handoff, which introduces a point of potential failure." This is the only write-up whose walkthrough shows a Bot stopping on a missing contract rather than inventing one.
• Three first, six planned (Nav; a docs-derived setup plan, no run output shown): a chief of staff (Klaus) that is "the single front door," a researcher (Scout) writing memos to Notion, a writer (Quill) saving drafts to Drive, each with the same closing line about never sending or purchasing without approval, and a rollout that starts with those three and adds specialists weekly toward a planned six (inbox, ledger, support). His warning: "50 bots per account is a ceiling, not a target."
• Six draft-only Bots for a solo founder (Paul Klay): support triage, scribe, signal miner, launch manager, money watch, outer loop, all with "never send" rules, and a direct argument against the org chart: "Ten bots you skim is worse than two you trust." Start with two.
• About ten under a chief of staff (Krista Letz, SpaceXAI): a pinned chief of staff that "owns meeting prep, inbox and post-call drafts, orchestrates the rest of the team," a prospecting Bot run overnight, one Bot per strategic account, a forecasting Bot, a slides Bot, a sales coach. Her maintenance tip is the one most rosters lack: periodically ask the chief of staff to audit every Bot and routine and "clean up unnecessary routines."
• One channel per project (Eric Zakariasson, official guide): a projects manager Bot with a Project Ops skill opens a channel and a Notion row per project and staffs it under three rules: reuse existing Bots first, propose at most five besides the manager, and create a new Bot "only when nothing on the bench fits, and only after I say yes." Stuck Bots mark a task Blocked and ping the channel. His own observation: "the more I build on this, the more it resembles a system initially built for humans."
• Chief plus four, with permission tiers (a playbook circulating as "the SpaceXAI PDF," which it is not): research, strategy, execution, reviewer under a chief, a seven-field mission contract, and a green, yellow, red ladder (read and draft freely; edit internal files inside approved tools; always ask before sending, publishing, purchasing, deleting, or changing production). Its rule for growth: "Add agents to remove proven bottlenecks, not to make the graph look impressive," and never schedule a routine until three consecutive runs pass.

The size split is clean: the one SpaceXAI insider describes about ten under a chief of staff; Paul Klay says he runs eighteen for his fund but publishes a six-Bot roster and argues for starting with two; the other authors land on three to six, and the docs-derived explainers put the noise threshold at "past four or five Bots." Our build order above sides with the small end, for the reason Paul Klay gives: every Bot is another output you have to read.

What recurs across several of them, with the source for each: the coordinator routes rather than produces (Akshay's Piper "writes no application code at all," Eric's manager "mostly watches progress," the playbook's chief "should not perform every task itself"; Krista's chief of staff is the exception, since it also owns her inbox and post-call drafts); state lives in files, and messages carry pointers (Akshay's board and task files, Eric's Notion databases, Paul Klay's state file of what was already reported); a fence on external actions in the Bot description (Nav's closing line, Paul Klay's "never send," the playbook's red tier, Akshay's blocked-task rule); and nothing goes on a schedule until it has run as a one-off task and been saved as a skill (the playbook's three-run rule, Paul Klay's routines built from tested prompts, and the product docs' own order). That is most of the five-part pattern above, rediscovered on one product. Note the two structural absences on the hosted side: there is no task object or board in the product (every roster builds one), and, per the teams documentation, no model picker, so a reviewer cannot be a different model from the producer, which is the one gate design a built graph can do and these rosters cannot.

Five Failure Modes

• Coordinator-first. The most common. An orchestrator with no working specialists is cost plus a new failure surface, producing nothing.
• Role-titled agents without contracts. Agents named for human roles instead of contracted for jobs. A "Head of Marketing" agent is a prompt; a specialist that drafts, gates, and ships one content pipeline is an employee. (The conference-talk version of this lesson: Subbiah Sethuraman and Abhilash Asokan of ZS Associates killed their multi-agent pipeline after building it to mirror the stages of a human analyst's workflow; they report context lost at handoffs, deterministic work handed to an LLM, and no agent owning the end-to-end conclusion.)
• Chatty coordination. If agents coordinate through long conversations rather than structured handoffs and shared artifacts, token spend scales with team size and coherence falls. This is also the documented failure pattern behind hosted-product limit burn.
• No gate between team and world. A team that ships whatever its members produce multiplies mistakes instead of catching them. Our rule is to require a gate at team scale, because mistakes now compound across agents. The inverse failure is the reviewer that repairs, as the chief-plus-four playbook puts it: "every task reaches Reviewer, Reviewer rewrites everything, and the entire graph develops a new bottleneck." A useful reviewer rejects precisely and sends work back; it does not become a second producer.
• Human in the middle instead of at the edge. If every task routes through your approval, you built a very expensive to-do list. Approvals belong on consequential actions; the rest belongs behind verifiers.

The Managed and Built Versions

If you want this shape without infrastructure, Grok Bot productizes the coordinator, specialists, shared context, and approval surface, with the trade-offs our buy-vs-build sort covers, and OpenBot open-sources the surface for self-hosters. A built system can implement the full five-part pattern, including executable gates, assembled from loops, a graph, shared artifacts, and gates. In our judgment the choice between them is about control and cost, not about which side has the working architecture.

The unit under every version of this, the one contracted specialist that runs on schedule and ships behind a gate, is what the Loop Engineering course builds. Hire your first agent there; the team follows.

Related Content

• Graph Engineering Guide (2026) - The architecture under the team: nodes, edges, shared state, and when coordination pays.
• Loop Engineering: Stop Writing Prompts, Start Writing Verifiers - Specialist number one, end to end.
• How to Become an AI-Native Company - The company-scale sequencing: which functions get a team first, and what breaks.
• Grok Bot: How to Use It - The managed version of this pattern, with the chief-of-staff convention and its limits problem.
• Who Owns Your AI Agents - Credentials, autonomy ladders, and offboarding for a team of agents with real access.
• How to Evaluate AI Agents - The gates: why self-evaluation fails and what to build instead.
• Grok Bot Templates - The rosters above as one-click installs, and how to vet one before it inherits your logins.

Join AI Builder Club