Imagine an assistant helping an operations team resolve a customer-account problem. It encounters an access issue, proposes an alternative, receives approval for one specific recovery action, and reports that the service portal accepted the change. Later, the team lead confirms that the problem is resolved.

What should the assistant remember?

“Account problem fixed” is convenient, but incomplete. “Recovery initially blocked” is historically true, but no longer the current state. A transcript contains both statements, along with the approval, the attempted action and the final confirmation. A conventional summary might compress away the differences that matter most.

Those differences are the work.

The assistant needs to know what was requested, what was permitted, what it attempted, what the portal actually confirmed, and what the owner subsequently verified. It should retain the useful technical lesson without turning a one-time approval into permanent authority. And when someone asks about the incident next week, it should retrieve the current account—not an obsolete intermediate state.

This is the real problem of memory in agentic systems. It is not simply keeping more text. It is maintaining a trustworthy account of a changing world.

The architecture explored here is a proposed design, not a claim of a fully deployed system or measured production performance. The operational examples are hypothetical and industry-neutral; they do not describe any identifiable person, organisation or incident. The aim is to explain the principles, engineering trade-offs and failure modes behind memory that can support consequential work.

1. The archive is not the memory

A conversation archive answers a relatively straightforward question: what was recorded?

Useful memory must answer harder ones:

  • What remains true?
  • What was decided, and under which conditions?
  • Which earlier assumption was corrected?
  • What is unresolved?
  • How strong is the supporting evidence?
  • Who is allowed to use this information?

These questions cannot be solved by storage capacity alone.

A larger context window can keep more material available within an interaction. A search index can locate relevant passages across many interactions. Neither automatically determines whether a passage is current, whether two reports describe the same incident, or whether a remembered instruction applies to the present task.

Consider a report that appears in a worker’s output, a coordinator’s summary and a daily digest. Searching the archive may return three apparently supporting documents. But they could all descend from one unverified statement.

Three copies are not three confirmations.

A memory system therefore needs an account of evidence and change, not just an account of text. The archive preserves the record. Memory maintains the interpretation, with enough provenance to challenge that interpretation later.

2. Separate the jobs before choosing the tools

The proposed architecture separates five responsibilities.

Source evidence preserves what was said, attempted and observed: relevant conversation records, tool results and versioned references to documents or other artifacts.

Event relationships connect requests, approvals, assignments, attempts and outcomes. They establish which pieces of evidence belong to the same episode.

Daily memory distils useful continuity: decisions, significant outcomes, lessons, corrections and unfinished work.

Durable knowledge retains reviewed information worth reusing beyond the immediate episode.

Retrieval supplies the right permitted knowledge to the current task, preserving its status and limitations.

User preferences belong alongside these responsibilities, with their own scope and revision rules. A compact working view can surface current commitments and pending decisions without becoming another independent source of truth.

The separation matters because each responsibility has a different failure mode. A source can be missing. An event can be attached to the wrong task. A summary can overstate its evidence. A durable lesson can generalise too far. Retrieval can surface an obsolete revision.

Calling all five things “memory” makes these failures harder to diagnose.

It also encourages a common architectural mistake: adding a more sophisticated database before defining what a record means. A graph service cannot resolve an ambiguous approval by itself. A vector index cannot repair missing evidence. Infrastructure helps only after the semantic contract is clear.

3. Remember episodes, not isolated messages

Operational work rarely happens in a single message.

An operations team might investigate an inventory discrepancy across a spreadsheet, a staff conversation, a portal report and a subsequent correction. One assistant retrieves the report; another checks the arithmetic; the team lead clarifies that a shipment belongs to the following day.

Summarising each message independently produces fragments. Summarising only the final response may hide the reason the conclusion changed.

The better unit is an episode: a connected piece of work with intent, constraints, evidence and evolving state.

Episode assembly should begin with stable identifiers where available—task relationships, assignment references, message identities and artifact versions. Similar wording can suggest a connection, but should not silently merge unrelated incidents.

The resulting evidence packet should contain only what is relevant:

  • The objective and its boundaries.
  • Important approval changes.
  • Selected source excerpts.
  • Directly observed results.
  • Reports from other participants.
  • Existing memories that may need revision.
  • Missing evidence and contradictions.

This is not an argument for feeding every log into a model. It is an argument for assembling the smallest packet that preserves the meaning of the episode.

A completion marker is useful evidence about a process. It is not, by itself, proof that the business objective was achieved.

4. Capture at different moments, using one set of rules

Some information should be preserved immediately. Some should wait. Some needs a later review.

The mistake is to implement these as competing memory systems.

An immediate note writer, a background summariser and a nightly promoter can each look sensible in isolation. Together, they can duplicate claims, disagree about format and overwrite one another’s interpretations.

The proposed design uses several triggers but one shared decision contract.

Immediate capture: preserve important continuity

A direct correction, a meaningful decision, a significant result or an actionable blocker should not have to wait for a retrospective digest.

If the user says, “That approval was only for this customer account,” the boundary should be captured while the context is fresh.

But immediate capture still requires validation. The system should distinguish between a candidate being queued and a record being durably saved. “I’ll remember that” should not conceal a failed write.

