Stigmergy
Treat your team like a bunch of insects?!
Why has the industry decided large teams don’t work? Well, that’s because we say that everyone needs to talk to everyone else, and that doesn’t scale very well. The solution is to split teams up into small units, each one with a discrete focus and arrange them so that they either don’t have to talk to each other, or if they do it’s via well thought out methods (or more likely, it’s via a series of unfortunate meetings).
And now, everyone is a manager with a fleet of agents at their disposal (not to mention the autonomous ones spawning off). So is the solution more communication (stand-ups, Slack, the dreaded alignment meeting) or is it something different entirely?
OK, let’s go off at a tangent. Insects build things too. There are gazillions of the buggers, and they don’t decide what to build by having meetings. Insects get shit done, but how?

Stigmergy
In 1959, Pierre-Paul Grasse explained how termites coordinate to build complex mounds with no blueprint or leader.
A termite drops a pellet of soil; the pellet changes the local environment. The changed environment triggers the next termite’s action. No direct communication needed, just shape the environment instead.
Stigmergy is formed from the Greek for “mark” and “work”. Work that leaves a mark that provokes work.
I won’t try and explain it any better than that (since I can’t!). But in the termite world coordination is not a property of the termites, it’s a property of the environment they share.
You can get sophisticated collective behaviour out of very stupid agents, providing the environment is rich enough (see Emergent Algorithms for some fun examples). The opposite is also true, you can get chaos out of very smart agents in a poor environment (see any cubicle-based environment).
Stigmergy sounds attractive. Direct communication scales badly, whereas stigmergic signals scale with the artifact not the population. A README file in the environment costs the same to maintain whether it’s for one reader or thousands.
Pac-Man (or so many tangents you’ll get whiplash)
You’ve played Pac-Man right?
Think about how you’d write an algorithm for the ghosts that chase Pac-Man.
I suspect your answers immediately dives for an algorithm. Let’s do some pathfinding. We’ll give each ghost a map, run some A* algorithm and recompute every tick. And then somehow we’ll bodge the ghosts not converging on the same corridor.
An alternative to this is stigmergy; how can we shape the environment so that the ghost algorithm is simple?
Collaborative Diffusion: Programming Antiobjects shows how. This is one of my favourite papers because of the ah-ha moment you get when you see how simple the algorithm is (and the cognitive biases that seem to get engineers to try the hard way first).
Pac-Man emits a scent value. Every open tile diffuses it, averaging from its neighbours. Walls return nothing, so the scent flows round corners rather than through them. A ghost moves to whichever neighbouring tile smells strongest. That’s the whole algorithm.
The corridor problem solves itself. Ghosts don’t diffuse the scent either, so a ghost standing on a tile blocks it. The gradient behind that ghost goes flat, and the next ghost finds a different route more appealing. They spread out and cover the maze. Repenning calls it collaboration by goal obfuscation. No ghost knows the other ghosts exist.
Repenning uses the anti-object to describe this, the thing you assumed was passive is where the computation lives.
The ghosts got dumber, and the system got smarter.
Your codebase is a maze
Think of an AI agent as a ghost. The ticket is Pac-Man. Your job isn’t to get a smarter ghost, it’s to shape the maze so that each signal triggers the next action without you having to say anything.
You already do this. You just do it for humans.
Failing test - gets fixed without anyone asking
CI red - a wall between the work and production
Type signature - removes the need to ask what the function does
Lint rule - a code review comment you only have to write once
Index card on a board - work in progress limited without a meeting about it
ADR - intent recorded rather than relitigated
None of that is new the only change is who’s reading (an agent) and the scale.
The catch is that a signal only counts if the agent can read it. In one of my first management roles I tried to prioritize by putting index cards on a board, highest priority at the top. This almost worked, but one person on my team was constantly working on lower priority items. Lesson learned. Don’t put things out of reach of the shortest developer 🤦
What can go wrong?
When an ant turns around it inadvertently creates circles of pheromones, leading to this rather disturbing death spiral (original video).
If the environment you shape ends up contradicting itself, you can get problems! You’ve got to invest the effort in keeping your environment up to date. Those forgotten wiki pages that point to a design that was relevant 18 years ago are going to bite you.
What to do with this?
With my standard caveat of no silver bullets.
Be the termite - what would this environment (repo, meeting) tell a stranger what to do next with no access to humans?
Convert conversations to constraints - every repeated code-review comment is a lint rule you haven’t written. Every recurring meeting is a signal you could have shared.
Audit meetings for transmitting state - These should be artifacts, not multi-person meetings
Invest in gradients, not maps - You don’t need every agent to know everything, you just need the next action to be obvious from the current one.


Reminds me of the opening chapter of Egan's Diaspora https://www.gregegan.net/DIASPORA/01/Orphanogenesis.html