The older problem hidden inside the new model

Early cognitive architectures are easy to caricature. One imagines rooms of researchers encoding rules by hand, brittle symbols standing in for the world, and elaborate diagrams that promised general intelligence before the necessary data and compute existed. The caricature contains truth. It also hides the engineering problem those systems were built to expose. A broad review later catalogued 84 architectures and more than 900 practical projects, showing how varied the label had become.10

Once an intelligent system does more than map one input to one output, several processes must coexist. Perception changes current beliefs. Retrieved knowledge changes which alternatives appear relevant. Goals compete. An action alters the environment. Failure may create a subproblem. Learning changes future behaviour. If all of this is called “the model”, no one can say which change caused an outcome or which part may be edited safely.

Langley, Laird and Rogers defined a cognitive architecture as the infrastructure that remains relatively constant across domains, including its memories, representations, performance processes and learning processes.8 The contents of memory are task knowledge. The rules governing what a memory can contain and how it affects action are architectural commitments. That distinction is more useful than any historical label.

Production systems: behaviour as matched conditions

A production system begins with a small move. Represent procedural knowledge as condition-action rules. Compare those conditions with current facts, collect the rules that match, select one or more, apply their actions, then repeat. Efficient matching became a research problem in its own right; Forgy’s Rete algorithm avoided reconsidering every pattern against every object from scratch.7

The important point is not the syntax of an if statement. A production system separates three things that ordinary code often entangles: the facts currently believed, the knowledge that can respond to those facts, and the conflict-resolution procedure that decides what fires. A rule base becomes architecturally interesting only when matching and selection have their own observable semantics.

This separation also exposes a weakness. Rules can proliferate, overlap and encode accidental assumptions. A conflict resolver can hide arbitrary priorities behind a mechanical veneer. The architecture makes these debts visible; it does not pay them automatically.

Soar: impasses as first-class events

Soar casts deliberate goal-directed behaviour as the selection and application of operators to a state. Working memory represents the current situation. Production memory contains procedural knowledge. Productions elaborate the state, propose operators, compare them and apply the selected operator. A fixed decision procedure interprets the resulting preferences.12

The distinctive move is what happens when selection fails. If no operator is available, several operators tie, or an operator cannot be applied, Soar creates an impasse and a substate in which the system can solve the missing problem. When that subproblem resolves, chunking can create a new production that summarises the conditions and result.2

This is not a claim that every modern agent needs Soar’s exact mechanism. The reusable idea is narrower: uncertainty about what to do next can be represented as state, rather than concealed inside another stochastic generation. Once an impasse is explicit, a system can search, retrieve, ask a person, abstain or record that it lacks a discriminating rule.

ACT-R: cognition through constrained interfaces

ACT-R was built primarily as a theory of human cognition. It divides activity across perceptual-motor, goal, declarative and other modules. Modules expose limited contents through buffers. A production system detects patterns across those buffers, and one production is selected at a time. Subsymbolic quantities influence retrieval latency, production utility and learning.34

The buffer is the transferable idea. A module may perform complicated internal work, yet only a constrained interface participates in central selection. This creates a bottleneck, but the bottleneck is scientifically productive: a model must specify what was available to the system at a given moment. It can then predict timing and error patterns, rather than merely produce a correct answer after unlimited hidden computation.

For engineering agents, the lesson is not to simulate human fifty-millisecond cycles. It is to ask which information deserves a stable interface. A retriever, planner or visual system may be powerful internally. The agent still needs a contract for what each can assert, with what provenance, at what effective time and for which decision.

Blackboards: coordination without a single master procedure

Hearsay-II tackled speech understanding using heterogeneous, imperfect knowledge sources. Independent components posted hypotheses to a shared, multi-level blackboard. Changes on the blackboard activated relevant knowledge sources, while a control mechanism allocated attention among their possible contributions.5 Nii later described the blackboard model as a family of system organisations, not one fixed algorithm.6

The blackboard was useful because no specialist needed to know every other specialist. Acoustic, phonetic, lexical and syntactic knowledge could contribute through a common problem representation. Its danger was equally clear: a shared workspace can become an untyped dumping ground. If every contribution has ambiguous status, the board coordinates activity while destroying epistemic discipline.

