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 declares an activation condition: a predicate over the blackboard's contents that says when this specialist has something to contribute. When a condition matches, that KS becomes eligible; a control component picks which eligible KS runs; it posts its contribution, which may make others eligible.

       ┌──────────────── blackboard ────────────────┐
       │  raw   evidence   hypotheses   solution   │
       └───┬───────┬────────────┬───────────┬──────┘
           │       │            │           │
      condition?  condition?   condition?  condition?
           │       │            │           │
        extract  propose      score      accept        ← knowledge sources
           └───────┴──────┬─────┴───────────┘
                      control: run the highest-priority eligible one

Levels are state scopes; nothing needs creating, they exist on first write. Knowledge sources are functions bound 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 precisely because there is no call stack to read — "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 that by hand.

The agenda gap is a deployment detail with real consequences: the builtin and redis queue adapters ignore message priority entirely, so a single-node blackboard has an unordered agenda. Every eligible KS still runs; you just lose control over which one runs first, which — see the next rung — is the difference between an optimization and a bill.

The store, the knowledge sources and the control loop are small. What takes the space is everything around them — 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". That is the honest shape of opportunistic control, and writing it out is what makes the earlier gap concrete: nothing calls anything, so nothing naturally ends. Termination is a thing you build. It looks free in the diagram.

stalled is the one I did not anticipate. A knowledge source whose condition stays true but which contributes nothing will be selected forever — 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 — and because a wrong predicate fails silently (nothing fires), it is the failure you should build your tests around.
• 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", not "nothing is eligible anymore" — a different question, and the one that actually ends a run.
• Agent knowledge sources make the priority function load-bearing. With deterministic specialists, running them in a poor order costs microseconds. With model-backed ones it costs a model call, in dollars and seconds. The agenda stops being an optimization and becomes the cost control — which is what makes iii's priority gap matter 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 is known, no specialist can contribute further. For agent systems — which routinely hit the edge of what they can determine — that is a far more useful thing to return than an exception.

The companion repo has both implementations side by side, plus a demo that walks the activation conditions flipping between allow and skip against a live engine. Six tests, offline and deterministic; the one worth reading first is test_quiescence_when_nothing_eligible, because that outcome is the whole architecture in one assertion.