SOAR and AI Agents

What can AI agents borrow from SOAR?

Not the claim that software has a human mind.

Not the idea that a language model becomes cognitive architecture because it has a prompt and tools.

The useful lesson is more practical.

An agent needs a current state. It needs possible next steps. It needs a way to choose between them. It needs to handle uncertainty without guessing. It needs to learn from solved problems without turning bad outcomes into habits.

SOAR gives clear words for those jobs.

State before action

A good agent should know what situation it is in.

That sounds obvious, but many systems blur it. They pass a long prompt, some retrieved text, and a tool list into a model, then hope the next step makes sense.

SOAR starts with state.

For AI agents, that means the current task should be explicit:

goal
user
available facts
selected tool
last result
risk level

The exact fields depend on the product. The principle is stable: action should come from a readable state.

Operators before free-form action

SOAR uses operators as possible next steps.

AI agents can borrow that idea by representing common next steps as operators: retrieve, ask, summarize, call a tool, retry, escalate, wait, or stop.

The point is not to remove the model. The point is to stop making every next step feel invented from scratch.

When the state is explicit and the operators are known, the system becomes easier to test.

Impasses before silent guessing

SOAR treats stuck points as part of problem solving.

That is a good habit for agents.

If no tool fits, say that. If two actions conflict, create a review step. If required information is missing, ask for it. If the rule is unclear, make a subtask.

An impasse is better than a confident wrong action.

Learning needs boundaries

SOAR can learn from problem solving. AI agents should too, but with care.

If a workflow keeps helping, the system should remember the pattern. If an error handler fixes the same issue again and again, it should become easier to choose. If a human reviewer corrects a bad path, the system should learn that as well.

But learned behavior needs boundaries.

A learned shortcut can violate policy. A repeated preference can become stale. A rule that helped one team can harm another.

So an AI memory system needs review, decay, permissions, and audit trails around learned behavior.

What Achiral borrows

Achiral is SOAR-inspired in the same careful sense that it is ACT-R-inspired.

We borrow design language, not identity.

From SOAR, the useful ideas are:

• working memory for the current state
• operators for possible next steps
• preferences for choosing between operators
• impasses for moments when the system is stuck
• subgoals for smaller problems
• chunking for learning from resolved problems
• semantic and episodic memory for different kinds of stored knowledge

These ideas help AI builders separate memory from action and action from judgment.

The takeaway

SOAR is useful for AI agents because it makes problem solving visible.

The agent is not just a model call. It has a state, candidate actions, selection pressure, stuck points, and memory of what has worked before.

That is the lesson worth borrowing.

Sources

• Soar homepage, University of Michigan
• The Soar Architecture
• Procedural Knowledge Learning in Soar
• Semantic Memory in Soar
• Episodic Memory in Soar

Go back to Semantic and Episodic Memory in SOAR, continue with ACT-R Memory vs Agent Memory, or return to the Concepts hub.