Four architectures cut open

The four systems disagree about representation, timing, learning and scientific purpose. Soar emphasises operators and impasse-driven problem solving. ACT-R constrains access through buffers and aims to explain human data. Hearsay coordinates heterogeneous specialists through a shared hypothesis space. A contemporary foundation-model agent often starts with a probabilistic model and adds memory, tools and a control loop around it.

They should not be flattened into the slogan “everything has modules”. The recurring structure is more precise: current state is made available through some interface; long-term competence is stored or generated elsewhere; a control process determines which proposed change becomes effective; and observations return after action. The common inheritance is a set of seams where causal questions can be asked.

The 2017 Standard Model of the Mind attempted to identify convergent commitments across several mature cognitive architectures, including perceptual and motor systems, working memory, procedural memory, declarative memory, learning and a repeated cognitive cycle.9 Its authors presented the model as a cumulative reference point with acknowledged gaps, not a settled anatomy. A later detailed comparison of ACT-R and Soar found substantial common structure alongside meaningful differences in representation, metadata and processing.15

This creates an important fork. A scientific cognitive architecture is judged by whether it explains human behaviour, including timing, errors, learning and information limits. An engineering architecture is judged by whether it helps a system achieve and verify outcomes under operational constraints. The same buffer or production metaphor may serve both, but evidence does not transfer automatically. A useful service boundary does not validate a theory of mind; a good cognitive model does not establish an efficient production runtime.

For this article, the systems are compared at the engineering level of intervention. Their scientific claims remain local to their published evidence. This prevents a common nostalgia error: importing a classical mechanism because it sounds cognitively plausible, rather than because a controlled test shows that the mechanism changes recovery, attribution or selective modification.

Separation creates an intervention surface

Modularity is often defended with vague words such as maintainability or interpretability. Those benefits are possible, but they are not automatic. A module boundary can add indirection without adding knowledge. We need a sharper test.

Call a boundary an intervention surface when three conditions hold. First, the two sides obey different update rules or truth conditions. Second, one side can be changed while the other remains materially fixed. Third, the resulting behavioural difference can be observed and attributed. This is a practitioner synthesis, not a standard term in cognitive-architecture research.

A separation earns causal meaning when it supports a controlled swap. Replace the declarative policy but preserve the controller and proposal model. Change the conflict-resolution rule but preserve the facts and candidate actions. Interrupt execution but preserve a replayable working state. If outcomes change as predicted, the boundary does explanatory work. If nothing can be varied independently, the boxes are decorative.

Thought experiment one: the interrupted kitchen

Return to the mug. Hold the model, prompt, sensors, task and interruption fixed. Vary only the representation available after restart. System A receives a transcript. System B receives typed working state, a command receipt and readback evidence. The predicted difference is not general task intelligence. It is recovery accuracy under ambiguous completion.

If repeated trials showed no difference, or if a long-context transcript recovered as reliably as typed state under realistic corruption, the case for a separate working-state layer would weaken. The point of the thought experiment is therefore falsifiable: the architecture predicts a specific advantage under interruption, not universal superiority.

Thought experiment two: the swapped librarian

Imagine two agents answering the same travel-expense claim. They use the same model, the same claim and the same procedural controller. Only the declarative policy store differs. Policy P-7 permits automatic approval up to £100. Policy P-8 lowers the limit to £50. An £80 claim should move from an approval proposal to manual review, while the rest of the trace remains stable.

Now run a second intervention. Restore P-7 and change only authority: the agent may recommend approval but may not execute it. The proposal should remain “approve”, while the outcome becomes “held for authorised review”. These two swaps distinguish knowledge from power. Knowing that an action is permitted by policy is not the same as possessing authority to perform it.

A monolithic prompt can mention both policy and authority. The distinction becomes architectural when they are separately versioned, separately testable and separately enforceable. That is why an API connection, a graph or a memory store is not itself an authorisation mechanism.

