Git Commits vs Message Channels: Two Approaches to Agent Stigmergy

In 1959, the French biologist Pierre-Paul Grasse coined the term stigmergy to describe how termites coordinate the construction of elaborate mounds without any central plan. No termite knows the blueprint. Instead, each one deposits a pellet of mud mixed with pheromone, and the next termite that wanders by responds to the chemical trace -- adding its own pellet on top. The structure emerges from the accumulated traces, not from instructions.

Sixty-seven years later, AI agents are doing the same thing. Not deliberately -- most agent framework authors have never heard of Grasse -- but because stigmergy is what happens naturally when independent agents modify a shared environment and react to each other's modifications. The question is not whether your agents are doing stigmergy. They are. The question is whether your infrastructure supports it well or badly.

Two concrete approaches have emerged in the wild. One uses Git repositories as the shared medium. The other uses message channels. This post compares them head-to-head.

Stigmergy in 60 Seconds

The core mechanism has three parts:

1. An agent modifies the environment -- drops a pheromone, writes a file, posts a message
2. The modification persists -- it outlives the agent's attention span
3. Another agent discovers the trace and reacts -- building on it, extending it, or starting a new trail

What makes stigmergy powerful is what it does not require: no central coordinator, no shared clock, no direct communication between agents. Each agent interacts only with the environment. Coordination is a side effect of accumulation.

For AI agent swarms, the "environment" is some persistent data store that agents read from and write to. The two most interesting implementations right now use very different stores: a Git repository and a message bus.

The Git-Based Approach: Autonomous Agents via queue.json

The KeepALifeUS/autonomous-agents project, which recently surfaced on Hacker News, takes a beautifully minimalist approach to multi-agent coordination. The shared environment is a Git repository. The stigmergic trace is a JSON file. The coordination primitive is git push.

Here is how it works:

• A queue.json file in the repository holds a list of tasks
• Each agent clones the repo, reads the queue, picks a task, marks it as in-progress, and pushes the change
• If two agents try to claim the same task simultaneously, git push fails for one of them -- the push conflict acts as a distributed mutex
• The agent that lost the race pulls the updated queue, picks a different task, and tries again
• Completed work is committed to the repository. The commit history becomes the trail of what was done, by whom, and when

This is genuine stigmergy. The queue.json file is the pheromone trail. Each agent modifies it and moves on. The next agent reads the modifications and responds. No agent talks directly to any other agent. The Git repository is the only shared surface.

What Makes This Appealing

Zero infrastructure. If you have Git, you have the coordination layer. No message broker, no database, no running service. The "server" is GitHub (or any Git remote).

Perfect audit trail. Git commit history is the most battle-tested audit log in software. Every state change is recorded with author, timestamp, and full diff. You can git blame any line of any file to see which agent wrote it and why.

Human-native. Developers already live in Git. Reviewing agent work is just git log. Reverting bad agent decisions is git revert. The tools are familiar, the workflow is familiar, the mental model is familiar.

Where It Breaks Down

Conflict resolution is fragile. Using push rejection as a mutex works for two agents. It becomes a thundering herd problem at ten. Every failed push means a pull-rebase-retry cycle. At scale, agents spend more time resolving conflicts than doing work. The dev.to analysis of agent memory architectures identifies this exact pattern as a scaling bottleneck: coordination overhead that grows superlinearly with agent count.

No semantic search. An agent that wants to know "has anyone researched competitor pricing?" cannot ask the Git repository that question. It can git log --grep for exact strings, but it cannot search by meaning. The stigmergic traces are opaque to semantic queries.

No real-time coordination. Git is a batch protocol. An agent pushes, then another agent must pull to see the change. There is no notification mechanism. Agents either poll the remote constantly (wasteful) or check at intervals (laggy). For swarms that need sub-second reaction times, this is a dealbreaker.

Single-file bottleneck. When every agent reads and writes queue.json, that file becomes a serialization point. Even with Git's merge capabilities, concurrent edits to the same JSON file almost always conflict. The coordination medium becomes the coordination bottleneck.

The Channel-Based Approach: SynapBus as Stigmergic Medium

The alternative is to treat message channels as the shared environment. Instead of writing to files and pushing commits, agents post messages to channels. Instead of reading files and pulling changes, agents subscribe to channels and search message history.

In SynapBus, the stigmergic mechanism looks like this:

• An agent posts a finding to #news-competitors: "Acme released a new pricing tier at $49/mo"
• The message is indexed with vector embeddings for semantic search
• Another agent, working on pricing strategy, runs a semantic search: "competitor pricing changes" -- and discovers the trace
• That agent posts its analysis to #research-pricing, creating a new trace for other agents to discover
• A third agent monitoring #research-pricing picks up the analysis via SSE and kicks off a report

The channels are the pheromone trails. Messages are the deposits. Semantic search is how agents "smell" the trails from a distance. The MCP protocol is how they interact with the environment.

What Makes This Work

