An Accidental Blackboard

Refactoring
Agile
Architecture
About
Thoughtworks

Topics
Architecture
Refactoring
Agile
Delivery
Microservices
Data
Testing
DSL

about me
About
Books
FAQ

content
Videos
Content Index
Fragments
Board Games
Photography

Thoughtworks
Home
Insights
Careers
Radar
Engineering

follow
RSS
Mastodon
LinkedIn
Bluesky
X
BGG

An Accidental Blackboard

Giles Edwards-Alexander

Giles is CTO for Europe, Middle East and India at
Thoughtworks. He has over 25 years experience in engineering and
technology leadership across technologies from mobile to AI and
industries including retail, fintech and
healthcare.

This article is part of “Exploring Gen
AI”. A series capturing Thoughtworks technologists' explorations of using gen ai technology for
software development.

02 September 2026

This week, across Thoughtworks Europe, we took 10 engineers and put
them in one room in our Barcelona office. The goal was to see how far
and how fast we could go if we really leant into agentic
engineering. We called it hyper-agentic. Along the way, we
accidentally re-discovered something about coordinating agents.
The 10 engineers were given the goal of building an airline IROps
system. This is the system that airlines use in a flight control
centre when something goes wrong. When a plane has a technical fault
that needs to be repaired. When a crew member gets sick and the crew
needs to be replaced. It’s how they decide which flights to cancel,
which planes to swap, which passengers get offloaded and put into
hotels, etc. etc. They’re doing this over hundreds of aircraft,
hundreds of thousands of passengers and many, many crew across
multiple stations and airports. It’s a really, really hard problem,
hard to solve, hard to execute. An IROps system is complex to build,
complex to understand, and complex to use.
We managed to build one in four days. But this post isn’t about how we
did that.
We started with a specification and a simulated airline, because this
was a practice exercise, not a real client. We tried a couple of
things just to see what would and wouldn’t work. We used a
monorepo. All the engineers began working at once. We just got
started, and after a couple of days we began to see things happening
in interesting ways, things emerging.
Emergent behaviour from tuning our approach
With lot of agents working in one repo, build pipelines suffered. To
deal with this we introduced a discipline: our agents were to
continually commit and rebase from main. At first, we required a
rebase after commit and to then push, with all of the build checks and
controls in place. We introduced this change to catch build failures
locally: integrate early and often. But, there was a side-effect. We
were directing the agents to plan, to scope work to sections in the
spec and to create plans linked to those sections. These plans were
stored in the repo. All agents were working off the same spec using
the same numbered and identified sections. As agents worked, plans
were updated to record progress. These updates, alongside all others,
were swept up with the new commit discipline. Agents were able to see
other agents’ progress.
So, one agent was, say, working on the evaluator, the component to
determine if a particular plan to restore operations is valid, whether
it breaks hard constraints or soft constraints, etc. At the same
time another agent was working on the search algorithm that looks for
plans that could solve the disruption. The search component depends on
the evaluator. Each component can be written together, but there is a
shared interface and search depends on the evaluator.
The plans recorded these integration points. One plan said at this
point I’m going to need to update the callers to call the real
verifier. And on the search side, it said, at this point I need to
insert the call to the real verifier when it arrives. Both agents
could see each plan, and the progress. We realised that the agents
were using the plans to coordinate. One agent would mark a line of the
plan as in progress, the other agent would see that and not work on
that line. When the first agent finished, the other agent would see
not only that the work was complete and thus it was released to
proceed, but would also be directly delivered notes on how the line
had been implemented.
We started to exploit this. We’d kick off a session and direct it to
work on a particular journey. One example was to introduce a cost
model alongside the verifier. Knowing that someone else had been
working on the cost model and pushing commits continually, we directed
the agent working on the verifier to look at plans and source, monitor
the repo, and when the work for the cost model lands start to
integrate it. And it did.
This was entirely ad hoc. It was an accident of a series of
decisions. We saw it happen. And then started to use it.
The repo as an accidental blackboard for agents
There’s a name for the pattern our agents had discovered: a
blackboard system. This was something I explored back in my
university days. My research thesis was in directing agent behaviour
with hierarchical sensors. I was looking at applying modern machine
learning techniques of the time, such as reinforcement learning,
across large, dynamic datasets. Looking back over the literature, I
adopted the blackboard pattern as the core coordination
structure. This had previously been discovered in the development of
the Hearsay-II system in 1980. It had been subsequently been
developed into the more formal tuple space concept by Gelernter
et al. in 1986.
A blackboard or tuple space is a shared memory that autonomous agents
can read and write from independently. They read and write tuples with
a certain minimum structure, and then as many extra fields as you
want: no schema. It’s a very effective technique for coordinating
autonomous problem solvers towards a single goal. They can each solve
a decomposed part of the problem, drop their solution into the shared
space, label it, and other autonomous searchers will find it, pick it
up, and use it as part of their work.
We had accidentally prompted our agents to start using our repo as a
blackboard. But it was an accident. It wasn’t an intentional act. It
wasn’t fully structured. It was missing some of the key parts of how
blackboards operate. And because it was accidental, I’m not convinced
I would be able to reliably prompt our agents into doing it
again. I’ve got a pretty good idea what we did, because we did some
analysis and identified the single prompt that caused this cascade to
start happening. But it was an emergent behaviour. It wasn’t a
directed behaviour.
As well as creating this intentionally, rather than accidentally, I
believe you want this communication channel to be sitting
independently of source control. While we created it by directing a
frequent push cycle, we backed-off from that. The frequent commits
were overloading our CI pipeline. We switched to only push when a more
coherent chunk of change was complete. This deprived the agents of the
continuous flow of updates on progress.
A good accidental solution requires a good intentional project. I’ve
started working on a project I’m calling Talwrn. That’s Welsh for a
threshing pit, an area or space where arguments and conflict get
worked out. This is aiming to be a blackboard for agentic
engineering. My goal is a very simple to use tool that drops straight
into your project and immediately offers a communication channel for
agents to coordinate work. The first step is to get Talwrn to a point
where it can support its own development. I’m planning to post about
it regularly as I’m hoping to use it as a single, evolving example of
how pure agentic engineering can proceed.

