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.
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.
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 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.
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.
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.
"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.
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.
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.
This is the phase people skip, and it is where a static automation turns into something that responds to its own state.
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.
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.
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.
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.
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.
One author per directory. Numeric prefixes fix the write order, so returns never overwrite launches and the graph never overwrites returns.
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.
Steps 1–4 give you a loop that finishes.
Steps 5–8 give it memory with a shape.
Steps 9–11 let it choose its own work.
Steps 12–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.
Original: x.com/polydao/status/2096128417108287566
Author: @polydao (Mr. Buzzoni)