flowchart TD
  A["The mug after the network cut"] --> B["The older problem hidden<br/>inside the new model"]
  B --> C["Four architectures cut open"]
  C --> D["Separation creates an<br/>intervention surface"]
  D -. "re-test" .-> A
  classDef first fill:#0a1424,stroke:#D95545,stroke-width:2px,color:#e6f3ff
  classDef step fill:#0a1424,stroke:#3f7da0,stroke-width:1px,color:#e6f3ff
  class A first
  class B,C,D step

A minimal executable example

The following micro-runtime is intentionally small. It is not an implementation of Soar or ACT-R. It isolates four surfaces: working memory holds case facts; declarative knowledge holds a versioned policy limit; procedural memory contains rules; and authority determines whether an approval proposal may become an effect.

The positive case has verified identity, a receipt, an £80 claim, policy P-7 with a £100 limit and approval authority. The negative case differs only in identity verification. A third run swaps policy P-7 for P-8 with a £50 limit. That declarative-memory intervention should route the same verified claim to review without changing procedural code.

from dataclasses import dataclass
from typing import Any, Callable

WorkingMemory = dict[str, Any]

@dataclass(frozen=True)
class Knowledge:
    policy_limit_gbp: int
    policy_version: str

@dataclass(frozen=True)
class Authority:
    may_approve: bool

@dataclass(frozen=True)
class Context:
    knowledge: Knowledge
    authority: Authority

Condition = Callable[[WorkingMemory, Context], bool]
Action = Callable[[WorkingMemory, Context], dict[str, Any]]

@dataclass(frozen=True)
class Rule:
    name: str
    priority: int
    when: Condition
    apply: Action

TERMINAL = {"approved", "held", "rejected", "impasse"}

def run_case(initial, context, rules, max_cycles=8):
    wm, trace = dict(initial), []
    for cycle in range(1, max_cycles + 1):
        if wm.get("status") in TERMINAL:
            return wm, trace
        matches = [rule for rule in rules if rule.when(wm, context)]
        if not matches:
            wm.update(status="held", reason="no_rule_matched")
            return wm, trace
        highest = max(rule.priority for rule in matches)
        winners = [rule for rule in matches if rule.priority == highest]
        if len(winners) != 1:
            wm.update(status="impasse", reason="priority_tie")
            return wm, trace
        chosen = winners[0]
        changes = chosen.apply(wm, context)
        wm.update(changes)
        trace.append((cycle, chosen.name, changes))
    wm.update(status="held", reason="cycle_limit")
    return wm, trace

RULES = [
    Rule("hold_unverified_identity", 100,
         lambda wm, c: not wm["identity_verified"],
         lambda wm, c: {"status": "held",
                        "reason": "identity_not_verified"}),
    Rule("request_missing_receipt", 90,
         lambda wm, c: wm["identity_verified"] and not wm["receipt_present"],
         lambda wm, c: {"status": "held", "reason": "receipt_required"}),
    Rule("propose_within_policy", 60,
         lambda wm, c: (wm["identity_verified"] and wm["receipt_present"]
                        and wm["claim_amount_gbp"] <= c.knowledge.policy_limit_gbp
                        and "proposal" not in wm),
         lambda wm, c: {"proposal": "approve",
                        "policy_version": c.knowledge.policy_version}),
    Rule("propose_manual_review", 60,
         lambda wm, c: (wm["identity_verified"] and wm["receipt_present"]
                        and wm["claim_amount_gbp"] > c.knowledge.policy_limit_gbp
                        and "proposal" not in wm),
         lambda wm, c: {"proposal": "review",
                        "policy_version": c.knowledge.policy_version}),
    Rule("execute_approved_proposal", 50,
         lambda wm, c: wm.get("proposal") == "approve" and c.authority.may_approve,
         lambda wm, c: {"status": "approved",
                        "effect_receipt": "synthetic-001"}),
    Rule("hold_without_authority", 50,
         lambda wm, c: wm.get("proposal") == "approve" and not c.authority.may_approve,
         lambda wm, c: {"status": "held",
                        "reason": "approval_authority_absent"}),
    Rule("route_review_proposal", 50,
         lambda wm, c: wm.get("proposal") == "review",
         lambda wm, c: {"status": "held",
                        "reason": "manual_review_required"}),
]