Deferred capture: let an episode remain unfinished

Not every developing situation needs a settled conclusion.

If a reconciliation is waiting for a missing invoice, memory can preserve the blocker now while deferring the broader finding. The deferred item needs a reason, a missing-evidence description and a condition for reconsideration.

“Defer” should mean “tracked for review,” not “discarded politely.”

Periodic reconciliation: check what the first pass missed

A periodic review can connect later outcomes to earlier notes, revisit pending evidence and recover important details missed during active work.

Its job is reconciliation, not mandatory content production. A quiet period should produce no filler.

Crucially, a review that writes nothing needs to explain why. Nothing new happened, the information is already captured, the material is low-signal, the episode is unsettled, and a source is inaccessible are different outcomes.

Treating all five as “successful, zero writes” creates an attractive dashboard and a misleading system.

5. Make every memory answerable to its evidence

A useful memory record needs more than a title and a paragraph.

At minimum, it should identify the claim, the episode it belongs to, its owner, relevant dates, supporting sources, current status and permitted audience. It should also record how the claim was established.

“User stated,” “directly verified,” “reported by another assistant” and “inferred” are not interchangeable labels.

There are two distinct questions:

  1. How strong is the evidence?
  2. How confident are we in the interpretation?

A tool result may be unambiguous evidence that a portal displayed a success message. It may still be insufficient evidence that a downstream business process completed. Conversely, an explicit user preference can be strong evidence of that preference even if it appears only once.

Artificially precise confidence scores do not solve this. A label accompanied by a reason is often more honest than an unexplained decimal.

Dates need similar care. The time an event occurred, the time it was captured and the time it was revised may differ. A conversion script’s timestamp must not become the supposed date of the underlying decision.

References also need to survive change. A path to a document is not enough if the document is routinely overwritten. Important references should include a version, content fingerprint or stable source identity, with a permitted excerpt when necessary.

The goal is not to make every memory bulky. It is to keep the readable claim concise while preserving a reliable route back to its basis.

6. Corrections should change the current answer, not erase history

Suppose an assistant recommends one process, learns that the recommendation was based on a mistaken assumption, and later verifies a different approach.

A weak system stores all three notes and hopes search finds the newest one.

A trustworthy system creates an explicit revision relationship.

The original record remains available for historical questions. The current view points to the corrected claim. Retrieval excludes obsolete claims by default, or clearly marks them as superseded when they are relevant to the explanation.

This supports two different questions:

  • What should we do now?
  • What did we believe at the time, and why did that change?

Both are legitimate. They require different views of the same history.

Deduplication must follow the same logic. If a later message merely repeats an existing claim, it can be linked or skipped. If it adds a new approval boundary, contradiction or confirmation, it is not redundant simply because the topic is familiar.

Good deduplication removes repetition without removing change.

7. Daily memory and long-term knowledge have different standards

A daily note can be valuable without deserving permanent retention.

“The supplier has not sent the revised sheet” is useful continuity. It should remain visible while the work is pending. It is not necessarily a durable lesson about that supplier or the business.

Long-term memory requires another judgment: what abstraction is supported, useful and appropriately scoped?

A repeated failure might support a conditional operational lesson. A single explicit preference may justify a profile update. A speculative personality inference should remain tentative, even if several assistant-generated summaries repeat it.

Promotion should examine supporting evidence, counterevidence, existing records, scope and conditions under which the claim may expire.

It should produce a reviewable change: create, revise, merge, reject or defer.

Starting in proposal-only mode is a sensible restraint. It lets people inspect what the system would make durable before allowing it to change future behaviour automatically.

Memory volume is not the objective. Reducing the user’s need to reconstruct important context is.

8. Ownership, privacy and permission are separate dimensions

A multi-agent system can share a memory architecture without sharing every memory.

A domain assistant may maintain a technical lesson. A coordinating assistant may maintain the approval boundary and the final user-visible outcome. Those records can refer to the same episode while serving different purposes.

Four concepts should remain separate:

  • Who maintains the record.
  • Who may read it.
  • What kind of information it contains.
  • How long it is expected to remain useful.

A personal preference does not become workplace context merely because the same assistant participates in both conversations. Discovering a file does not confer permission to read it. An unknown access scope should not default to global visibility.

Permission checks should happen before retrieved content reaches the model, not after the model has already seen it.

There is also a deeper boundary: memory is not new authorization.

Remembering that an owner approved a particular action does not authorize a similar action tomorrow. The approval must retain its task, resource and action boundaries.

Likewise, a retrieved document can contain instructions without having authority over the assistant. Source material remains evidence to interpret under the current request—not a back door for changing operating rules.

9. Persistence needs a recovery protocol, not optimism

Even a carefully reasoned memory is useless if it disappears during a crash. A poorly managed retry can be just as harmful if it writes the same claim repeatedly.

A practical file-backed design can use an append-only record journal, a readable daily view and a rebuildable search index. The journal governs new managed records; the daily view serves people; the index serves retrieval.

These surfaces do not update in one magical atomic transaction.

A process can commit a record and crash before updating the readable view. It can update the view and fail before refreshing search. The recovery protocol must distinguish these states.

