What is better than your AI loop?

A blackboard architecture, modernized with event sourcing, content-addressed knowledge source (KS) firing and a few more enhancements.

While working on improvements to various LLM-powered components and subsystems over the past year, I noticed I kept converging on the same architecture — one that, as I later found out, had been described and named four decades ago.

The blackboard model of problem solving is less known today not because it is so recent, but quite the contrary, because it was already summarized and canonized in 1986 by H. Penny Nii. The article "The Blackboard Model of Problem Solving and the Evolution of Blackboard Architectures" was published in two parts, the first part in AI Magazine, Volume 7, Issue 2 [1, 2].

That is right, 40 years ago, AI Magazine, long before we had GPUs pushing TOPS. And the metaphor itself is older still: the first "blackboard" in the AI literature appears in 1962, when Allen Newell imagined "a set of workers, all looking at the same blackboard: each is able to read everything that is on it, and to judge when he has something worthwhile to add to it" [3].

The model/architecture itself is relatively simple, based on a shared solution space (blackboard) and knowledge sources (humans, computers) participating in a solution. There is no classic "agentic loop" in this architecture. The set of knowledge sources is being evaluated by priority until none of them is firing. Each KS could plant new evidence on the board and the evaluation is potentially infinite.

It wasn't a mere theoretical exercise back then. In fact, the article describes existing and functional systems such as HEARSAY-II (speech understanding) [5], HASP/SIAP (sonar signal interpretation) [6], CRYSALIS (protein structure inference), TRICERO (air-activity monitoring) and OPM (opportunistic errand planning), and summarizes theory and experience gathered in preceding decades.

Interestingly, the article itself describes limitations of execution and control. These were partly theoretical and mostly practical limitations dictated by the available computers of that era. Footnote 7 of Part One [1] even treats the serialization of the model as a mere uniprocessor artifact and looks ahead to hundreds of processors.

The control decisions posted on the blackboard and made by the control KSs, scheduled like the domain KSs, were actually described a year earlier by Barbara Hayes-Roth (1985 article: "A Blackboard Architecture for Control") [4]. McManus (1990) [8] later worked at the same architectural layer, contributing design and analysis metrics (output-overlap and I/O-connectivity between knowledge sources) for concurrent blackboard systems.

My Enhancements

As I mentioned in the first sentence, the most prominent additions are event sourcing and content-addressed firing. These two choices work together to enable a third key enhancement: execution as a KS!

The 1980s systems kept execution in a separate action layer on purpose. They would be forced to re-run the side effects on every step (catastrophic to performance) or to build ad-hoc guards (the "did we already do this" kind).

The new event-sourced substrate [9] and N-tuple-based KS firing (a generalization of Rete's refraction [7], with the content-addressed matching itself echoing Linda's tuple spaces [10]) make the per-step evaluation cheap while guaranteeing the action fires once. The idea that evaluation cost should scale with the change rather than with the whole knowledge base has a long afterlife in incremental computation research and is very much alive today.

In today's backend jargon, this is CQRS: the event journal is the write side and the blackboard is a projection — an ephemeral read model, never a mutable database. Replay merely reconstructs projections from journaled events; the executor cannot re-fire, because its past action is itself an event in the journal and the content-addressed gate sees that the question was already asked. The executor KS could be treated like every other KS and that is a huge win.

A philosophical note on concurrency:

like SQLite, this is deliberately an engine, not a server. Where Nii's footnote treated serialization as an artifact of uniprocessor hardware and looked ahead to hundreds of processors, I embrace it — deliberate serialization is exactly what buys replayability. The hard part of the problem is not throughput but the universe of possible solution trees; concurrency can stay somebody else's problem.

Practical Implications

Beyond the benefits that originally motivated the design, I later realized the architecture also absorbs many of today's constructs quite naturally.

Consider the classic chat with an LLM: a KS observing the latest post from a human operator, invoking the LLM to respond. This sounds trivial until you realize:

• The operator could respond to any previous node in the conversation — the KS will see an "unreplied-to" post and invoke the LLM to respond, effectively creating a branched conversation (and a chronological journal of events as a bonus). This capability became available only recently (and in various forms) with current coding harnesses and AI chat applications.
• The tree of conversation nodes provides an accurate path for each leaf and a cache-friendly prefix for any branched conversation.
• The introduction of multiple instances of the same KS (using different LLMs or varying system prompts) already creates a research team.
• Wrap any coding harness (such as Claude Code with the -p switch) into a KS and you have built an automated and insanely powerful development system.

