Recently, I’ve been exploring how systems can work together without having a central manager controlling everything.

This started with looking at how ant colonies work.

Ants have limited capabilities. They can communicate through chemical signals, respond to their surroundings, and somehow cooperate to build and maintain entire colonies without a manager telling each ant what to do.

That made me wonder how something similar could work in software systems.

The exploration went through different areas, including how cells in the human body cooperate, especially in the immune system.

And somewhere along the way, I came across an interesting software architecture pattern called Blackboard Architecture.

It doesn’t really solve the decentralization problem I started with. In fact, it has a coordinator.

But it introduced another interesting idea.

What if nobody knows the complete solution?

Imagine having a complex problem, but none of the specialists working on it knows how to solve it completely.

Each specialist only has some knowledge that might contribute to the solution.

This is the idea behind Blackboard Architecture.

The system has three main parts:

• Blackboard: A shared space where the current problem, partial solutions, and findings are available.
• Knowledge Sources: Independent specialists, each capable of contributing something based on its own knowledge.
• Coordinator: Responsible for deciding which specialist should have the opportunity to contribute next. The Blackboard may start with just the initial problem.

A specialist contributes something, maybe a hypothesis or a partial solution.

Based on the current state of the Blackboard, the Coordinator selects another specialist that might be able to contribute.

And this process continues.

The interesting thing is that the Coordinator doesn’t know the complete solution either.

It only needs to coordinate the search for one, based on what is currently known.

A contribution may be useful, may lead to another contribution, or may not move the problem forward.

And there is no guarantee that the system will always find a solution.

An interesting example from the 1970s

One of the things that surprised me was learning about HEARSAY-II, a speech-understanding system developed in the 1970s.

The system was trying to understand spoken language using different sources of knowledge.

One could contribute knowledge about sounds, another about words, another about grammar, and another about the meaning or context.

None of them had the complete answer.

But by sharing partial findings through the Blackboard, and coordinating which source should contribute next, the system could gradually work toward interpreting what was spoken.

And this was happening back in the 1970s!

Interestingly, HEARSAY-II was already part of early AI research, long before the Generative AI models we’re familiar with today.

What caught my attention

The most interesting part wasn’t having multiple specialists.

It was the Coordinator.

The Coordinator doesn’t need to know how to solve the problem. It needs a way to decide which contribution could be useful next.

There doesn’t have to be a predefined sequence of steps leading to the final answer.

And the system may eventually reach a solution, or stop without finding one.

This made me think about how much we expect from today’s Generative AI models.

We keep trying to build more capable models, give them larger context windows, and make them handle increasingly complex problems.

But what if solving some complex problems doesn’t require any single component to understand the whole problem?

What if the answer can emerge gradually from partial contributions, while a coordinator manages the process without knowing the final solution?

That’s the question Blackboard Architecture left me thinking about.

Originally published on LinkedIn: [Article URL].