Memory is not the transcript

A conversation records what someone said or what the system presented. It matters for continuity and reference resolution. It should not automatically become the current truth about an ERP record.

A supplier invoice discussed in August may have been corrected in September. The history should preserve the earlier discussion without silently overriding the current authoritative record.

A running task has its own lifecycle, outstanding waits, evidence and results. A work surface can have filters, selections and unsaved edits. None of that is inherently memory.

Summaries of long conversations are useful retrieval aids, but compaction is a derived view. A summary should not gain stronger authority merely because it is shorter than the original.

Reusable memory might include a preferred report format, a stable company convention or an approved procedure. It needs an owner, scope, correction path and evidence appropriate to how it may be used.

A personal preference cannot quietly become a company rule. A web page cannot grant financial policy authority. An agent should propose a potentially useful memory rather than promoting every recurring phrase automatically.

For a given operation, the runtime can retrieve relevant conversation history, current business state, permitted company references and durable memory. The important thing is not to merge them into an undifferentiated block.

Each source contributes evidence with different freshness, provenance and allowed uses. If two sources disagree, the conflict is information to resolve, not an invitation to pick whichever sounds most confident.

The user benefits from continuity when the system can remember appropriately and also recognize when something needs to be looked up again.

Consider three sentences: 'I prefer compact tables,' 'our payment policy requires two approvers,' and 'invoice 142 was unpaid last Monday.' All could appear in a conversation. They have different owners, freshness requirements and effects. A user's UI preference can inform presentation; a company policy should come from an authorized policy source; an invoice status should come from current authoritative business data.

When the system creates a context projection, it should not flatten these into equally trustworthy bullet points. Source, date, confidence, sensitivity and permitted use ought to travel with the information. A repeated claim cannot become company policy merely by surviving several summaries.

This matters especially when a worker reads external web pages or attached documents in the same operation as memory. External content may be evidence, but instructions inside it must not acquire authority over tool use or business actions.

Long sessions need summarization or selective retrieval. Compaction is useful for preserving decisions, open questions and references without replaying every word. But every summary is lossy: it can omit the caveat that made a conclusion safe or turn a tentative hypothesis into a confident assertion.

A good system therefore maintains the difference between durable task facts and generated summaries. If a summary says 'payment confirmed,' a later financial action should still retrieve the relevant receipt or current record. The shorter sentence is a navigation hint, not a substitute for the evidence behind it.

The same principle applies to source-aware memory: useful knowledge should carry an identifiable scope, an owner, a correction path and a lifecycle. Otherwise a temporary decision can haunt tasks long after the underlying context changed.

The goal is not infinite retention. A workspace can feel continuous when it resolves references reliably, knows where durable work lives and can fetch the right evidence at the right time. It does not need to send the entire transcript into every agent, and it certainly should not grant all tasks access to every remembered detail.

This creates trade-offs. Retrieval can fail, memory promotion needs governance, and multiple authorized sources can disagree. Those failures should be observable, not hidden by broad claims that an assistant 'remembers everything.'

Artemis treats conversation, operational state, knowledge and memory as different resources, with dynamically assembled context in its vNext direction. See https://github.com/sarooo17/artemis-architecture/blob/main/docs/06-CONTEXT-AND-TRUST.md.