The unifying observation is that a blackboard system could become any current app: a chat, a loop, an orchestrator. It depends purely on the roster of enabled KSs and their vocabulary, and the realization of these patterns is elegant rather than merely possible.

Main Benefits of a Blackboard Architecture

Apart from the natural absorption of any common LLM app pattern used today, the blackboard architecture provides non-trivial benefits which are often "bolted on" within other systems.

• Control is decentralized and arbitration is coordinated. This strikes harder than it sounds: consider the case where a shell command is supposed to run a certain test suite of unit tests. The command could either succeed or fail (e.g. due to a wrong path), but the actual test execution must be assessed by a different KS. Did the test suite actually run? Did the test actually cover the source code properly? This leads to an important realization: There is no single result of an action — it all depends on "who is watching", and thus any other system with a single task outcome will be severely limited in properly and accurately representing the state of the world.
• Event sourcing provides temporal consistency, replayability, audit trails and natural versioning all at the same time.
• Blackboard as a projection avoids uncontrolled state mutation and consistency issues. The projection also doesn't have to be a single monolithic board: the same journal can materialize into specialized read models per KS — for example straight into a search index for a RAG-supporting KS.
• Content-based KS firing maps cleanly to reactive/subscription patterns and thus to many common products used today (Kafka topics, pub/sub or even rule engines) — a decoupling already fully formed in 1985 in Linda's tuple spaces [10].
• Heterogeneous knowledge sources are natural:
  • Prominently LLM-based KSs, either in a pure form (KS code invoking an LLM directly) or by embedding another product (such as Claude Code in non-interactive mode). The context rendering is just another projection which could be tailored for every kind of KS separately if desired.
  • A human operator as a KS becomes "human in the loop" in a powerful way. Their view of the "world" could be implemented as a UI; the underlying substrate is still the single source of truth.
  • A whole gradient of symbolic reasoners, simulators, sandbox environments, build pipelines, connectors to databases (RAG-supporting KSs), etc.
• Recursive composability: The blackboard system could be using knowledge sources which are themselves embedded blackboard systems with a specific (focused) set of KSs and specific vocabulary.

Limitations

• There is a potential trap in the decentralized control inherently embedded in a set of knowledge sources. This was historically also the reason why blackboard systems with large rule sets became unmaintainable. This should be avoided and proper focus and decomposition are advised. Instead of building a set of KSs which could do anything, it is better to focus on a set of KSs addressing a particular task exceptionally well.
• No real-time systems with any kind of latency requirements. A blackboard system is better thought of as a team of experts, built to solve difficult problems without any time expectations.
• Like with Turing completeness, many architectures could be simulated as a blackboard system, but that does not mean it is the optimal or idiomatic fit.

Conclusion

Perhaps the best way to summarize the whole design: this is not just a blackboard. It is a continuously evolving, historically accurate database of reasoning.

Have you converged on a similar architecture in your own work, or do you disagree with my design choices? Please, leave me a comment below!

References

1. H. Penny Nii, "The Blackboard Model of Problem Solving and the Evolution of Blackboard Architectures" (Part One), AI Magazine, 7(2), 1986.
2. H. Penny Nii, "Blackboard Application Systems and a Knowledge Engineering Perspective" (Part Two), AI Magazine, 7(3), 1986.
3. Allen Newell, "Some Problems of Basic Organization in Problem-Solving Programs", in Yovits, Jacobi & Goldstein (eds.), Conference on Self-Organizing Systems, Spartan Books, 1962.
4. Barbara Hayes-Roth, "A Blackboard Architecture for Control", Artificial Intelligence, 26(3), 1985.
5. Lee D. Erman, Frederick Hayes-Roth, Victor R. Lesser, D. Raj Reddy, "The HEARSAY-II Speech-Understanding System: Integrating Knowledge to Resolve Uncertainty", ACM Computing Surveys, 12(2), 1980.
6. H. Penny Nii, Edward A. Feigenbaum, John J. Anton, A. J. Rockmore, "Signal-to-Symbol Transformation: HASP/SIAP Case Study", AI Magazine, 3(2), 1982.
7. Charles L. Forgy, "Rete: A Fast Algorithm for the Many Pattern/Many Object Pattern Match Problem", Artificial Intelligence, 19(1), 1982.
8. John W. McManus, "Design and Analysis Tools for Concurrent Blackboard Systems", 9th IEEE/AIAA Digital Avionics Systems Conference, NASA Langley Research Center, 1990.
9. Jay Kreps, "Questioning the Lambda Architecture", O'Reilly Radar, 2014.
10. David Gelernter, "Generative Communication in Linda", ACM Transactions on Programming Languages and Systems, 7(1), 1985.