The oldest multi-agent architecture is the least used

The blackboard is a shared, structured store, partitioned into levels: raw input, derived evidence, candidate hypotheses, the solution. Independent knowledge sources watch it. Each one declares an activation condition, which is a predicate over the blackboard's contents. The predicate says when that knowledge source has something to contribute. When it matches, the knowledge source becomes eligible, and a control component picks which eligible one runs. It posts its contribution, and that contribution can make others eligible.

flowchart TD
  subgraph bb["blackboard"]
    raw["raw"]
    evidence["evidence"]
    hypotheses["hypotheses"]
    solution["solution"]
  end
  subgraph ks["knowledge sources"]
    extract["extract"]
    propose["propose"]
    score["score"]
    accept["accept"]
  end
  control["control: run the highest-priority eligible one"]
  raw -.- c1["condition?"] -.- extract
  evidence -.- c2["condition?"] -.- propose
  hypotheses -.- c3["condition?"] -.- score
  solution -.- c4["condition?"] -.- accept
  extract --- control
  propose --- control
  score --- control
  accept --- control
  class raw,evidence,hypotheses,solution dim
  class c1,c2,c3,c4 block
  class control pass

Levels are state scopes, and nothing needs creating: they exist on first write. A knowledge source is any function you bind to a state trigger. The interesting piece is conditions: an array on the binding, where fp::condition expresses the precondition as data:

iii trigger engine::register_trigger \
  trigger_type=state function_id=promote-hypothesis \
  config='{"scope":"bb:hypotheses"}' \
  conditions='[{
    "function_id": "fp::condition",
    "config": { "path": "/new_value/confidence",
                "op": ">", "to": 0.8 }
  }]'

Operators are == != > >= < <= exists not_empty, plus negate. And the predicate returns more than a boolean:

$ iii trigger fp::condition \
    event='{"new_value":{"confidence":0.9}}' \
    condition_config='{"path":"/new_value/confidence","op":">","to":0.8}'
{"decision": "allow", "reason": "`/new_value/confidence` is 0.9, expected > 0.8"}

$ # same condition, weaker hypothesis
{"decision": "skip",  "reason": "`/new_value/confidence` is 0.5, expected > 0.8"}

That reason string is the detail worth stealing. Opportunistic control is the hardest kind to debug, because there is no call stack to read. So "why didn't anything happen?" is the characteristic failure. Here every scheduling decision explains itself, and you did not have to instrument anything to get it. Classic blackboard implementations built those explanations by hand.

The agenda gap is a deployment detail with real consequences. The builtin and redis queue adapters ignore message priority, so a single-node blackboard has an unordered agenda. Every eligible knowledge source still runs, so you only lose control over which one runs first. The next rung shows why that ordering is the difference between an optimization and a bill.

The store, the knowledge sources, and the control loop are small. Everything around them takes the space: content-hash compare-and-set, a change log so the loop can tell progress from stalling, and the termination logic.

def run(self) -> str:
    for step in range(self.max_steps):
        if not self.bb.empty("solution"):
            return "solved"

        eligible = [ks for ks in self.sources if ks.eligible(self.bb)]
        if not eligible:
            return "quiescent"        # nothing applies. a real answer.

        ks = max(eligible, key=lambda k: k.priority)
        before = len(self.bb.log)
        ks.action(self.bb)
        if len(self.bb.log) == before:
            return "stalled"          # eligible but contributed nothing

    return "exhausted"

Four outcomes, and only one of them is "solved". Those four are the honest shape of opportunistic control. Writing them out makes the earlier gap concrete: nothing calls anything, so nothing ends on its own. Termination is a thing you build, and it looks free in the diagram.

stalled is the one I did not anticipate. If a knowledge source keeps its condition true but contributes nothing, control selects it forever. That repeat selection is the single way this loop livelocks. The check is three lines, and it is not optional.

[0] extract-evidence   (priority 10)
[1] propose-hypothesis (priority 20)
[2] score-hypothesis   (priority 30)
[3] accept-hypothesis  (priority 40)
[4] solution present — done

outcome: solved
answer:  The backlog is a throughput limit, not a failure: one consumer, flat errors.
conf:    0.86

• The activation condition is the whole architecture. Everything else is bookkeeping. Get the predicates wrong and a blackboard is a hash map with extra steps. A wrong predicate fails silently, because nothing fires, so build your tests around that failure.
• Opportunism needs a termination story, and it is yours. Both implementations needed an explicit quiescence check. iii's state::barrier answers "wait for N contributions". It does not answer "nothing is eligible anymore", and that second question is the one that ends a run.
• Agent knowledge sources make the priority function load-bearing. With deterministic knowledge sources, running them in a poor order costs microseconds. With model-backed ones it costs a model call, in dollars and seconds. So the agenda stops being an optimization and becomes the cost control. That shift is why iii's priority gap matters more than it first appears.
• Partial results are a first-class outcome. A pipeline that can't finish has failed. A blackboard that reaches quiescence has told you something true: given what the blackboard holds, no knowledge source can contribute further. Agent systems often hit the edge of what they can determine, so that partial answer is more useful than an exception.

The companion repo has both implementations side by side. It also has a demo that walks the activation conditions flipping between allow and skip against a live engine. The six tests are offline and deterministic. Read test_quiescence_when_nothing_eligible first, because that outcome is the whole architecture in one assertion.