Roughly 15,600 developers from more than 1,400 companies have built the Linux kernel, described by the Linux Foundation as the largest collaborative project in the history of computing, and no manager ever assigned most of that work (Linux Foundation, 2017). The mechanism underneath that scale is stigmergy: coordination that happens through a shared environment instead of a chain of command. Ants use it. Termites use it. Well run teams use it too, usually without naming it.

Cross section of a termite mound with a glowing hot pink pheromone trail illustrating stigmergy coordination — Stigmergy is coordination left in the environment: a trace one worker makes becomes the instruction the next worker follows.

What stigmergy actually means

The French biologist Pierre-Paul Grasse coined the term in 1959, while studying how blind termites rebuild a nest they cannot see as a whole (Wikipedia: Stigmergy). The word joins the Greek stigma (mark) and ergon (work). It names a simple idea: the work already done stimulates the work that comes next.

Grasse noticed something that had looked paradoxical. Each termite behaves as if it is working alone, yet the colony produces coordinated pillars, arches, and chambers. His resolution was that the coordination does not live in the workers. It lives in the construction itself. In his words, the worker does not direct his work, he is guided by it.

A termite drops a ball of mud laced with pheromone. That deposit raises the local pheromone concentration, which makes nearby termites more likely to add their own mud in the same spot. Small heaps become pillars, pillars lean toward neighbors, arches form. No blueprint, no foreman, no meeting. The structure is both the output and the set of instructions.

Researchers now describe stigmergy as a generic mechanism for coordination that works across ants, termites, humans, and software agents alike (Wikipedia: Stigmergy). The common thread is indirection: agents never message each other, they read and change a shared medium.

How ants find the shortest path with no one in charge

The cleanest demonstration is the double bridge experiment run by Jean-Louis Deneubourg and colleagues around 1990. They connected an ant nest to a food source with two bridges of different lengths and watched what the colony did (Scholarpedia: Ant Colony Optimization).

At the start there is no pheromone, so roughly half the ants pick each bridge at random. The ants that happen to take the short bridge reach the food and return first. Their round trip lays pheromone on the short path sooner, which nudges the next ants toward it, which lays more pheromone, and the loop compounds. Within a short window most of the colony uses the shorter route (Scholarpedia: Ant Colony Optimization).

Two details matter for anyone running a team. First, the optimization is a byproduct of timing and feedback, not intelligence in any single ant. Second, the same setup with two equal bridges still produces convergence: the colony commits to one, roughly fifty-fifty across repeated trials, because early random noise gets amplified. Shared traces coordinate, and they also lock in whatever happened to go first.

Why this is the model for teams without managers

Most small teams cannot afford a layer of people whose job is to route other people's work. The interesting question is not how to add that layer. It is how to get the coordination without it. Stigmergy is the answer that scales down to two people and up to fifteen thousand.

The move is to stop treating coordination as something that happens in conversations and start treating it as something that lives in artifacts. A clean backlog, a current dashboard, a well named codebase, and honest documentation are pheromone trails. Each one is a trace that tells the next person what state the work is in and what to do next, without a synchronous handoff.

This is also why context switching is so expensive when the trail is missing. If the state of the work lives only in someone's head, every handoff requires interrupting that person, and the interruption itself carries a measurable recovery cost. I have written before about the real cost of context switching, and stigmergy is the structural fix: put the state in the environment so the next person reads it instead of asking for it.

Asynchronous work depends on the same principle. Being remote does not make a team asynchronous. Leaving good traces does, which is the distinction I drew in async first is not remote work. The trail has to carry enough state that someone can act on it hours later without you in the room.

The shared artifact is the coordination

Once you accept that the artifact coordinates, the loop is easy to see. An agent acts, the action changes a shared artifact, the next agent reads the changed artifact and decides what to do, and their action changes the artifact again. The environment carries the plan.

Horizontal flow diagram showing stigmergy: an agent modifies a shared artifact, the next agent reads it and acts, looping back — The stigmergy loop: work changes the shared artifact, the changed artifact instructs the next worker, and the cycle repeats without a central controller.

Compare that with the alternative most teams default to, which is coordination by meeting and message. Every state change has to be spoken, remembered, and re-spoken to whoever missed it. That model gets more expensive with each person you add, because the number of pairwise conversations grows faster than the headcount. Stigmergy stays flat: everyone reads the same trail regardless of how many people are on it.

The practical test for any tool or ritual is simple. Does it leave a durable, readable trace, or does the information evaporate when the call ends? A status meeting where decisions live only in memory fails the test. A pull request with a clear description, a ticket that captures why not just what, and a runbook that survives the person who wrote it all pass. This is the same reason institutional memory that survives turnover is an operational asset, not a nicety.

Open source is stigmergy at scale