base = {"identity_verified": True,
        "receipt_present": True,
        "claim_amount_gbp": 80}

positive = run_case(base,
    Context(Knowledge(100, "P-7"), Authority(True)), RULES)
negative = run_case({**base, "identity_verified": False},
    Context(Knowledge(100, "P-7"), Authority(True)), RULES)
policy_swap = run_case(base,
    Context(Knowledge(50, "P-8"), Authority(True)), RULES)

for label, result in [("positive", positive),
                      ("negative", negative),
                      ("policy_swap", policy_swap)]:
    print(label, result)

assert positive[0]["status"] == "approved"
assert negative[0]["reason"] == "identity_not_verified"
assert policy_swap[0]["reason"] == "manual_review_required"

The code is deliberately less capable than a language model. Its value is experimental clarity. We can state exactly why the negative case stopped, exactly which policy version supported the proposal, and exactly what changed when the policy was swapped. A foundation model could generate the proposal, extract the receipt or explain the rule. It should not erase the distinction among those operations.

One can now insert a model without surrendering the experiment. Let the model convert an unstructured receipt into candidate facts, or propose whether an unusual expense resembles a covered category. Persist the proposal separately, validate its schema, and run the same authority and policy cycle. Then compare models while holding the architecture fixed, or compare architectures while holding the model fixed. This two-way control is precisely what a monolithic prompt makes difficult.

The explicit conflict set also changes failure behaviour. If two top-priority productions match, the runtime returns an impasse rather than selecting whichever textual instruction happens to dominate. That may feel conservative. For consequential action, an observable tie is often more useful than an eloquent guess.

What foundation models change

Classical cognitive architectures paid a severe knowledge-acquisition cost. Designers had to encode concepts, productions, operators, utilities and interfaces before the system could behave competently. Coverage expanded slowly, and the resulting knowledge often failed outside its intended domain. Sutton’s “bitter lesson” sharpened the objection: methods that exploit general computation and learning tend to outlast methods built around human-specified knowledge about how intelligence should work.14

Foundation models alter that balance. Training on broad data produces a reusable source of linguistic, visual and behavioural priors. A model can interpret novel instructions, generate candidate plans, translate between representations and fill missing procedural knowledge without a developer writing every rule. The foundation-model paradigm obtains leverage by adapting one broadly trained model across many downstream tasks.11

This weakens any claim that explicit symbolic decomposition is necessary for competent behaviour. A sufficiently capable model may implicitly perform retrieval, planning, conflict resolution and self-monitoring inside one forward pass or one recurrent reasoning process. CoALA acknowledges the extreme possibility that a model’s internal computation could implement all the functions described by an external cognitive architecture.12

Yet implicit implementation and explicit system responsibility are different claims. A model may contain a mechanism that behaves like working memory. That does not give an application a durable, typed state that survives process loss, supports bitemporal reconstruction or can be reconciled against the world. A model may infer that an action is allowed. That does not create a capability token, an approval record or an effect receipt.

Foundation models reduce the cost of supplying competence; they do not abolish the need to locate consequence. The more a system acts across time, the more it must distinguish a model proposal from a world-state assertion, a policy judgement from authority, and a predicted outcome from a verified one.

A recent architectural proposal, the Structured Cognitive Loop, makes this separation explicit: retrieval establishes context; cognition proposes; regulation shapes permitted proposals; deterministic control checks the run; action touches the environment; memory preserves verified state. Its early controlled experiments combine some of those layers, so the reported absence of policy violations is not yet a general guarantee. The design is still useful as a falsifiable map. It gives each failure somewhere concrete to land instead of asking one prompt to be memory, policy, controller and audit trail at once.

A bounded modern result

Recent work offers a useful, limited bridge. Zhu and Simmons used an LLM to bootstrap production rules for a cognitive agent performing simulated kitchen tasks. In their reported setting, the bootstrapped agent reused learned productions, reduced later LLM reliance and completed the tested tasks efficiently relative to an action-only LLM baseline.13

The paper’s limitations matter as much as its result. The experiments focused on high-level decision making with well-defined low-level actions. The authors noted the likely gap between simulation and physical robots, and the difficulty of expressing some skills as articulate production rules. This is evidence that a hybrid can help in a bounded environment, not evidence that production rules have solved general agency.

