SOAR: An Architecture for General Intelligence

TL;DR. In 1987 Newell, Rosenbloom, and Laird proposed that a complete intelligent agent needs exactly one control structure: all deliberation is search in problem spaces, all long-term knowledge is if-then productions, and whenever the agent gets stuck (an impasse) it recursively spawns a subgoal whose solution is compiled into a new production (chunking), so the agent literally learns by getting unstuck. SOAR failed to scale for one reason — every production had to be hand-written, so it had no world knowledge and no perception — and that is precisely the gap LLMs now fill, while LLM agent frameworks busily reinvent impasse-driven subgoaling and experience caching without SOAR's principled machinery.

The idea as they had it

The paper arrives at the peak of the expert-systems era. The state of the art in deployed AI was R1/XCON configuring VAX computers with thousands of hand-written rules; the state of the art in theory was Newell's decades-long program (from GPS onward) to find a unified architecture rather than a bag of methods. SOAR was the bet that one mechanism suffices.

The architecture is austere. Working memory holds the current situation. Long-term memory is a single, uniform store of productions — condition-action rules — with no distinction between "procedures," "facts," and "control knowledge." Behavior unfolds in a fixed decision cycle: first an elaboration phase, where all matching productions fire in parallel, monotonically adding whatever they know — facts, proposed operators, preferences among them ("operator A is better than B here"). Then a fixed, knowledge-free decision procedure reads the preferences and selects the next problem space, state, or operator.

The elegance is in what happens when the decision procedure cannot decide. If no operator is proposed, or two tie, or the selected operator produces no change, the architecture — not the programmer — declares an impasse and automatically creates a subgoal: "resolve this impasse." The agent then brings its full machinery to bear on that subgoal, recursively, using whatever problem space is relevant (including look-ahead search, means-ends analysis, or asking for advice — these are not built in; they emerge from knowledge). This is universal subgoaling: the goal stack is generated by the architecture from its own ignorance.

Chunking closes the loop. When a subgoal resolves, SOAR traces which working-memory elements the resolution actually depended on, and compiles a new production: those conditions → that result. Next time the same situation arises, the production fires in the elaboration phase and the impasse never occurs. Deliberation transmutes into reflex. Rosenbloom and Newell had earlier shown this mechanism reproduces the power law of practice in human skill learning, which is why they believed it was not just an engineering trick but a theory of cognition.

Why it could not work then

The paper is candid that SOAR is "knowledge-lean." Every production was written by a graduate student. The demonstrations were the Eight Puzzle, blocks world, Towers of Hanoi, and R1-Soar — a reimplementation of a slice of XCON with a few hundred productions. The largest Soar systems ever built (TacAir-Soar, in the 1990s) reached roughly 8,000 hand-coded rules after years of effort. Compare what the architecture needed to be a general agent: something like a human's world knowledge, which no rule-writing effort could approach. This is the classic knowledge-acquisition bottleneck, and chunking couldn't bootstrap out of it — chunking only caches what the agent could already derive from existing productions. Zero knowledge in, zero knowledge compiled.

There was also no perception. Working memory was populated by hand-typed symbolic structures; SOAR could not see a chessboard, let alone a kitchen. And hardware pinched: a 1987 workstation ran at roughly 1–3 MIPS with maybe 4–16 MB of RAM, and the Rete match over a growing production set was the bottleneck — chunking famously risked the utility problem, where learned rules with expensive match conditions made the system slower, not faster.

What changed

Two things. First, LLMs solved the exact problem SOAR could not: broad, cheap, immediately usable knowledge, plus perception (vision-language models turn pixels into working-memory-like descriptions). A frontier model is, functionally, an elaboration phase trained on trillions of tokens — it proposes operators, evaluates them, and supplies world knowledge on demand, no rule-writing required.