A proposed write sequence is:

  1. Save an identifiable candidate and its evidence references.
  2. Validate permission, format and the expected current revision.
  3. Acquire the appropriate writer lock and check for competing changes.
  4. Record the intended transaction.
  5. Commit the canonical revision.
  6. Update and verify the readable view.
  7. Settle source progress and queue the index update.

Recovery should resume incomplete work without creating a second logical memory.

“Effectively once under retry” is a more defensible goal than claiming globally exactly-once execution across every component.

Progress tracking needs similar precision. Evidence can be scanned but not yet interpreted, or interpreted but not durably committed. Advancing one generic checkpoint beyond unfinished work can create permanent omissions.

A missing source should block dependent claims, not every unrelated task. Healthy sources can continue while the system reports partial coverage honestly.

10. Retrieval is where memory earns its value

A record on disk is an implementation fact. A correct answer at the right moment is the product outcome.

Retrieval should first establish the requester, audience and purpose. It should then distinguish a current-state question from a historical question, a procedure request or a search for unfinished commitments.

Search can combine exact identifiers, lexical matches and semantic similarity. But the returned context should include more than a matching paragraph. It should carry the claim’s date, status, evidence class, scope and known gaps.

An assistant should not turn “another worker reported success” into “I independently verified success” merely because the information arrived through memory.

Freshness also matters. The index should expose which revision it has processed. A stale semantic index may justify a permitted direct-record lookup or lexical fallback. It does not justify saying that nothing happened.

Corrections and deletions must invalidate affected cached context. Otherwise, the archive can be correct while the assistant continues to answer from an obsolete snippet.

The strongest tests therefore exercise the actual assistant path: can it retrieve the corrected process, preserve a narrow approval, identify an unresolved commitment and abstain when the evidence is insufficient?

11. Forgetting is part of responsible memory

Auditability does not justify retaining everything forever.

Different sources need different retention rules. A transient access state, a business procedure and an explicitly stated communication preference do not have the same useful lifetime or sensitivity.

Deletion is also more than removing a paragraph from a readable file. A removed claim may remain in an index, cache or derived view. It may be recreated during the next rebuild unless the system records that the deletion was intentional.

A protected deletion record can prevent this resurrection. Backup limitations should be stated honestly rather than hidden behind a promise of instant universal erasure.

The same principle applies to user understanding. Inferred preferences should remain revisable, purpose-bound and distinguishable from direct statements. A system should become better at helping someone, not more confident in an unchallengeable model of their personality.

12. Migrate without rewriting the past

Existing systems usually have several memory-writing paths: direct notes, background jobs, completion hooks, validators and maintenance tools.

Before introducing a common writer, those paths must be inventoried. Disabling a scheduled job does not prove that a completion hook stopped mutating the same files.

Validation should be genuinely read-only. Compatibility readers can interpret older formats without rewriting the archive. Unknown fields should remain unknown rather than being coerced into a broader scope or a false certainty.

New managed records can coexist with historical prose while preserving human edits. Only clearly designated regions should be regenerated, with change detection before replacement.

Rollback should preserve new knowledge. Restoring an old daily file wholesale may undo a software change by deleting valid records created afterward. Safer rollback changes executable behaviour while retaining committed revisions and pending evidence.

A migration is successful when correctness improves without destroying the history needed to explain it.

13. Measure usefulness, not the number of notes

A memory pipeline can generate thousands of well-formatted entries and still fail its user.

Evaluation should measure whether meaningful episodes are captured, unsupported claims are excluded, corrections replace obsolete answers and private context stays within its audience.

Useful test cases include:

  • A crash between record commit and view update.
  • Duplicate triggers after a restart.
  • A result available only through a tool artifact.
  • A missing transcript.
  • A correction arriving after the original episode was summarised.
  • A narrow approval that resembles a broader permission.
  • More worthwhile candidates than one batch can process.
  • A stale index returning an earlier revision.
  • A deletion that must survive rebuilding.

Tests need clear denominators, held-out examples and visible failures. Proposed accuracy targets are not achieved results. A small passing suite is not proof of universal reliability.

Operational metrics matter too: oldest pending evidence, age of unresolved gaps, correction latency, projection lag and index lag. “The scheduled job ran” is not a substitute for any of them.

A sensible rollout proceeds from a reproducible baseline to compatibility tests, safe writes, evidence assembly, shadow comparison and a narrow live trial. Durable promotion can remain review-only until its quality is demonstrated. Retrieval should be tested throughout, not added at the end.

The goal is not perfect recall

Perfect recall is the wrong promise.

A useful assistant should remember what matters, preserve what remains unfinished, revise what was wrong and explain what it knows. It should distinguish a requested action from an attempted action, an attempted action from a verified outcome, and a verified outcome from permission to act again.

It should know when a source is missing. It should avoid creating memories merely to demonstrate activity. It should let people correct it without fighting an accumulated history of its own assumptions.

The central design principle is simple:

An AI memory system should not merely preserve the past. It should maintain an accountable relationship between evidence, interpretation and present action.

That relationship—not the size of the archive—is what makes memory worth trusting.