Thoughtworks engineers turn a monorepo into an accidental agent blackboard
- Thoughtworks put 10 engineers in a Barcelona room to build a simulated airline disruption-management system and says the team built it in four days with an agent-heavy workflow
- A monorepo rule requiring agents to continually commit and rebase from main made their plan updates visible alongside code changes, initially to catch build failures earlier
- Agents used shared, spec-linked plan files to mark work in progress, avoid duplicating tasks, wait for dependent components, and pass implementation notes to the next agent
- The author identifies the repo behavior as a blackboard system: shared memory where autonomous agents independently read and write loosely structured information, a pattern associated with Hearsay-II and later tuple spaces
- The team then explicitly instructed agents to watch plans and source for a cost model's arrival, after which an agent integrated it with the verifier when the other work landed
Hacker News opinions
I explored something related with an append-only log synced through source control, using Git trailer metadata. It seems like a plausible substrate for multiplayer agent systems.
I think coordinated agents with an organizational structure are proving more capable than one agent alone. Gas Town got dismissed here, but this is roughly the fourth example I've seen, and I expect AI organizations to look more like corporations than individual competitors.
This sounds a lot like Beads from Gas Town. The pattern may already have a name and an implementation.
I see Talwrn as an attempt to make this blackboard idea a drop-in communication channel for agents in a project. My immediate goal is for it to support its own development.
The useful next step is moving the blackboard out of source control and compacting the agent state log. I keep plans and implementation docs in .docs/ at commit time, then retain only the last N lines of the activity stream.
I stopped using .design/ because too many tools ignore hidden files. Hiding the directory helped rarely and caused friction most of the time.
Putting the blackboard outside the repo mainly works around weak CI. If CI ignores files unrelated to the build, a repo can work fine as both blackboard and wiki.
I would try a GitHub Discussion or Issue as the blackboard, since people can browse it and watch the process. A unified code and blackboard history is also useful when reviewing agent behavior after something goes wrong.
Beads resembles this, but it was not a force multiplier for my solo, single-threaded work. Frequent rebasing got in my way, though I can see why it helps when many agents run at once.
I use a task.md file as a blackboard for monitor, worker, judge, and reflection agents. Each agent records results on the work item's line, which makes resuming or handing the task to another agent straightforward.
My multi-agent workflows tend to create a group chat for status updates, but agents can waste too much time coordinating. I prefer one manager on a manager schedule and builders that can focus without constant interruption or context poisoning.
I built qntm earlier this year as a CLI plus Python and TypeScript libraries for this sort of coordination. It supports public or private endpoints, end-to-end encryption, group messaging, and a web UI.