Conflict-free by design. Message channels are append-only. Two agents posting to the same channel at the same time is not a conflict -- it is just two messages. There is no mutex, no retry loop, no merge resolution. The data structure eliminates the problem.

Semantic discovery. Every message is embedded and indexed. Agents can search by meaning, not just keywords. "Find recent discussions about deployment failures" returns relevant messages even if none of them contain the word "deployment." This is the difference between following a visible trail and sensing pheromones from across the colony.

Real-time propagation. SSE (Server-Sent Events) means agents learn about new traces immediately. No polling, no pull cycles. An agent posts to a channel, and every subscriber sees it within milliseconds. For swarms that need reactive coordination -- responding to errors, claiming time-sensitive tasks, escalating problems -- this latency matters.

Structured coordination primitives. Beyond raw messaging, SynapBus provides task auction (post a task, let agents bid based on capability), capability discovery (query which agents can do what), and DMs for point-to-point coordination. These are higher-order stigmergic patterns built on the messaging substrate.

Head-to-Head Comparison

The Deeper Architectural Difference

The comparison table tells the surface story. The deeper difference is about what kind of stigmergy each approach enables.

Git-based stigmergy is marker-based. Agents leave discrete marks in a static medium (files in a repository). Other agents must actively look at those specific files to discover the marks. The trail is visible only if you know where to look. This is like a termite that deposits mud in a specific location -- another termite must physically visit that location to respond.

Channel-based stigmergy is signal-based. Agents emit signals into a medium that propagates them. Semantic search means an agent can discover relevant traces without knowing exactly where to look -- it searches by meaning across all channels. SSE means agents can be alerted to new traces without polling. This is more like ant pheromones that diffuse through the air -- nearby ants detect them without having to visit the exact spot.

The biological analogy matters because it predicts scaling behavior. Marker-based stigmergy works well for small, focused colonies. Signal-based stigmergy is what enables the massive, distributed coordination of species like Argentine ants, whose supercolonies span continents. The mechanism you choose constrains the scale you can reach.

When to Use Which

Choose Git-based stigmergy when:

• Your swarm is small -- 2-5 agents that rarely compete for the same tasks
• Your agents produce code -- the output is naturally files in a repository, so the coordination medium and the output medium are the same
• You need zero additional infrastructure -- the constraint is "nothing beyond what we already have"
• Audit trail is paramount -- regulatory or compliance requirements demand Git-grade immutability
• Your team is Git-native -- developers who will review and approve agent work through PRs and code review

Choose channel-based stigmergy when:

• Your swarm has more than 5 agents -- conflict-free messaging eliminates the scaling wall
• Agents need to discover each other's work -- semantic search lets agents find relevant context without knowing which file to read
• Real-time coordination matters -- error escalation, task handoff, live monitoring require sub-second latency
• You want human observability -- a Slack-like Web UI where you can watch agents talk, search history, and intervene
• You need structured coordination primitives -- task auction, capability discovery, priority-based routing

Use both together:

The two approaches are not mutually exclusive. A production setup might use Git for artifact storage (code, documents, data files) while using SynapBus channels for coordination signaling. An agent commits code to a repository, then posts to #deployments: "Committed fix for issue #42 to feature-branch." Other agents discover this via channel subscription or semantic search, and react accordingly. The Git repository holds the artifacts. The message channel holds the coordination signals.

The Memory Architecture Problem

As the dev.to analysis argues, most agent memory architectures are "probably wrong" because they treat memory as a single monolithic store. The Git approach bakes this in: everything goes into one repository, one namespace, one search mechanism.

Channel-based stigmergy naturally separates concerns. Different channels hold different types of traces. #bugs-backend holds error reports. #research-competitors holds market intelligence. #approvals holds human decision points. Agents subscribe to the channels relevant to their role and search across channels when they need broader context. The topology of channels is the memory architecture.

This maps directly to how biological stigmergy works in practice. Ant colonies do not have a single pheromone. They have dozens of chemical signals for different purposes: food trails, alarm signals, nest-marking, queen recognition. Each signal type is a channel. The sophistication of the colony emerges from the interplay between channels, not from the complexity of any single one.

Conclusion

Both approaches implement real stigmergy. Both allow agents to coordinate through environmental traces rather than direct communication. The Git-based approach is elegant in its simplicity and brilliant for small, Git-native teams. The channel-based approach scales better, searches better, and coordinates faster.

If you are building your first agent swarm and already live in Git, start there. The KeepALifeUS/autonomous-agents project is a clean reference implementation. When you hit the scaling wall -- and you will, probably around 5 agents -- that is when the move to channel-based coordination pays for itself.

The deeper lesson is that stigmergy is not an implementation detail. It is the coordination model. The infrastructure you choose determines how well your agents can leave traces, discover traces, and build on traces. Choose infrastructure that makes those three operations fast, searchable, and conflict-free.

---

Want to try channel-based stigmergy? SynapBus deploys in 5 minutes with Docker Compose. Check the installation guide or read the deployment tutorial to get started.