Goals, Beliefs, Constraints, and Memory

Our first shopper prototype maintained variables such as irritation, patience, tolerance, curiosity, and trust.

After each browser step, rules updated those values. If frustration crossed a threshold, the shopper might change plans or leave.

The state machine made the system inspectable. It also created false precision. What did “irritation equals 0.7” mean? Why should one page move it from 0.4 to 0.7? A rule could trigger abandonment when a real shopper might simply continue.

We later experimented with richer persona prompts, a Belief-Desire-Intention structure, and several approaches to memory. Those mechanisms made it easier to preserve context and debug a journey. They did not, by themselves, show that the state matched a person’s internal process.

That distinction is central:

Structured state is an operational model of what the simulator may know and use. It is not a reconstruction of a human mind.

The purpose of state is to make behavior testable. We should be able to inspect what the agent was trying to do, which evidence it had encountered, what it believed, which constraints applied, and why the next action was available.

Memory alone cannot provide that structure.

Grounding and state are different

Grounding is the evidence the system is allowed to use about a person, segment, task, or population.

State is the simulator’s current, revisable representation during a run.

An interview may report that a shopper usually compares prices. That belongs in the grounding bundle. During a specific journey, the shopper may be rushing to buy a gift before a deadline. That active goal and constraint belong in state. When the shopper sees a delivery date, the observation may change the plan.

Collapsing all three into one persona prompt creates several problems:

• old and current information receive similar authority;

• facts, beliefs, preferences, and constraints become difficult to distinguish;

• the model may use evidence the simulated user has not encountered;

• contradictions are resolved silently;

• generated explanations can invent state after an action has already been chosen.

A structured model does not eliminate those errors. It makes them visible enough to test.

A practical user-state schema

The smallest useful schema depends on the task. For a journey simulator, these fields provide a reasonable starting point:

This is not a universal cognitive theory or a required checklist. It is a menu for debugging and evaluation. A system should omit fields that do not affect the task or evidence.

The distinctions matter because different state types should behave differently.

A goal can be completed, abandoned, or replaced. A constraint should block or penalize actions. A belief can be wrong. The knowledge state should be limited to visible or retrieved information, and encountering a statement does not make it true. A preference may apply only when stronger goals and constraints do not dominate. Context can change quickly. Memory should preserve where a statement came from.

If every field is simply another sentence in the prompt, those semantics depend on the model interpreting them correctly on every step.

Represent propositions with a lifecycle

State becomes more useful when consequential propositions carry metadata.

A lifecycle might look like:

Grounded evidence or observation → Candidate proposition → Active, uncertain, or rejected → Reinforced, revised, contradicted, superseded, expired, or archived

Two distinctions are especially important.

Supersession is not contradiction

If a store changed its return policy in June, a policy from March may be accurate historically and stale now. The newer policy supersedes the older one.

If two current pages describe different return policies, the evidence is contradictory. The simulator should not silently select whichever statement makes the next action easier.

Unknown is not low-confidence fact

If the shopper has no evidence about returns, the state is unknown. A low-confidence belief may exist when there is weak evidence. Those conditions can produce different behavior.

An unknown may lead the shopper to search, ask, delay, branch the decision, or proceed while accepting risk. A fabricated preference removes that uncertainty from the journey.

Memory is a source, not a decision

Memory systems often combine three different functions:

1. storing what happened;

2. retrieving what appears relevant;

3. summarizing what the history means.

Each can fail independently.

The event log may omit an observation. Retrieval may surface the wrong episode. A summary may convert a tentative inference into a stable trait. Once that summary is fed back into the model, later actions can make the invented trait appear consistent.

The influential Generative Agents architecture stored observations, retrieved memories, generated higher-level reflections, and used them for planning. Its ablations showed that observation, planning, and reflection contributed to the believability of behavior in the paper’s interactive sandbox.

That is a useful architecture result. It is not evidence that the reflections reproduced the hidden mental states of real people. Believability was the measured target.

More recent work on General User Models offers another relevant pattern. It converts computer-use observations into confidence-weighted propositions, retrieves related propositions, and revises them when new evidence reinforces or contradicts prior information. The system keeps underlying observations and metadata connected to the proposition.

General User Models are designed for contextual assistance rather than user simulation. Their value here is architectural: they show how inferred user context can remain revisable and evidence-linked instead of becoming one permanent profile paragraph.

The same work also exposes the cost. Continuous observation can reveal highly sensitive information, and a confident proposition can still be an inference. A structured memory system needs data minimization, user control, and claim boundaries, not only better retrieval.

Do not update everything after every event

Our early shopper model recalculated emotional state after each page. This made the agent too sensitive to weak signals.

State persistence matters. A new observation should update the fields it has evidence to change, not regenerate the entire user.

For example:

• a newly revealed delivery date may update the knowledge state and the feasibility of a goal;

• a hidden fee may update price belief, appraisal, and intention;

• a visual redesign should not automatically rewrite a long-term preference;

• a navigation error by the execution agent should not become evidence that the simulated user changed personality.

This requires explicit update rules or at least typed update proposals that can be inspected. It also requires preserving the pre-update state, triggering observation, proposed change, and resulting action in the trace.

Without that record, a simulator can rationalize any behavior after the fact.

State fields must earn their place

Structured state creates engineering work and can make a system look more scientific than it is. Every additional field should face an ablation.

A practical comparison could test:

Select the reduced state on development tasks, then evaluate it on separate held-out journeys. Reusing the same journeys for selection and evaluation would reward a schema tuned to those examples.

The evaluation should not stop at persona consistency. It should examine:

• whether the agent uses only information it has encountered;

• whether constraints actually change available actions;

• whether controlled changes to a state field alter subsequent actions in the expected direction;

• whether contradictions and unknowns produce reasonable search or clarification;

• whether action paths better overlap with observed users;

• whether added structure reduces or increases run variance;

• whether the same value can be achieved with fewer fields.

Different outcomes support different conclusions.

If typed state reduces contradictions and makes failures reproducible, it improves engineering quality. If it changes explanations but not actions, it improves inspectability or narrative consistency. If it improves held-out action similarity against real users, it provides bounded evidence of behavioral value.

None of those results automatically establishes general prediction.

The useful model is the one we can revise

A simulated user should not know everything in the grounding data, remember every detail, or maintain one permanent preference profile.

It should have a bounded goal, incomplete information, task-relevant constraints, explicit unknowns, and a state that changes only when evidence supports the change.

The test is not whether the state sounds psychologically sophisticated. The test is whether it helps us explain and evaluate action better than a simpler representation.

Goals, beliefs, constraints, and memory are useful because they separate reasons a journey can change. They give us something to inspect, remove, compare, and falsify.

The next article places that state inside the world. A user does not act from internal state alone. Visible information, interface affordances, device limits, latency, institutional rules, and prior actions determine what can happen next.