Agent Teams: Org Charts, Not Task Lists

When one bot stops being enough: roles, a coordinator, shared channels, and the discipline of small teams.

The most impressive Grok Bot projects share one shape: not a bigger bot, but several small ones with named jobs — researcher, writer, reviewer, dispatcher — coordinated like a tiny company. Here is how teams actually work, and the failure modes nobody warns you about.

Why teams beat one big bot

A single bot doing research, writing, and publishing holds three jobs in one context. Contexts blur: research style leaks into the writing, review becomes a formality (“looks good to me”), and every edit risks breaking something unrelated.

Split by role and three things improve immediately:

• Each prompt stays short — a researcher doesn’t need publishing rules.
• Review becomes real — a separate reviewer has no sunk cost in the draft.
• Failure is localizable — “the writer ignored the sources” names the culprit.

The minimal viable team

Two bots and a human:

• Worker — does the thing: research, draft, monitor, triage.
• Coordinator — runs the roster: wakes the worker, collects output, escalates only what needs you.

That’s it. Most “I built a company of bots” stories are this pattern repeated. Add specialists (writer, reviewer, scout) only when the coordinator’s job description starts growing compound sentences.

The org chart in practice

A role prompt per bot, ~10 lines each:

You are Scout. You find candidates matching config.md.
You never draft, never send, never decide. Output: a list,
each with source and one-line rationale. Max 10 items.

You are Chief. Your roster: Scout, Writer, Reviewer.
Every morning: wake each bot, collect outputs, compare
against jobs.md, and send me one report: done / blocked /
needs-me. You never do the specialists' jobs yourself.

The coordinator’s “you never do their jobs” line matters more than it looks — coordinators love to help, and a coordinator that rewrites everything is just a big bot with overhead.

Shared channels and files

Teams coordinate through the same primitives as single bots, just disciplined:

• A shared jobs board file (jobs.md) — status per task: queued, working, blocked, done.
• A report channel — one place where every bot files. Never DMs with individual bots for status; that’s how fleets go dark.
• A membership list — who exists, their role, their last-seen timestamp. The workforce checker pattern reads this file and notices when someone quietly quit.

Failure modes, honestly named

• Middle management bloat. Coordinators multiplying coordinators. Cap the org chart; if a bot’s only output is meetings, delete it.
• The silent quitter. A bot’s schedule died two weeks ago; nobody noticed because its report still arrives — from a stale run. Fix: last-seen timestamps in the roster file.
• Context duplication. Every bot carries a copy of the rules; the copies diverge. Fix: one rules file, read at every run, referenced by all.
• Review theater. The reviewer approves everything. Fix: give the reviewer explicit veto criteria and make it cite them.

When you don’t need a team

If the whole workflow fits in one prompt and one file, a team is overhead with extra steps. Teams earn their keep when roles need different instructions, schedules, or permissions — not before.