CoALA makes a broader conceptual proposal: place a language model within an architecture of working and long-term memories, internal and external actions, and a repeated decision process.12 It is a useful vocabulary and design space. It should not be treated as an empirical verdict that every successful language agent needs each named memory or action type.

The negative control: when architecture is ceremony

Consider a one-shot task: classify a support message into one of five queues. The input is complete, the output is reversible, no tool is called, no case persists, and a human can correct an error. A model with a constrained output schema and a small evaluation set may be the best design. Adding episodic memory, an operator hierarchy, a blackboard and a production cycle creates more failure points without changing the decision.

This negative control matters because nearly any software can be redrawn as a cognitive architecture. The drawing proves nothing. The correct baseline is the simplest system with the same model, information and output constraints. The proposed architecture must then earn its extra latency, implementation effort and state-reconciliation burden under a matched disturbance or intervention.

There are deeper failure modes. A wrong decomposition can make cross-module interactions harder to learn. Rule systems suffer combinatorial growth and hidden priority conflicts. Shared workspaces invite contamination. A central decision bottleneck can suppress useful parallel work. Cognitive fidelity also imposes different requirements from engineering utility: a system that is operationally controllable may be a poor model of human cognition, and a psychologically accurate timing model may be an inefficient service architecture.

Nor does a cognitive architecture establish consciousness, sentience or selfhood. It may reproduce functional organisation associated with cognition while leaving experience entirely unaddressed. The evidence ledger for system behaviour remains separate from any claim about what, if anything, the system experiences.

A production-shaped case without the museum

Suppose a service handles disputed card payments. The system gathers the customer’s account, the disputed transaction, merchant evidence, applicable policy and prior case events. A language model can summarise evidence, propose a hypothesis and draft a customer explanation. The system may also request documents, place a temporary marker or route the case to a reviewer.

This is a synthetic worked scenario. It is not a claim about a deployed bank system. Its purpose is to show how classical separations translate into present operational objects.

Do not call every persistent object memory

The current transaction status belongs to world state and must be read from an authoritative system. The progress of the investigation is workflow state, reconstructed from events. Prior interaction episodes may support retrieval, but they remain episodic records. Policy documents and product rules are enterprise knowledge. Source extracts, decisions and readbacks form an evidence ledger. These stores differ in ownership, freshness, correction and authority.

A free-form agent memory that blends them recreates the worst blackboard failure. A stale policy sentence can masquerade as current world state. A model-generated explanation can return later as evidence. A previous customer’s pattern can influence a new case without entitlement. The useful blackboard idea is shared visibility; the necessary modern addition is typed provenance and temporal scope.

Map the decision cycle to ten distinct responsibilities

Intent records what the customer or operator asked to achieve. Identity binds the requester and subject. World state records what authoritative systems currently report. Context compiles the evidence permitted for this decision. Reasoning produces hypotheses and a model proposal. Authority determines which principal may approve which consequence.

Action uses a typed contract with preconditions and an idempotency key. Evidence records why a proposal passed or failed. Outcome is established through an effect receipt and independent readback. Release and recovery define timeout, unknown-outcome handling, compensation and escalation.

These are not ten “agents”. They are ten claim types and control responsibilities. They can be implemented by one process or many services. The architecture is justified by their different truth conditions. A model can propose that a payment is eligible for temporary credit. It cannot make the account ledger true by writing the sentence.

What is inherited from the classical systems

From production systems, retain explicit conditions and a traceable conflict set for consequential actions. From Soar, retain the idea that unresolved choice is an impasse with a deliberate recovery path. From ACT-R, retain constrained interfaces between specialised processes and central selection. From blackboards, retain a shared case representation through which heterogeneous evidence can contribute without every component knowing every other component.

Discard the assumption that all useful knowledge must be hand-coded symbols. Let the foundation model interpret documents, generate candidate procedures, map language to schemas and propose missing rules. Then subject those outputs to typed validation, authority and outcome verification. The model supplies semantic reach. The architecture supplies intervention points.

