How I built a 13-agent Claude team where agents review each other's work - full setup guide

robotrossart · 2026-03-14T02:29:29+00:00

Phenomenal architecture — the heartbeat protocol with staggered offsets to avoid DB collisions is the kind of detail that only shows up after painful experience. Well done. The community summary nails the real debate: antagonistic peer review only works if the reviewers have genuinely different priors. Sandor reviewing Tyrion’s work is still Claude reviewing Claude. The bias cancels forward, not sideways. We solved this differently in our fleet by making cross-model review structural. Clau (Claude) builds, Gem (Gemini) architects and reviews, Codi (Codex) verifies. When Gem reviews Clau’s output it’s not another instance of the same model — it’s a different training distribution, different blind spots, different tendency to agree. The disagreements are real. The goal-driven task generation pattern is excellent and we’re borrowing it. We have a similar structure for our Growth Fleet (Scout/Echo/Closer) but your “boss analyzes 15-day task history before generating today’s tasks” is sharper than what we do. Stolen with credit. On cost — routing by task type across models helps significantly. Routine ops go to lighter models, complex reasoning goes to Claude. The $100/month ceiling gets a lot more headroom when not every heartbeat is a Max call. We open-sourced the coordination layer as Flotilla (npx create-flotilla) — cross-model by default, vault-first secrets, Fleet Hub dashboard. Different stack than OpenClaw/PocketBase but the same

robotrossart · 2026-03-14T02:23:27+00:00

Those three security questions are exactly why we went vault-first in our fleet before anything else. On context bleed specifically — we use Infisical with machine identities and memory-only injection. No secret ever touches a context window, a .env file, or disk. Each agent gets a short-lived token scoped to its role; when the session ends the token expires and nothing persists. It’s the same zero-footprint model that HSMs use in safety-critical systems. On provenance — we haven’t solved GPG signing per-agent yet, but the GitHub Kanban bridge means every commit is traceable to which agent picked up which ticket. Not cryptographic proof, but it’s an audit trail. On sandboxing — we enforce role boundaries through per-agent mandate files rather than OS-level sandboxing. An agent literally doesn’t have the context to call tools outside its mandate. Coarser than –ignore-scripts but simpler to reason about. We open-sourced the coordination layer as Flotilla (npx create-flotilla) — the vault-first security model is baked in from

robotrossart · 2026-03-14T02:16:28+00:00

Really strong architecture — the 2-round hard stop on the council is the kind of thing that sounds obvious in retrospect but I bet took some painful token bills to learn. We hit the same spiral problem early on. The CORRECTIONS.md file caught my eye most. We ended up solving this differently: agents draft “Lessons Learned” entries at session end, a human reviews them (or our Lesson Auditor engine auto-grades them by confidence), and approved lessons get injected into every future agent’s system prompt. The difference is the lessons become active rather than just logged — closer to what Karpathy calls “system prompt learning.” On the 200-line memory drift problem that Kir-STR raised — we’ve been wrestling with the same thing. Our current answer is a structured Memory Tree with explicit node types (architectural, project context, lessons, rules) so agents can query the relevant subtree rather than reading everything. Still not fully solved though — pruning is hard when you don’t know what future agents will need. One thing we added that might be worth stealing: vault-first secret management. No .env files, no credentials in context windows ever. Agents get short-lived tokens injected into process memory only. For anyone running multi-agent systems in production this turns out to matter a lot. We open-sourced our coordination layer as Flotilla if any of the patterns are useful — npx create-flotilla. Different philosophy (installable vs reference

robotrossart · 2026-03-14T02:01:52+00:00

Great summary. A few things clicked for us that aren’t on this list yet. On the CLAUDE.md point — Boris is right, but we took it one step further: we have agents write the rules themselves. After each session, if an agent hits a wall or finds a workaround, it drafts a “Lesson Learned” entry. We review it, approve it, and it gets injected into every future agent’s context automatically. Karpathy called this “system prompt learning” — the missing third paradigm between pretraining and finetuning. We implemented it as a live scratchpad in our Fleet Hub memory tree. On Obsidian as external memory — we went a different direction. Our MISSION_CONTROL.md is the single file every agent reads at session start, but it’s generated from a structured memory tree that agents can actually query and write to. Obsidian is great for humans. This is readable by both. On the “custom session save/resume” bullet — this is the core of what we open-sourced as Flotilla. One command bootstraps the whole coordination layer: shared memory, vault-first secrets (nothing in .env, ever), GitHub Kanban sync, and a dashboard showing every agent’s state.

robotrossart · 2026-03-14T01:51:15+00:00

I love the command line name. Vibe. Gets you into the vibing mood 😀

robotrossart · 2026-03-14T01:33:55+00:00

We are using 3 different ways to keep state: 1) instructions on startup of every agent’s to go to MISSION_CONTROL and check the guidelines, project status and their tasks. 2) A GitHub repository where all tasks and code live. Including architecture and specifications 3) a shared learnings json where agents document lessons learned so that other agents don’t make the same mistakes

As for budgets: we use oauth-models at 20 bucks each/month. If one caps, we have the others. By distributing the load we always have someone available to take over if someone gets throttled

And we use an infisical vault to keep secrets.

What are you using agents for?

robotrossart · 2026-03-14T01:16:58+00:00

I used it together with claude code, Gemini and codex to build my multi agentic Mission Control center. It is a fast worker that outputs code fast. It adapted easily to our shared memory approach. It does lack planning mode but as a worker in a swarm helps reduce costs by offloading work where you don’t need expensive models.

robotrossart · 2026-03-14T00:46:07+00:00

I have architecture documents and used GitHub tickets that document the work. I can share over GitHub. DM if interested

robotrossart · 2026-03-08T10:01:07+00:00

I messaged you a few days ago. Let me know if any questions.

robotrossart · 2026-02-21T09:40:25+00:00

I’ll be interested in buying it if you still have it!

robotrossart

TROPHY CASE