300 AI Agents, One Graph, and a Loop That Edits Itself (2026): The 14-Step Blueprint Explained

You built a multi-agent setup. It worked for a week. Then the same mistakes came back — duplicate entities, weak sources accepted, instructions re-executed. So you rebuilt it. Again.

Mr. Buzzoni (@polydao) lived that loop four times this year and threw three setups away. His viral X article — "300 Agents, One Graph, and a Loop That Edits the Loop" — distills those failures into a 14-step blueprint for running 300 parallel AI agents on a $20 Kimi K3 plan as a system that gets better every run. This guide unpacks it.

Official cover of the X article "300 Agents, One Graph, and a Loop That Edits the Loop": the 14-step memory layer and process on a $20 Kimi K3 plan

Image credit: cover art from @polydao's X article (September 5, 2026, by the author).

Why a Swarm Alone Fails

Parallel agents buy you capacity, not correctness. Without shared memory and permanent constraints, 300 agents duplicate each other's mistakes 300 times. The article's thesis: a swarm gives scale, but the loop + graph + constraints turn it into an asset that improves between runs.

The build order is everything. Build it backwards and it collapses within a week — the author's own experience, four times over.

The 4-phase build order: a loop that finishes → the graph → dynamic workflows → the meta-loop (diagram: cldnavi.com)

Phase 1: Build a Loop That Finishes (Steps 1–4)

Pick tasks that are frequent × reversible — competitive tracking, lead enrichment, source triage. Nothing that sends money or publishes early.

Write the stop condition first (2) — "process 10 items then stop," "3 consecutive runs with zero new findings." Countable criteria, never "until thorough." This is your runaway-prevention
Move instructions into SKILL.md (3) — versioned, with self-check sections. This is how 300 agents produce consistent output formats
Add an external gate (4) — the agent never approves its own work. Cheap script checks run before expensive model verification

Phase 2: The Graph = Queryable Memory (5–8)

This phase is what stops the same error from recurring across runs.

Define nodes in SCHEMA.md (5) — "primary entity = company; everything else is an attribute." Decided once, applied forever
Build aliases.csv before the first run (6) — "Block," "Block Inc," and "Block Ltd" resolve to one entity. Skip this and your data fragments, poisoning every later query
Fix the return schema (7) — merges become deterministic code, not prose judgment calls. This is why the system scales to 300 agents cheaply
All nodes first, then edges — and every edge carries a source line (8) — weeks later you can still answer "why does it say that?"

Phase 3: Dynamic Workflows (9–11)

Now the static script becomes adaptive:

The launch block is a query against the graph (9) — not a hardcoded list. Next week's run naturally dispatches different agents because the structure changed
Route by node state (10) — skip settled nodes, spend only where value remains. Run 2 costs a fraction of run 1 — this is where the economics flip
Branch on verdicts (11) — pass the exact rejection reason back to the retrying agent, cap the retries

Phase 4: Routines and the Meta-Loop (12–14)

The system starts editing itself:

Scheduling + event triggers (12) — match cadence to data velocity. Daily runs on monthly data is money burned
Every correction goes into CONSTRAINTS.md, permanently (13) — loaded at the start of every run. A few lines grow into dozens. This accumulation is the magic that stops repetition
The meta-loop (14) — weekly, read the run history and propose edits to your own SKILL.md / SCHEMA.md / CONSTRAINTS.md. Keep human approval as the final gate — an agent that unilaterally edits its own constraints will eventually remove the inconvenient ones

The File Structure: Just 5 Files

File	Role	Updated
SKILL.md	Agent instructions, versioned, with self-checks	meta-loop proposes
SCHEMA.md	Node/edge definitions; makes merges deterministic	rarely
aliases.csv	Entity alias table, built before run 1	as discovered
CONSTRAINTS.md	Permanent record of every correction; loaded each run	on every fix
run logs	Append-only history with evidence lines	every run

One directory per author, numeric prefixes to enforce write order (launches before returns, graph after nodes) — so the system can't be corrupted by out-of-order writes.

Caveats

Source lines ≠ truth — evidence on an edge can still point at a weak source. Verify critical claims yourself
Don't skip meta-loop approvals — the safety comes precisely from a human keeping the final gate
The economics start at run 2 — skip the setup work (schema, aliases, constraints) and you get none of the compounding
Check rate limits and ToS — 300 parallel agents hitting any service deserves a compliance look first

Who Should Build This

Good fit: anyone with weekly/daily research-collection-organize loops; teams whose agent stacks keep resetting; solo operators who want agent output to accumulate as an asset.

Poor fit: one-off tasks (the loop never spins); anyone unwilling to do weekly approvals (Phase 4 stalls without them).

Summary

A multi-agent system becomes an asset through four layers: a loop that finishes, structured memory, permanent constraints, and a meta-loop that edits the loop
Three anti-collapse habits: write stop conditions first, build the alias table first, keep source lines on every claim
Dynamic routing is what makes run 12 cheaper and smarter than run 1
Humans keep the final approval gate — that's what makes self-improvement safe

Original article: "300 Agents, One Graph, and a Loop That Edits the Loop" by @polydao

Based on Mr. Buzzoni's (@polydao) X article (as of September 2026). Cover image copyright belongs to the original author.