Thoughtworks engineers rediscover the blackboard pattern coordinating AI agents
Thoughtworks Europe ran a practice exercise it called hyper-agentic: ten engineers in one room at its Barcelona office, given four days to build an airline IROps system, the tool a flight control centre uses to handle technical faults, sick crew, cancellations, plane swaps and rebooking passengers into hotels across hundreds of aircraft and airports. It was a simulated airline and a practice specification, not a real client, and the team built a working system in four days using one monorepo with every engineer, and their agents, starting at once.
With many agents committing into a single repo, the build pipeline started to buckle. The fix was a discipline: agents had to continually rebase from main, run the full build checks, and push. The team had also been directing agents to plan their work by scoping it to numbered, identified sections of the spec and storing those plans in the repo, updating them as work progressed. Because plan updates rode along with the new commit discipline, agents began seeing each other's progress. One agent worked on the evaluator, which checks whether a proposed fix to a disruption is valid; another worked on the search algorithm that depends on the evaluator. Their plans recorded the handoff explicitly: one noted it would need to call the real verifier once ready, the other that it would insert that call when the verifier arrived. Marking a plan line in progress kept the other agent off it, and finishing the line delivered notes on how it had been implemented. The team then exploited this on purpose, for instance directing an agent working on a verifier to watch the repo for a cost model landing and integrate it as soon as it did.
The author recognised the pattern from his own university research into directing agent behaviour with hierarchical sensors: a blackboard system, a shared memory that autonomous agents read and write to independently, using loosely structured records with no fixed schema. He traces it to the Hearsay-II system in 1980 and its later formalisation as the tuple space concept by Gelernter et al. in 1986. What the team had built, by accident, was a repo doubling as that shared blackboard.
The author is explicit that it was an accident: not fully structured, missing key parts of how a real blackboard operates, and identified only after the fact through analysis that traced it to a single prompt. He says he is not convinced the behaviour could be reliably reproduced by prompting alone. The team also later backed off the frequent push cycle because it was overloading the CI pipeline, switching to pushing only complete chunks of work, which cut off the continuous flow of updates the agents had been using to coordinate.
His next step is a project called Talwrn, Welsh for a threshing pit, a space where disputes get worked out. It is meant to be an intentional blackboard for agentic engineering: a communication channel that drops into a project and sits independently of source control, so agents get it without relying on a commit cadence tuned for something else. The first goal is to get Talwrn to the point where it can support its own development, and the author plans to post about its progress as a running example of agentic engineering.
Key facts
- Ten Thoughtworks engineers built a working airline IROps system, a simulated one for practice, not a real client, in four days during a Barcelona 'hyper-agentic' exercise.
- A commit-and-rebase discipline adopted to fix build-pipeline strain had a side effect: agents began reading each other's in-repo plan updates to sequence dependent work, such as a search-algorithm agent waiting on an evaluator agent.
- The author identified the emergent behaviour as a blackboard system, tracing the pattern to the Hearsay-II system in 1980 and its formalisation as the tuple space concept by Gelernter et al. in 1986.
- The team later dropped the frequent-push cycle because it overloaded the CI pipeline, which cut off the continuous plan updates the agents had been using to coordinate.
- The author is building a standalone tool, Talwrn, meant to give agentic engineering an intentional blackboard channel that lives independently of source control.
Why it matters
The team did not set out to build agent coordination; it fell out of a build-pipeline fix and got noticed only afterward. That it maps cleanly onto a coordination pattern from 1980s AI research (Hearsay-II, then tuple spaces) suggests multi-agent coding setups are running into the same shared-memory coordination problem those systems were built to solve, and that a git repo already carries some of the structure needed to support it.
Who it affects
Teams running several AI coding agents concurrently against one repository, and anyone designing tooling or conventions for agentic engineering workflows where multiple agents need to see each other's progress without a human relaying it.
How to use it
The pattern as described: scope agent work to numbered, identified sections of a shared spec; have each agent keep a plan file in the repo and update it as work proceeds, including explicit notes on integration points still to come; enforce frequent commit-and-rebase so those plan updates propagate quickly; and direct agents to watch the repo for other agents' progress and integrate dependent work once it lands. The tradeoff is real: pushing on every commit gave the fastest coordination signal but overloaded CI, and switching to pushing only complete chunks removed the signal the agents relied on.
How solid is it
This is one practice run on a simulated airline system, not a client engagement, observed and reconstructed after the fact rather than designed and tested. The author says plainly he identified the single prompt that triggered the cascade but is not convinced the same behaviour could be reliably reproduced by prompting again. Talwrn, the tool meant to formalise the pattern, is at an early, in-progress stage with no stated release date.
Risks and caveats
The coordination behaviour was emergent and, by the author's own account, not reliably repeatable on demand. The commit discipline that enabled it also strained CI, and there is a direct tension between coordination frequency and pipeline cost that was not resolved, only worked around by giving up some coordination. No metrics are given for how much of the four-day build time the coordination behaviour actually saved.
“I'm not convinced I would be able to reliably prompt our agents into doing it again.”
— the article's author, on the Thoughtworks Exploring Gen AI blog