An Accidental Blackboard

📝 摘要

Thoughtworks 欧洲团队在巴塞罗那集结 10 名工程师，尝试"超智能体"（hyper-agentic）工程方式，在 4 天内构建了一个航空公司 IROps（Irregular Operations）系统。过程中，工程师们意外发现 AI 智能体自发利用 Git 仓库中的计划文件作为协调媒介——一个智能体标记某项工作为进行中，另一个智能体看到后便不会重复该工作；工作完成后，其他智能体不仅知道可以继续，还能获得实现方式的说明。作者识别出这正是经典的**黑板系统（Blackboard System）模式：源自 1980 年的 Hearsay-II 语音识别系统，后由 Gelernter 于 1986 年发展为更形式化的元组空间（Tuple Space）**概念。然而，这种协调行为是涌现的而非被引导的，频繁提交虽能维持信息流却会压垮 CI 管线。作者据此启动了 Talwrn 项目（威尔士语意为"辩论场"），目标是构建一个独立于版本控制、专门为智能体工程设计的意向性黑板系统。

核心概念： 多智能体可以通过共享的读写空间（黑板系统/元组空间）实现自发协调，这是 AI 智能体工程中被重新发现的经典模式。

关键技术栈 / 关键要点：

Hyper-agentic Engineering — 10 名工程师 + 多个 AI 智能体在单一代码库中并行工作，4 天建成复杂系统
Blackboard System — 自主智能体通过共享读写空间协调求解的架构模式，源自 Hearsay-II（1980）
Tuple Space — 黑板系统的形式化发展，由 Gelernter 于 1986 年提出，无 schema 的共享元组空间
Emergent Coordination — 智能体的协调行为并非被显式指令引导，而是从频繁提交+计划文件的工作纪律中涌现
CI Pipeline 负载 — 频繁提交维持了信息流但压垮了 CI，后退至"完成一定整变更后推送"导致信息流中断
Talwrn — 作者正在构建的意向性黑板项目，目标是独立于源码控制的智能体协调通信通道

关键结论 / 实践建议： 黑板系统是多智能体协调的有效模式，但依赖源码控制作为通信通道存在结构性缺陷（CI 负载、信息流中断）；应构建独立的智能体协调通信基础设施。

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.