Four Kinds of State, Four Lifecycles
Run state, session history, workflow checkpoints, and long-term memory have different lifecycles and recovery semantics. One messages array cannot hold all four.
A single messages array cannot hold everything an agent knows. Run state, session history, workflow checkpoints, and long-term memory have different lifecycles and recovery semantics. Flatten them into one structure and you lose both properties that matter: you cannot expire what should expire, or recover what should survive.
One table, four lifecycles
| State | Scope | Purpose |
|---|---|---|
| Run state | One run | Current step, budget, interrupts |
| Session history | One session | Message continuity |
| Workflow checkpoint | One workflow instance | Resume, replay, human pause |
| Long-term memory | Across sessions | Preferences, verified facts |
The table is about write rate, retention, and deletion rules. Run state can die with the process, session history can be truncated, a checkpoint has to be replayable, and memory has to be retractable by source. In one array you cannot set a rule for any of them: give memory a TTL and you have quietly made checkpoints expirable too.
Business facts cannot live in framework memory
The memory object your framework hands you is a cache, not a database. Order status, approval records, the metric definition a user signed off on belong in storage you own, with the agent holding a reference. It is tied to the framework, so one migration loses it; it lives in the process, so a crash takes it; and it carries no source or validity period.
Separate inference from verified fact the same way: inference in context, facts in a ledger. Mix them and the next agent treats last turn's speculation as evidence.
Classify memory by how it recovers
Five things hide behind the word memory agent-trend-2026:
- Working state can be replaced by a newer checkpoint. Do not persist it.
- Event history is append-only. Summaries compress context; audits read the original records.
- Domain knowledge keeps versions and sources. When a source changes you re-validate.
- Preferences decay and need correction. "Always do it this way" from three months ago may not hold.
- Credentials and identity stay in a dedicated privacy boundary, never in the general store.
If a task can finish without state, keep it short-lived. Persistence charges you for privacy, decay, and migration.
Memory is an enhancement, not a dependency
When retrieval fails or times out, return an empty result, log a warning, and keep going. Load long-term memory and short-term context on parallel paths and join them; neither should block the other.
The implementation behind an enterprise MultiAgent platform at Poizon is worth copying. A dedicated thread pool, not the shared common pool, launches two futures at request entry. Long-term memory gets a 4,000 token budget with a 60 percent ceiling for profile data, and whatever the profile does not use goes to task experience. Truncation happens line by line so one memory keeps its full meaning. The async consolidation chain writes the new memory before deleting the old one, because an external memory service cannot wrap insert and delete in a transaction: write-first means the worst case is one redundant entry, not a lost one poizon-memory.
Structure decides whether you can find it again
Every extra directory level doubles the choices an agent makes to locate one memory. So cap it: two levels, files only below the second, and absorb growth with filename prefixes instead of new folders. Wanting a third level usually means avoiding the decision about which category a memory belongs to personal-ai-memory.
Two practices go with it. Index first: a top-level index with one line of title and description per entry, so the agent scans the map before reading any body text, plus a README per directory declaring what belongs there. Use tags for themes that cross directories rather than splitting folders further. Mark uncertain information as "pending" instead of leaving a blank.
One personal memory system also refuses full automation: every entry needs human confirmation before it is written. Automatic capture sweeps in half-formed judgments, and over time the store freezes the version of you that exists today instead of the better one.
What shape the memory sits in
The storage format is not a style choice. It decides which later operations are possible at all, and the four formats in circulation form a clean cost gradient ai-agent-book:
| Format | Shape | What it costs |
|---|---|---|
| Simple Notes | One minimal, indivisible fact | Near-free, O(1) reads and writes; every link between facts gone |
| Enhanced Notes | A paragraph with full context | Semantically intact; redundant storage, and one changed attribute rewrites many paragraphs |
| JSON Cards | Category, subcategory, key-value | Partial updates and predictability; assumes every fact classifies cleanly |
| Advanced JSON Cards | Adds backstory, person, relationship, timestamps | Best at disambiguation and cross-session linking; costlier and slower to maintain |
Choose by volume and consequence. Facts that are critical and few belong in Advanced JSON Cards; facts that are many and incidental belong in Simple Notes, and most production systems run both. Rigid categories have a specific price: "builds a personal project in Python on weekends" is simultaneously a time preference, a technology preference, and an activity, and filing it under one heading deletes the other two. On the other end of the same axis, a handful of structured key facts resident in context as the overview, with raw conversation retrieved on demand as the detail, is what makes proactive service work — resident-only loses the detail, retrieval-only never sees the whole picture.
The step past text is executable state. All four formats above are text: good at recalling one fact, and they leave aggregation, conflict detection, and constraint enforcement to the model's mental arithmetic. The alternative types user state as objects and writes rules as ordinary functions, borrowing write-ahead log plus checkpoint: append facts to an append-only log when a session ends, then periodically rebuild the typed state from the full log. Evidence stays in the log; queryable, checkable state comes from code ai-agent-book. Which is the division this chapter has been drawing all along: evidence is appended, state is recomputed.
Make eviction asymmetric
Bad experience should be evicted several times faster than good experience is reinforced. If one disproven memory accumulates at the same rate as ten verified ones, a few mistakes steer the agent off course, and correcting it takes ten times the evidence. Rule-level memory is the dangerous case: it changes how every future task runs, so it needs human confirmation first.
Audit any memory with three questions: where did it come from, when does it stop being true, and how do you delete it? If you cannot answer, it is context that happened to be persisted.