stateDiagram-v2
  [*] --> Claim
  state "Production systems: behaviour<br/>as matched conditions" as Claim
  state "Soar, impasses as first-class<br/>events" as Test
  state "ACT-R: cognition through<br/>constrained interfaces" as Revision
  Claim --> Test: expose mechanism
  Test --> Decision: evidence survives
  Test --> Revision: rival survives
  Revision --> Claim: narrow or rebuild
  Decision --> [*]

The architecture checklist

The checklist below converts the argument into a design decision. Score each dimension 0 when absent, 1 when useful and 2 when essential. The thresholds are practitioner heuristics, not validated scientific scales. Their purpose is to force a matched baseline and an explicit reason for each boundary.

1. Temporal continuity. Must the system survive interruption, reconstruct progress or distinguish a pending command from an observed effect?
2. Heterogeneous knowledge. Do specialists or sources have different provenance, freshness, uncertainty or correction rules that must remain visible?
3. Selective change. Must policy, task knowledge, conflict resolution or learned procedure be updated independently without retraining or revalidating everything?
4. Consequential authority. Can a proposal cause money movement, external communication, physical change or another effect requiring identity, permission and postcondition verification?
5. Causal diagnosis. Must an operator reproduce why a choice occurred and test a counterfactual swap of memory, control or authority?
6. Scientific fidelity. Is the goal to explain human timing, errors or information limits, rather than merely obtain a correct task output?

Test the architecture, not its diagram

A convincing evaluation holds the foundation model, task information and action interfaces constant. Compare the simplest baseline with the proposed architecture under normal operation and deliberate disturbance. Inject stale policy, missing evidence, a priority tie, an interrupted action, a corrupted episode and an authority withdrawal. Measure task success, recovery success, duplicated effects, diagnosis time, change isolation, latency and cost.

Then perform component swaps. Replace declarative memory while preserving procedural control. Replace the control policy while preserving candidate actions. Remove outcome readback while preserving everything else. These ablations reveal whether the architecture’s seams carry causal responsibility or merely mirror the implementation.

Record the decision as a compact architecture decision record: the pressure being addressed, the simplest baseline, the new boundary, its owner, its truth condition, the intervention test, the expected benefit, the new failure modes and the retirement condition. A boundary without a retirement condition tends to become permanent ceremony even after the model, task or operating environment changes.

For scientific cognitive architectures, add human behavioural predictions: response-time distributions, error patterns, learning curves and transfer. For operational agents, add bounded evidence: decision receipts, effect receipts, replay, failure injection and verified business outcome. Do not use task accuracy alone to evaluate a system whose claimed benefit is recoverability or explanation.

Build the intervention surface, not the museum

The lasting contribution of classical cognitive architectures is not a catalogue of modules to reproduce. It is the discipline of making commitments visible. Soar asks what happens when choice reaches an impasse. ACT-R asks what information is available through a constrained interface at a given moment. Blackboard systems ask how heterogeneous specialists can cooperate through shared hypotheses. Production systems ask which conditions made a procedure applicable and how competing procedures were resolved.

Foundation models answer a different historical weakness. They supply broad priors, flexible interpretation and candidate procedures at a scale that hand-authored architectures could not approach. That success should end nostalgia for encoding the world rule by rule. It should not turn every system concern into an invisible property of one model call.

The changed architecture decision is simple: start monolithic, then factor only under demonstrated separation pressure. Introduce working state when interruption tests require reconstruction. Separate knowledge when a controlled policy swap must preserve other behaviour. Add an authority kernel when a proposal can create consequence. Add an evidence ledger when an outcome must be reconstructed. Treat unresolved conflict as an impasse when guessing would hide risk.

Each boundary must survive the intervention test. Can it be changed independently? Does that change produce a predicted trace? Does the boundary improve recovery, attribution or selective modification enough to pay its latency and coordination cost? If not, remove it.

A capable model can occupy the centre of such a system, generate procedures and even learn how to route its own work. The architecture around it should remain modest. It is neither a mechanical soul nor a diagram of experience. It is a set of operational seams through which evidence, authority and change can be controlled. That is enough reason to recover cognitive architecture, and enough restraint to avoid rebuilding its museum.