Open source is the largest live experiment in coordination without managers, and it runs on stigmergy. The Linux kernel accepts changes at an average rate of about 8.5 per hour, which works out to more than 1,400 per week, contributed by thousands of developers who mostly never speak to each other (Linux Foundation, 2017).

What holds that together is not a project manager. It is the codebase itself, plus the issue tracker, the mailing list archive, the commit history, and the test suite. A contributor reads the current state of the tree, makes a change, and submits it. The change becomes part of the shared artifact that the next contributor reads. The tests are a trail too: a red build is a pheromone signal that says do not go this way yet.

Wikipedia works the same way. One editor leaves a rough article, which attracts corrections and additions from strangers, the way a mudball attracts more mud (Wikipedia: Stigmergy). The article is both the product and the coordination surface. This is worth remembering when you rely on open components: the same openness that lets the trail coordinate strangers is also a surface others can influence, which is the tension I explored in the AUR supply chain incident. Good traces coordinate, and they coordinate whoever shows up.

How to design artifacts that coordinate

If the artifact is doing the coordinating, then the quality of your artifacts is your operating model. A few principles hold up in practice.

Make the trace legible. A ticket titled "fix bug" leaves no usable signal. A ticket that states the symptom, the suspected cause, and the acceptance test tells the next person exactly where to add their mud. The goal is that someone who was not in the original conversation can act correctly from the artifact alone.

Keep the trail current, because stale traces mislead. A dashboard that shows last quarter's numbers is worse than no dashboard, the same way an old pheromone trail leads ants to food that is gone. Maintenance is not overhead here, it is the coordination itself, which is the argument I make in automation maintenance is the job.

Do not scatter the trail across a dozen surfaces. When the real state of the business lives in four SaaS tools and a group chat, there is no single environment to read, and stigmergy cannot function, a problem I unpack in your data lives in four SaaS tools and a group chat. Consolidating the trail is a precondition for coordination, and it is also the precondition for anything automated or AI driven to read reliable state, which is why data governance is the prerequisite for AI.

Where stigmergy breaks down

Stigmergy is not magic, and the double bridge shows its main failure directly. With two equal paths, the colony still locks onto one because early random noise gets amplified by feedback (Scholarpedia: Ant Colony Optimization). Teams do the same thing: an arbitrary early choice hardens into "how we do it here" long after anyone remembers why. Positive feedback that finds the short path can also entrench a bad one.

Two guards help. First, let evaporation happen on purpose. Real pheromone decays, which lets a colony abandon a route that no longer pays. The equivalent is retiring stale docs, closing dead tickets, and revisiting defaults so old traces stop steering new work. Second, keep some decisions off the trail. Irreversible, high-stakes calls should not be made by whoever moves first. Those deserve a deliberate human owner, which is exactly the class of work I argue you should never hand to an automatic process in the tasks you should never automate.

Used well, stigmergy lets a small team behave like a much larger one, because the environment does the routing. The teams that scale calmly are not the ones with the most managers. They are the ones whose artifacts are clean enough to coordinate the next person without a conversation. This is a core part of how we think about running systems at LTFI, and why we build for the developers doing the reading over at kief.dev.

Frequently Asked Questions

What is stigmergy in simple terms?

Stigmergy is coordination through a shared environment instead of through a central manager. One worker changes something (a pheromone trail, a document, a codebase), and that change tells the next worker what to do. The term was coined by biologist Pierre-Paul Grasse in 1959 to explain how termites build complex nests without any leader.

How does stigmergy apply to a team with no managers?

Treat coordination as something that lives in artifacts rather than in conversations. A clean backlog, a current dashboard, clear documentation, and a well named codebase act as trails: each one carries enough state that the next person can act without interrupting anyone. The better your artifacts, the less real time coordination you need.

Is open source software an example of stigmergy?

Yes. Projects like the Linux kernel coordinate thousands of contributors who rarely speak directly, using the codebase, issue tracker, commit history, and test suite as the shared environment. A contributor reads the current state, makes a change, and that change becomes the trail the next contributor reads and acts on.

What are the limits of coordinating through shared artifacts?

Feedback can entrench a bad path as easily as a good one, since early arbitrary choices get amplified. The fixes are deliberate evaporation (retiring stale docs, closing dead tickets, revisiting defaults) and keeping high stakes, irreversible decisions with a named human owner rather than letting whoever moves first decide.

What is the difference between stigmergy and just good documentation?

Documentation is one kind of trail, but stigmergy is the broader principle that the environment coordinates the work. It includes dashboards, tickets, tests, and code structure, and it requires those artifacts to stay current and legible. Documentation that no one updates is a stale trail, which can misdirect the next person rather than guide them.

Teams

What Ant Colonies Teach About Coordination Without Managers