What should the agent remember?

IDEA 1

State changes during a run

Current task state holds what the program needs right now: a selected task ID, a tool observation, or an attempt count. Updating it helps the next step continue from what already happened.

Retained memory is a separate design choice. A room's availability observed earlier may become stale, while a learner's explicitly saved display preference might remain useful. Keeping both in one undifferentiated list hides their different lifetimes.

Research connection: Generative Agents explored virtual characters whose recorded experiences, retrieved memories, and generated reflections inform later plans. Believable simulated behavior is not evidence about a real student's personality. In your own helper, label a directly supplied preference differently from a model's inference, and retain only what the task needs.

Two facts, two lifetimes

1. Task state. The current task needs a selected room, temporarily.
2. Retained note. An explicitly permitted preference can be saved with provenance.
3. Next run. Reuse only after checking the memory's owner and lifetime.

All owners and preferences in this exercise are fictional IDs.

State is not automatically memory

let state = { selectedRoomId: null };
state.selectedRoomId = "cedar";
// A separate save operation would be needed for retention.

Assigning a local variable changes this run. It does not automatically create a durable record or authorize retaining that value.

Think it through: Which belongs naturally in temporary task state?

IDEA 2

A session has a lifetime

A session groups one interaction's events and state. Persistence depends on the storage implementation: an in-memory store generally disappears when its process restarts, while a database can retain records according to its configured lifecycle.

This lab simulates a restart inside one execution: it resets task state while keeping an authored memory store for the demonstration. The store is not saved to your account or browser. The contrast teaches lifecycle, not a claim that memory survives between actual lab runs.

Simulate a restart

1. Before. Temporary state holds a selected room.
2. Restart. The exercise resets the current task.
3. Inspect. A separately retained classroom store may still contain a permitted note.

The whole demonstration runs inside one isolated execution.

Explicit lifecycle

let taskState = { selectedRoomId: "cedar" };
taskState = { selectedRoomId: null };
const saved = tools.readMemory(input.owner);

Resetting taskState and reading the separate store are different operations. Whether a real store survives a restart depends on its backend, not the word memory.

Think it through: What actually persists between runs of this classroom lab?

IDEA 3

Retain only useful, permitted information

A retained fact should have an owner, a source, and a deletion or expiry rule. Our tool accepts a learner-supplied preference only with an explicit remember flag. It preserves source: learner so later code knows where it came from.

Reading also needs checks. The tool returns only notes for the requested owner. The controller rejects expired notes, and at the exact expiry day treats the note as expired. These are classroom policy rules, not a complete privacy or authentication system.

A memory earns reuse

1. Permission. Save only a learner-provided preference they asked to retain.
2. Ownership. A note for learner-b must not be returned for learner-a.
3. Expiry. At expiresDay, clear the note instead of reusing it.

Day numbers are synthetic; expiry is part of the exercise's written contract.

Keep provenance and deletion visible

if (memory && memory.expiresDay <= input.day) {
  tools.clearMemory(input.owner);
  memory = null;
}

The condition uses <= so expiry is exact, not one day late. Clearing the record implements the exercise's deletion rule rather than merely hiding it from the display.

Think it through: A club helper finds another learner's note saying they prefer quiet rooms. Should it reuse that note for you?

Put it into practice

Simulate a restart, save only on request, isolate owners, and remove an expired note.

1. Inspect the existing memory record, owner, and synthetic day in each case.
2. Run the starter; the expired note is currently reused.
3. Insert the expiry-and-clear snippet before the restart.
4. Run all cases and inspect which reads, writes, and deletions actually occurred.

Your next experiment: Change expiresDay to 11 while day stays 10. Predict whether the note survives this simulated restart.

Saved information needs an owner, source, purpose, and lifetime; memory does not make a fact true.

Key terms

Session

One interaction's events and state, with a lifecycle defined by the application.

Provenance

Where a piece of information came from.

Expiry

A declared point after which a stored value should no longer be reused under the task's rules.

Sources and scope

Original Stemtiq teaching, reviewed 2026-09-14. The named researchers and organizations do not endorse this course. Classroom cases are authored exercises, not published findings.