Second, and more telling: LLM agent frameworks have been rediscovering SOAR piecemeal. ReAct-style loops are a degenerate decision cycle. "The model seems stuck, so spawn a sub-agent with a narrower goal" is universal subgoaling, hand-rolled. Voyager's skill library — cache verified code for solved Minecraft tasks and retrieve it later — is chunking, almost literally. Reflexion is impasse-triggered learning. What none of these have is SOAR's discipline: a uniform trigger for subgoaling (the impasse taxonomy: tie, conflict, no-change), a uniform learning mechanism tied to the dependency trace of the solution, and a single memory rather than N ad-hoc stores. Sumers et al.'s CoALA paper (2023) made this point explicitly, framing language agents in cognitive-architecture terms; it reads like SOAR's ghost auditing the field.

A serious 2026 revival

Keep from the paper: the decision cycle, the impasse taxonomy, universal subgoaling, and learning-as-caching-of-derivations. Replace: hand-written productions and purely symbolic working memory.

Concretely:

• Working memory is a structured context: current state, proposed operators, preferences — maintained as text/JSON, not raw chat history.
• Elaboration is a two-tier match. Tier 1: a library of compiled skills (verified code functions and cheap retrieval rules) fires deterministically, exactly like productions. Tier 2: only if tier 1 leaves gaps, the LLM is called to propose operators and preferences.
• Impasses are detected architecturally, not by prompt vibes: no operator proposed, top candidates within \epsilon of each other under a preference score, or k cycles of no state change. An impasse spawns a subgoal with a fresh, focused context — SOAR's answer to context-window rot.
• Chunking is the interesting engineering. When a subgoal resolves, trace which inputs the solution depended on (the LLM can annotate its own dependencies; verification comes from execution — tests pass, task completes). Distill the trace into the cheapest sufficient form: a retrieval rule, a code skill, or — for fuzzy competences — training data for a periodic LoRA update. The Voyager result suggests code-as-chunk is the practical sweet spot: verifiable, composable, and immune to the drift that plagues distillation into weights.

The payoff over current agent frameworks: the expensive, stochastic LLM is called only at genuine impasses, and its successful reasoning permanently migrates into fast deterministic machinery. Amortized cost per task falls with experience — SOAR's power law of practice, now with dollar signs on the y-axis.

Already tried, and what's open

SOAR never died. Laird's group evolved it continuously — Soar 9 added reinforcement learning, episodic and semantic memory, and mental imagery (see The Soar Cognitive Architecture, MIT Press, 2012) — and there is recent work from that lineage on integrating LLMs into Soar as a knowledge source. On the LLM side, Voyager, Reflexion, and the skill-library pattern generally vindicate chunking; CoALA vindicates the framing. So the thesis is partially confirmed from both directions.

Still open, and genuinely hard:

• Chunk correctness. SOAR's chunks were sound because productions were sound; an LLM-derived chunk is a generalization from one stochastic trace. When is it safe to compile? Execution-verified code helps but doesn't cover fuzzy skills. This is the old EBL utility problem (Minton, 1988) wearing new clothes — and SOAR's own history shows learned chunks can degrade performance.
• Dependency tracing. SOAR knew exactly which working-memory elements a result depended on. Getting faithful dependency annotations out of an LLM is unsolved; unfaithful ones produce over-general chunks that fire wrongly.
• The uniform-memory bet. SOAR claimed one memory suffices; modern evidence (and Soar 9 itself) suggests episodic, semantic, and procedural stores really are different. A revival should probably drop this claim.

One bibliographic note: the link below resolves to the DTIC technical-report version; the canonical citation is Artificial Intelligence 33(1):1–64, 1987, one of the most-cited papers in the field's history (the "cited 6 times" in the record refers only to the report DOI).

Where to read it

The paper: https://doi.org/10.21236/ada188742. Read alongside: Newell's Unified Theories of Cognition (1990) for the full argument; Laird's The Soar Cognitive Architecture (2012) for what 25 more years of engineering taught; Sumers et al., "Cognitive Architectures for Language Agents" (2023) for the modern mapping; and Wang et al., "Voyager" (2023) to see chunking reinvented in Minecraft, working, and unaware of its ancestry.