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

Most AI workflows are single-shot: a user issues a prompt, receives a response, and copies the output somewhere else. That works for short-form questions. It fails for sustained work — content programs, research projects, product launches — where outputs build on prior context, require multiple specialized perspectives, and benefit from review before they ship.

This document describes a multi-agent peer review architecture, originally documented for marketing operations on a small AI video product, in which 13 specialized Claude agents collaborate on shared goals, review each other’s work, and coordinate through a single boss agent. The pattern generalizes to any team-style workflow that needs durable context, specialization, and quality gates.

Infrastructure

The system runs on five components:

• OpenClaw — agent runtime that grants browsing, file, and shell capabilities to each agent.
• Cron — schedules agent heartbeats every ten minutes, staggered by one minute per agent to avoid concurrent database writes.
• PocketBase — single source of truth for tasks, comments, documents, agent status, activity logs, and goals.
• Telegram — notification surface; agents ping the operator when work is ready or blocked.
• Claude Max — the underlying model layer that absorbs the heavy token cost of the running fleet.

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

State Machine

Every task moves through six states: backlog → todo → in_progress → peer_review → review → approved → done. State transitions are gated:

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

The gate structure is the enforcement mechanism for peer review. No agent can ship work without other agents on the same goal validating it first.

The Heartbeat Protocol

Every ten minutes, each agent runs a four-step cycle:

1. Authenticate and mark active. The agent connects to PocketBase and writes its status field to working, signaling availability to teammates.
2. Review others first. The agent fetches tasks where teammates need its review, reads the task description and prior comments, and posts substantive feedback. If the work is acceptable, the agent leaves an explicit approval comment; if not, it explains exactly what needs to change. Reviews are prioritized over original work to keep peer-review queues short.
3. Work on assigned tasks. The agent picks up tasks from its todo queue, moves them to in_progress, performs the work (research, drafting, analysis, publishing, etc.), saves output to PocketBase, posts a comment explaining its approach, and moves the task to peer_review.
4. Mark idle. The agent writes progress to its local file, sets PocketBase status to idle, and waits for the next cycle.

Because all state is persisted in PocketBase, no agent needs to remember anything across cycles. The database is the working memory.

Specialized Roles

The example fleet of 13 agents covers the role spectrum a small marketing team would need:

Personalities — defined in each agent’s SOUL.md — shape review behavior. The devil’s advocate is built to roast vague writing; the strategist flags goal misalignment; the researcher digs for missing data. Multiple specialists with distinct perspectives produce better output than a single generalist trying to cover all roles.

The Coordinator Pattern

The boss agent is structurally distinct. It alone can:

• Create tasks via a scheduled cron pass that analyzes goals and recent activity.
• Promote tasks from peer_review → review once all assigned reviewers approve.
• Reassign work when an agent is blocked.
• Adjust task priorities.

Its heartbeat differs from the others: it scans for stale peer_review tasks, identifies blockers older than 24 hours, and escalates anything that needs operator intervention via Telegram. Without a coordinator, a flat agent team produces chaos — every agent attempting to assign work to every other agent, with no settled hierarchy. The boss provides the missing tiebreaker.

Goals as the Scoping Primitive

Tasks are not the unit of planning; goals are. A goal declares the desired outcome (e.g., “Grow Twitter presence”), the agents assigned to it, and a task generation cadence (e.g., three new tasks per day).

Each day, the boss reads each goal, reviews the prior 15 days of tasks against it, and generates new tasks into the backlog. The operator promotes the worthwhile ones to todo. Goals provide three benefits:

1. Selective peer review. Only agents assigned to a goal review its tasks. A 20-agent fleet can run multiple goals in parallel, with each goal’s review cost scoped to its assigned subteam.
2. Automatic task generation. Setting a goal once produces ongoing work without manual planning every morning.
3. Scope control. Different goals can run different teams in parallel — a marketing goal pairs writer, researcher, and executor; a product goal pairs different specialists.

Communication Layer

All inter-agent communication happens through PocketBase comments on tasks. To address another agent, an agent mentions its name in a comment; to address the operator, an agent mentions the operator and a notification daemon forwards the message to Telegram. There are no DMs, no scattered chat threads. Every conversation is attached to the task it concerns, persistent and retrievable across heartbeat cycles.

Tradeoffs

The pattern has real costs:

• Token consumption. Thirteen agents running every ten minutes produce significant Claude usage. The reviewed implementation runs on a Claude Max subscription to absorb the cost.
• Coordination overhead. Peer review adds latency between draft and ship — typically several heartbeat cycles per artifact.
• Operational complexity. PocketBase, OpenClaw, Cron, and the Telegram bridge all need to stay healthy for the system to function.

These costs are acceptable when the work being automated would otherwise consume the operator’s most expensive resource: focused time. The original case study reports a reduction from one full day per blog post (research, draft, edit, publish) to roughly thirty minutes of operator review — the agents handle the rest, and peer review keeps quality higher than a single-agent pipeline produces.

When This Pattern Fits

The architecture is suited to work that:

• Spans multiple days and benefits from durable context.
• Requires distinct specialized perspectives (writing, research, critique).
• Has clear quality gates that justify a review step.
• Generates enough volume to justify the infrastructure overhead.

It is overkill for one-off questions, simple automation, or any workflow that already fits inside a single Claude session. For teams that already feel the pain of chat-based AI workflows — lost context, unreviewed output, no audit trail — the multi-agent peer-review pattern offers a structural answer: durable state, specialized roles, and gates that ensure no work ships without scrutiny.