No ant has ever seen the colony. Each one reads pheromone trails left by whoever passed before, adds its own, and moves on. There's no foreman ant assigning tasks, no blueprint anyone consulted first. The nest gets built anyway — from thousands of tiny, local, asynchronous updates to a shared substrate.
That word — stigmergy — is the coordination mechanism: agents communicate by modifying a shared environment, not by messaging each other directly. I've come to think it's the right model for multi-agent knowledge systems too. I'm confident about that partly because this project is the cautionary tale that taught me the opposite pattern doesn't work.
The Cautionary Tale
Agentic Brewery's first real architecture pass wasn't small. Thirteen skills. Four agent archetypes. Seven hook events, wired and waiting. All of it built before a single real user had touched any of it — a complete org chart drawn for a company of one customer.
It wasn't a bad design on paper. It was premature — symmetric structure built for traffic that didn't exist yet, categories pre-filled before there was anything to put in them. Real colonies don't grow that way. They grow one ant, one trail, one delivery at a time. The trail gets reinforced because it's used, not because someone planned it into existence.
Five Principles
Rebuilding from that lesson, five rules held up across every system I've applied them to since:
- Stigmergy, not orchestration. No coordinator agent routing messages between workers. The shared substrate — files, frontmatter, timestamps — is the message bus. Agents read what's there and leave something for the next one.
- Asymmetric growth. Roughly 95% of a healthy system should be leaf content — individual notes, findings, claims. Only about 5% should be infrastructure. Resist pre-building view scaffolding or symmetric roles across domains before there's a reason to.
- Hub-and-spoke, no cross-spoke links. One hub holds the durable stuff — principles, taste, values — and doesn't multiply. Everything operational is a spoke, and spokes multiply freely. Spokes don't link directly to each other; anything that spans two of them gets promoted to the hub first, then re-expressed independently in each spoke.
- Asymmetric flow. Constraints flow down from the hub constantly — risk rules, kill criteria, taste. Synthesis flows up rarely, only when an operational insight actually changes a principle. There's no sideways flow between spokes at all.
- Pulse-check, not calendar-check. Live spokes update on trigger, not on a schedule. A research pass gathers dated findings; a separate pass pairs those findings with the structural domain knowledge that already exists, then writes the result back into the substrate. One does the news. The other does the physics. They stay separate on purpose.
Why the Foreman Doesn't Scale
Coordinator pattern
Every message routes through one node. It has to be taught about every domain before it can route for it.
Stigmergy pattern
Agents never message each other directly. The shared substrate is the only channel — no node has to be taught anything.
The instinct to build a coordinator agent is strong — it feels like control. But a coordinator is a single point of failure and a bottleneck disguised as architecture. Every spoke that wants to talk to another spoke has to go through it. Every new domain needs the coordinator taught about it first. Stigmergy routes around all of that: the substrate doesn't need to be taught anything, because the agents read and write the same files everyone else does.
The tradeoff is real — you give up centralized visibility for decentralized resilience. For a knowledge system that needs to keep functioning between sessions, with no single agent watching the whole thing at once, that tradeoff is the right one.
The First Real Colony
The pattern proved out on the first domain I applied it to deliberately: a research vault tracking a specific technical claim over time. A pulse-check agent ran periodic sweeps for new dated evidence; a separate pass paired those findings against the underlying thesis and sharpened the kill criteria each time. No orchestrator. No calendar. Just a trigger, a substrate, and a rule about what gets promoted where.
The Trail Already Exists
The mistake I made the first time wasn't ambition — it was sequencing. I built the fence before there was a trail to put it around. The better question, every time, isn't "what categories should this system have" but "what's already happening that I should be encoding." The colony exists before you design for it. Your job is just to notice which trail is real.