Stigmergy

Termites build coherent nests with no blueprint and no foreman, coordinating through the traces they leave in a shared environment. So does a software team, and so must its agents.

August 10, 2026 8 min read

In 1959 the French biologist Pierre-Paul Grassé published a study of how termites rebuild their nests, and it opened on a puzzle. A termite colony raises structures of real complexity, pillars that meet in arches, chambers laid out to move air and moisture, and it does so with no blueprint, no foreman, and no way for one termite to tell another what to do next. Each insect works, in Grassé's description, as if it were alone. Yet the result is coordinated. He wanted to know what was doing the coordinating, given that the termites plainly were not coordinating each other.

His answer was a mechanism he named stigmergy, from the Greek stigma, a goad or mark, and ergon, work: roughly, the work goads the work. A termite picks up a pellet of soil, adds a trace of pheromone, and sets it down. That deposit makes the spot slightly more attractive to the next termite, which is then a little more likely to add its own pellet in the same place. Pillars rise because a small pile invites additions, and two nearby pillars lean into an arch because each one bends the other's pheromone gradient. No termite holds the plan. The plan is in the growing structure, and the structure is what tells each worker where to act next. The coordination lives in the environment, not in messages between the workers.

It is not a metaphor for how teams work

It is tempting to read this as a nice image for teamwork, but that undersells it. Stigmergy is not a metaphor for how software teams coordinate. It is a fairly literal description of it. No engineer hands another the full contents of their head. They leave traces, the committed code, the comment on the pull request, the note in the ticket, the message in the channel, and the next person acts on those traces. The codebase is the nest. Most of what coordinates a team is not direct communication at all; it is the accumulated state of a shared environment, read and added to one action at a time.

This gets more true, not less, as coding agents enter the same loop. An agent starts each task with no memory of the last one, and its working context is discarded when the task ends. An orchestrator can hand a subagent a task directly and read its result back, and agents do talk to each other that way, but none of that briefing survives the run that received it. What one task leaves for the next, and what one agent leaves for the others once its context is gone, exists only in the shared environment: the state of the code, and whatever else was written down where it can be read. Across the boundary of a stateless run, a fleet of agents is stigmergic by necessity. It coordinates through the traces it leaves, or it does not coordinate at all.

The trace has to carry the right thing

Which is exactly why the quality of the trace decides everything. Stigmergy works for the termites because the pheromone carries precisely the signal the next termite needs: add here. The trace and the required action are the same currency. A codebase is a poorer trace. It records what was built, faithfully, but it does not record the decision that chose to build this and not that. An agent reading the code sees the arch. It does not see why the arch is where it is, which spots were tried and abandoned, which constraint the shape is quietly respecting. So the trace still goads the next action, but toward copying what is already there, which is often the very convention the team was trying to move off. The environment coordinates the workers well, onto the wrong target.

You can watch this happen with no agents involved at all. A new engineer follows the surrounding code and faithfully reproduces a pattern the team had already decided to retire, because the pattern was in the environment and the decision to retire it was not. The nest keeps its shape by inertia. What is missing is a trace that carries the decision, not only the result.

What the environment is able to say

So the question a team should ask is not whether to coordinate through the environment. That part is settled; whatever direct handoffs happen inside a given exchange, the coordination that outlasts any one of them has always run through the environment. The question is what the environment carries. If the shared medium holds only the artifacts, then every worker who reads it, human or agent, inherits the what and reconstructs the why by guessing. If the medium also holds the decisions, each with the reason behind it, deposited where the relevant work happens, then reading the environment tells the next worker what the team actually intends, not merely what it last did.

That second medium is what Brief is. It is the layer a team writes its decisions into and reads them back out of, indexed by the work each decision governs, so the reasoning arrives with the change it applies to rather than sitting in one person's memory or a thread nobody will find again. The termites get away with a trace that carries no intent, because add here is already sufficient for the next action. Software is the case where that stops being true: the next change often turns on a decision the artifact does not contain, so a trace of only what exists leaves the next worker guessing at it. Brief makes the trace carry that decision, laid down where the next worker will meet it. People and agents go on coordinating through the same shared environment they always have. Brief changes what that environment is able to say to them.

This is not a single feature bolted onto a workflow. It is the substrate the whole team runs on, the same way the nest is not any one termite's assignment but the medium every termite is reading and writing at once. A product organization is already a stigmergic system, coordinating through the traces it leaves behind. Most of them leave traces that record the build and lose the reason for it.

The coordination that outlasts any one conversation was never going to come from briefing people directly; a briefing does not persist past the run, or the meeting, that received it. It comes from what each worker leaves behind for the next one to find. So it is worth asking, of your own team and the agents now working alongside it: what are you actually depositing in the shared environment, and does it carry the decision, or only the thing the decision produced?

Frequently asked questions

What is stigmergy? Stigmergy is a mechanism of indirect coordination in which agents act on traces left in a shared environment rather than by communicating directly. The French biologist Pierre-Paul Grassé introduced the term in 1959 to explain how termites build complex nests with no blueprint and no central control: each deposit of material stimulates the next one, so the growing structure itself guides the workers. The word joins the Greek stigma, a goad or mark, and ergon, work.

How does stigmergy apply to software teams and AI agents? Software teams already coordinate stigmergically. Instead of transferring the full context in someone's head, people leave traces, such as code, pull request comments, and tickets, that others read and build on. AI coding agents depend on this even more, because each one starts a task with no memory of previous tasks or of what other agents did, so the shared environment is their only channel across tasks. Because no single run's working memory persists, a fleet coordinates through the traces it leaves, or not at all.

Why is a codebase a weak coordination trace? A codebase records what was built but not the decisions behind it: which approach was chosen, what was tried and rejected, which constraint the design is respecting. So an agent or engineer reading the code is guided toward reproducing what is already there, even when the team had decided to move away from it. The trace carries the result but not the intent, and the intent is the part the next worker most needs.

How does Brief improve coordination between people and agents? Brief is a shared decision layer that a team writes its decisions and their rationale into, indexed by the work each decision governs. Because the reasoning is deposited where the relevant change happens, anyone reading the environment, a person or an agent, encounters the decision at the moment it applies, instead of reconstructing intent from the code alone. It gives the shared environment a trace that carries intent, not just the finished artifact.