State and Working Memory

Goal

Represent the information an agent needs for the current run as explicit working state, and keep that state small, typed, and separate from the full conversation transcript.

An agent makes later decisions from what happened earlier. That means it needs state: information that survives from one cycle to the next.

State can contain trusted facts, progress markers, counters, the active subgoal, approval status, and recent observations. The subset needed for near-term decisions is often called working memory.

The term sounds human, but here it is an engineering structure. It can be a dictionary, object, or database row.

Start with explicit fields

For the running support example, a useful state might be:

{
  "goal": "resolve order 4172",
  "order_status": "delivered",
  "damaged": true,
  "active_subgoal": "check refund eligibility",
  "approval_status": "not_requested",
  "step_count": 2
}

Each field has a purpose. Application code can validate the type and update rules.

Compare that with storing only a long transcript and hoping the model remembers which order status is current. The transcript is still useful evidence, but explicit fields make critical state easier to inspect and test.

Working memory should be selective

Not every past sentence belongs in current working memory.

Suppose the agent has already looked up the order three times. Keeping all three raw responses in the active state may add noise. A normalized current fact such as order_status="delivered" may be enough, while the full raw responses remain in the audit trace.

This creates two useful layers:

• working state for current decisions;
• trajectory history for audit and debugging.

The first should be concise. The second can be more complete.

Track provenance for important facts

A fact is stronger when you know where it came from.

Instead of:

refund_eligible = true

you might store:

refund_eligible = true
source = refund_policy_tool
observed_at_step = 2

That helps distinguish a trusted tool result from a model inference or a user claim.

You do not need a provenance object for every trivial field. Use it where source identity affects correctness or authority.

State updates need rules

If a new observation contradicts an older value, do not silently keep both as if they are equally current.

Define update rules. A newer trusted order lookup may replace an older trusted order status. A model guess should not overwrite a trusted service result. An approval for one refund amount should not become a general approved=true flag.

State design is therefore part of safety, not merely bookkeeping.

Keep counters outside prose

Step count, retry count, repeated-action count, and cost budget should be numeric fields controlled by application code.

A prompt sentence saying “you have two steps left” can be useful context, but the real counter should live outside the model so the controller can enforce it.

Predict

The latest trusted order lookup says delivered, while an older transcript message says shipping. What should current working state contain?

The current delivered status, with provenance to the trusted latest lookupBoth statuses as equally current so the model can choose whichever fits the planOnly the oldest status because earlier observations should never be replaced

Run the local Lab

Run:

python labs/notebooks/level-11/l11-05-working-memory.py

The script feeds four observations into a small state object. Named fields (such as order_status) keep only the latest value, while recent keeps a short list of the last few events.

1. Run it unchanged. In working state:, find 'order_status': 'delivered'. The earlier shipping value was replaced, not added.
2. Count the events inside recent. There are 3: the second order event, the policy event, and the approval event. The first shipping event has dropped out.
3. Read audit event count: 4. The full event list still exists outside working memory.
4. Open l11-05-working-memory.py and change MAX_RECENT = 3 to MAX_RECENT = 2. Rerun.
5. Now recent holds only 2 events (policy and approval), but order_status, refund_eligible, and approval_status are unchanged, and the audit count is still 4.

The lesson: shrinking the working list does not lose the facts the agent needs, because important facts live in named fields, and the full history lives in the audit log.

Loading lab…

Quick Check

1. What is the main purpose of explicit working state in an agent?

To keep a full copy of every token from the conversationTo keep current facts and counters inspectableTo let the model overwrite counters when it thinks progress changed

2. Why keep trajectory history separate from concise working state?

Because history should be deleted as soon as the run endsThe loop needs a short current view; audits need the full recordBecause trusted tool results should be kept out of both records

3. Which value should application code control directly rather than trusting model prose?

A tentative wording choice for the final responseA descriptive summary of why the user cares about the taskThe numeric step counter used to enforce the run budget

0 of 3 questions answered.

Explain it back

List five fields your own bounded agent would need during a run. For each field, say whether it comes from the user, a trusted tool, application control logic, or model interpretation. Identify one field that should never be overwritten by model text.

Key Takeaways

• State carries important information across agent cycles.
• Working memory is a selective engineering structure, not the whole transcript.
• Important facts are easier to trust when their provenance is recorded.
• State updates need conflict and replacement rules.
• Budgets and counters belong under application control.

Next Lesson

Next, decide which information should survive beyond one run and how to keep long-term memory from becoming an uncontrolled pile of stale or sensitive text.

References

• Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models.