latest article (Sep 02):
An Accidental Blackboard

previous article:
TDD inside the agent loop - theater or actual value?

Topics
Architecture
Refactoring
Agile
Delivery
Microservices
Data
Testing
DSL

about me
About
Books
FAQ

content
Videos
Content Index
Fragments
Board Games
Photography

Thoughtworks
Home
Insights
Careers
Radar
Engineering

follow
RSS
Mastodon
LinkedIn
Bluesky
X
BGG

© Martin Fowler | Disclosures

The article describes an experiment conducted by Thoughtworks engineers focused on exploring agentic engineering by tackling the complex challenge of building an airline IROps system, a system essential for managing disruptions like flight cancellations and crew changes across multiple aircraft and stations. The team aimed to see how far and how fast they could progress using agentic methods, which inadvertently led to a discovery about coordinating agents. They initiated the project using a specification and a simulated airline within a monorepo. As agents began working concurrently, implementing disciplines like continual committing and rebasing from main to integrate early and often, emergent behavior surfaced regarding how agents interacted with each other's work.

This interaction was facilitated because the agents were directed to plan and scope work by storing these plans within the repository. The mechanism allowed agents to record progress on specific sections of the specification, which exposed integration points between different tasks. For example, an agent working on a cost model could coordinate with another agent working on a verifier by updating the shared plan, allowing one agent to know when resources were available and allowing the other to integrate their results directly upon completion. This discovery demonstrated that agents were effectively using the repository as an accidental blackboard for coordination.

The author connects this emergent behavior to the established pattern of a blackboard system, which is defined as a shared memory space where autonomous agents can independently read and write structured information, such as tuples, to coordinate toward a common objective without requiring a formal schema. This concept has historical roots in systems like Hearsay-II and the tuple space concept developed by Gelernter et al., suggesting that the agents' interaction mirrored established coordination structures for distributed problem solvers.

Although the use of the repository as a blackboard was accidental and unstructured, the experience highlighted the potential of such communication channels. The author suggests that creating this channel intentionally, rather than accidentally, is preferable. They note that while frequent commits initially overloaded the continuous integration pipeline, backing off the push frequency allowed for more coherent changes; however, this time reduction deprived agents of continuous progress updates. Consequently, the author is developing a project named Talwrn, which aims to create an intentional blackboard tool specifically tailored for agentic engineering, intending it to be a simple communication channel that allows agents to coordinate their work directly within a project space.