---
title: "Mr. Buzzoni on X: 300 Agents and a Loop"
url: https://stacklist.com/card/99eef9bc-41ec-4473-921e-575ed38def99
source_url: "https://x.com/polydao/status/2096128417108287566?s=12"
stack: https://stacklist.com/c/technology/stack/1659549d-373d-4391-ba12-5a14d40c19ed
summary: "PolyDAO presents a systematic approach to building scalable agent workflows using 300 parallel agents, graph structures, and self-correcting loops. The guide outlines 14 steps organized in phases covering task selection, stop conditions, skill documentation, gate validation, schema design, and deterministic merging for autonomous systems."
tags: "agent-swarm, workflow-automation, graph-engineering, loop-engineering, multi-agent-systems, data-validation, process-optimization"
key_entities: "Mr. Buzzoni (person), PolyDAO (organization), Kimi K3 (technology), Claude (technology), Agent Swarm (concept), Graph Engineering (concept), Loop Engineering (concept)"
classification: "tutorial"
content_hash: "sha256:2095dbb665103bf287b3069655fd99c6bc8d45fc4759a84b05a024815e9bc800"
acp_version: "0.2"
token_counts_approximate: 1964
visibility: public
agent_accessible: true
status: "final"
---

# Mr. Buzzoni on X: 300 Agents and a Loop

Mr. Buzzoni @polydao 300 AGENTS, ONE GRAPH, AND A LOOP THAT EDITS THE LOOP Loops, graphs, dynamic workflows and routines - in the order you should actually build them I have rebuilt the same agent setup four times this year and thrown three of them away. Each version worked for about a week. Then the corrections started repeating: the same duplicate company name merged into the wrong node, the same thin source accepted as evidence, the same instruction retyped on Monday that I had already typed on Friday. What ended that cycle was giving corrections a place to live. A system improves between runs when two things are true. Something carries forward, and something rejects work before it carries forward. Loop engineering gives you the first. Graph engineering gives the memory a shape you can query. Routines make it run without you in the room. Kimi K3's Agent Swarm supplies enough parallel capacity - up to three hundred agents on one problem - to make the structure worth building in the first place. Fourteen steps, in build order. Every one of them is a file you write or a rule you set, and none of them takes longer than an afternoon. Phase I · The Spine 1 · Pick the task by frequency times reversibility The first task decides whether the system survives its first bad week. You want something that recurs at least weekly, verifies in under a minute, and costs nothing when it comes back wrong. Frequency gives you enough runs to see a pattern. Reversibility gives you room to be wrong in public. Competitive tracking, changelog monitoring, inbound lead enrichment and source triage all qualify. Anything that sends, pays or publishes does not, at least not this month. 2 · Write the stop condition before you write the prompt Agent setups fail on the same axis over and over: they know how to start and have no idea when they are finished. Write the ending first, in a shape a machine can evaluate. A stop condition made of counts rather than adjectives is the difference between a loop and a runaway process. "Until the research is thorough" is not a stop condition. 3 · Move the work step out of the prompt and into SKILL.md A prompt is a sample of your intent. A file is the intent itself, versioned and reusable, and the swarm loads it before anything else. The self-check section is what keeps three hundred agents from returning three hundred formats. It is cheap, it runs inside the agent, and it catches the mechanical mistakes before they reach your gate. 4 · Add the gate, and make sure the agent does not control it An agent rereading its own output sees every reason it wrote things that way, so it approves. That holds for K3, for Claude, for every model on the board. A working gate has to be something outside the run. Run them in that order. The script is free, so it should reject everything it can before a single token gets spent on verification. Phase II · The Graph 5 · Decide what a node is, in writing One line in SCHEMA.md determines every question the system can answer later. A node is a company, or a person, or a filing, or a protocol. Pick one primary type per graph and treat the rest as attributes. Write it once and every future run against every market produces graphs that merge and compare the same way. 6 · Write the alias table before the first launch "Block", "Square" and "Block Inc" arriving as three nodes splits one cluster into three, and every query you run afterward inherits that error. Ten minutes of aliases.csv protects a run that puts three hundred agents in the field. It lives above the graph, not inside it, because it is an input to every future launch. Each duplicate that slips through gets fixed here once. 7 · Fix the return schema so the merge stays deterministic Three hundred agents replying in prose overflows any orchestrator you point them at. Three hundred agents replying in a fixed shape merge without a judgment call and cost a fraction of the tokens. 8 · Land every node before you draw a single edge A sequential tool notices connections on the way through and tilts the whole map toward whatever it read first. The swarm materializes the complete node set, then reasons across all of it at once. Keep that ordering, and give every edge a source line: The evidence field is what lets you walk a client through a claim instead of asking them to trust it. Phase III · Dynamic Workflows This is the phase people skip, and it is where a static automation turns into something that responds to its own state. 9 · Make the launch block a query, not a list A fixed list of forty companies is a script. A launch block that reads the graph first is a workflow, because next week it dispatches a different set of agents without you editing anything. That last clause is the whole point of having a graph underneath: the system ranks its own work by structural importance instead of by row order. 10 · Route by node state instead of running one path for everything This table is why the second run costs a fraction of the first. Skipping settled work is the entire economics of the setup. 11 · Branch on the verdict, and cap the retries Retrying a failure without telling the agent what failed is how a loop burns a budget on the same mistake. Passing the reason back turns a retry into a correction. Phase IV · Routines and the Review Loop 12 · Schedule it, then add the event trigger The schedule sets a floor and the event trigger handles the spikes. Match the interval to how fast the underlying data actually moves; a market that changes monthly does not need a daily run, and paying for one is the most common way people conclude that agents are expensive. 13 · Give corrections a permanent home in CONSTRAINTS.md This file is the reason the system improves rather than merely repeats. Every time you correct something, the correction goes here instead of into a chat message that disappears. Loaded at the top of every launch, three lines long at week one and thirty by month three. Each one is a mistake that will not be made again by any agent in any future run. 14 · Run the meta-loop that edits your own files The last step is the one that makes the whole thing self-improving. Once a week, one agent reads the run history and proposes changes to the files you own. Keep the approval step. An agent that can edit its own constraints without review will eventually edit away the constraint that was inconvenient, and it will be able to explain why that was reasonable. The Files, in One Place One author per directory. Numeric prefixes fix the write order, so returns never overwrite launches and the graph never overwrites returns. 40-runs is append only, because it is the file that answers "why does the graph say that" six weeks later. What It Costs and What It Pays The third one is the actual business. The steps do not change between domains; the schema and the alias table do. Anyone who has built two of these can build the third for someone else in a morning, and step 14 means the one they hand over keeps getting better after they walk away. The Short Version Steps 1 to 4 give you a loop that finishes. Steps 5 to 8 give it memory with a shape. Steps 9 to 11 let it choose its own work. Steps 12 to 14 make it run without you and rewrite its own instructions from its own failures. The first run is research. The twelfth is an asset, and the gap between them is four files you wrote in an afternoon. And if you found this useful: Save this article. The links change and new repos pop up weekly, you'll need this as a reference For weekly deep dives into AI architecture, quant trading, and the agent economy, follow me: @polydao Join the TG Channel: Buzzoni Notes - here I share my raw prompts, custom skills, and alpha that's too early for X 6:48 AM · Sep 5, 2026 229.3K Views 8 21 153 344