13-Agent Claude Team: A Multi-Agent Peer-Review Architecture

Most AI workflows are single-shot: prompt in, answer out, copy the result somewhere else. That’s fine for a quick question. It breaks down for sustained work — content programs, research projects, launches — where each output builds on earlier context, needs several specialized perspectives, and ought to be reviewed before it ships.

This is a peer-review architecture built for exactly that. Thirteen specialized Claude agents work shared goals, review each other’s output, and ship under the coordination of a single boss agent. It was originally documented for marketing operations on a small AI video product, but the pattern generalizes to any team-style workflow that needs durable context, specialization, and quality gates.

Infrastructure

Five components carry the system:

• OpenClaw — the agent runtime; grants each agent browsing, file, and shell access.
• Cron — fires agent heartbeats every ten minutes, staggered one minute apart so no two agents write to the database at once.
• PocketBase — the single source of truth: tasks, comments, documents, agent status, activity logs, and goals.
• Telegram — the notification surface; agents ping the operator when work is ready or blocked.
• Claude Max — the model layer that absorbs the fleet’s substantial token cost.

Each agent owns a workspace, a SOUL.md defining its role and personality, and a PROGRESS.md for local state.

The gate structure

Every task moves through a fixed pipeline: backlog → todo → in_progress → peer_review → review → approved → done. Transitions are gated by who may perform them:

• Only the operator promotes backlog → todo.
• Any assigned agent moves a task todo → in_progress, then in_progress → peer_review once its draft is done.
• Only the boss promotes peer_review → review, and only after every assigned reviewer has signed off.
• Only the operator promotes review → approved → done.

That gate — peer_review → review, boss-only, all-reviewers-required — is the enforcement mechanism. No agent can ship work without other agents on the same goal validating it first.

The heartbeat

Every ten minutes each agent runs the same four-step cycle:

1. Check in. Connect to PocketBase and set status to working, signaling availability.
2. Review first. Fetch tasks awaiting its review, read the description and prior comments, and post substantive feedback — an explicit approval if the work holds up, or a precise list of changes if not. Reviews come before original work, to keep review queues short.
3. Then produce. Pull a task from its todo queue, move it to in_progress, do the work (research, drafting, analysis, publishing), save output to PocketBase, comment on its approach, and move the task to peer_review.
4. Stand down. Write progress to its local file, set status to idle, and wait for the next cycle.

Because every bit of state lives in PocketBase, no agent has to remember anything between cycles. The database is the working memory.

Roles

The example fleet spans the roles a small marketing team would need:

Role	Function
Boss / coordinator	Creates tasks, promotes between gates, escalates blockers
Writer	Long-form content, threads, landing pages in a defined voice
Researcher	Web research, competitor analysis, data mining
Strategist	Campaign planning, positioning, goal-setting
Executor	Publishes content, runs automation, ships output
Designer	Briefs visual concepts and creative direction
Devil’s advocate	Brutal critique to surface weak claims, clichés, and drift

Personality — set in each agent’s SOUL.md — shapes review behavior: the devil’s advocate roasts vague writing, the strategist flags goal misalignment, the researcher digs for missing data. Several specialists with distinct viewpoints beat one generalist trying to wear every hat.

The coordinator

The boss agent is structurally distinct — it alone can create tasks (on a scheduled pass that reads goals and recent activity), promote peer_review → review once reviewers approve, reassign blocked work, and adjust priorities. Its heartbeat also differs: it scans for stale peer_review tasks, finds blockers older than 24 hours, and escalates anything needing the operator to Telegram.

Without a coordinator, a flat team descends into chaos — every agent trying to assign work to every other, no settled hierarchy. The boss is the tiebreaker that makes the structure hold.

Goals, not tasks, are the unit of planning

A goal declares a desired outcome (“Grow Twitter presence”), the agents assigned to it, and a task-generation cadence (e.g. three new tasks a day). Each day the boss reads each goal, reviews the prior 15 days of tasks against it, and drops new tasks into the backlog; the operator promotes the worthwhile ones. Goals buy three things:

• Scoped review — only agents assigned to a goal review its tasks, so a large fleet can run multiple goals in parallel with each goal’s review cost contained.
• Automatic work — set a goal once and it keeps generating tasks without daily planning.
• Parallel teams — different goals pair different specialists and run side by side.

Communication

All inter-agent communication happens as PocketBase comments on tasks. To reach another agent, an agent mentions it in a comment; to reach the operator, it mentions the operator and a daemon forwards the message to Telegram. No DMs, no scattered threads — every exchange is attached to the task it concerns, persistent and retrievable across heartbeats.

Tradeoffs

The pattern has real costs:

• Tokens. Thirteen agents cycling every ten minutes is heavy usage — the reviewed build runs on Claude Max to absorb it.
• Latency. Peer review adds several heartbeat cycles between draft and ship.
• Operational surface. PocketBase, OpenClaw, Cron, and the Telegram bridge all have to stay healthy.

Those costs are worth paying when the alternative consumes the operator’s scarcest resource — focused time. The original case study reports dropping from about a full day per blog post (research, draft, edit, publish) to roughly thirty minutes of operator review, with peer review holding quality above what a single-agent pipeline produces.

When it fits

Use this pattern for work that spans days and benefits from durable context, needs distinct specialized perspectives, has quality gates worth a review step, and generates enough volume to justify the infrastructure. It’s overkill for one-off questions, simple automation, or anything that fits inside a single Claude session. But for a team already feeling the pain of chat-based AI — lost context, unreviewed output, no audit trail — it offers a structural fix: durable state, specialized roles, and gates that keep unscrutinized work from shipping.