What an agent may remember, and who gets to decide

Memory is usually presented as a convenience: the agent remembers your preferences, your project names and the way your team formats reports, so you stop repeating yourself. All true. But a remembered sentence is also a standing input. It will shape future work for people who never saw it being written, long after the conversation that produced it is gone. That makes memory a governance question, not just a feature.

What goes wrong when agents remember on their own

• A passing remark becomes policy. Someone says "skip the appendix this time" and the agent drops appendices from every report that follows.
• A stale fact looks current. A contact, a price or a system owner was right in spring and is wrong now, but the memory carries no date and no expiry.
• Personal becomes shared. A note one person made for themselves turns up in a colleague's work.
• Someone else's text gets remembered. A pasted document or a web page contained an instruction, and the agent stored it as if the team had said it.
• Sensitive details linger. A client detail mentioned once is kept indefinitely, with no classification attached.
• Corrections erase history. A fact is fixed by overwriting it, and nobody can tell what the agent believed when it made last month's recommendation.

Proposed is not approved

The central rule is that an agent may suggest a memory, but nothing becomes a memory until a person accepts it. A proposal should carry enough context to be judged in seconds:

proposed memory
  statement:      Quarterly reports follow a fiscal year that starts in April.
  reason:         stated by the finance lead while reviewing the Q2 draft
  source:         review comment on the Q2 report work order
  scope:          project: finance reporting
  classification: internal
  retention:      until the reporting policy changes
  expires:        review in 12 months

A reviewer can see why the agent thinks this is worth keeping, where it came from, who will see it and when it will be looked at again. If any of those is missing, the proposal is not ready, and rejecting it is a perfectly good outcome.

Choose the narrowest scope that works

Most memory problems are really scope problems. The same sentence can be harmless for one person and wrong for the whole company.

Start at session level and promote a memory only when there is a reason. A line that helped once in one chat should not drift into company knowledge just because it was useful that day.

Retention, expiry and freshness

Every memory should answer two questions: how long may it be kept, and when must someone check it again? Preferences can last a while. Facts about the outside world, such as prices, owners and contact details, age quickly and should either expire or come up for review.

It also helps to be clear about what memory is not. It is not a live feed. If the work depends on a current figure, the agent should refresh it from the source, and the memory should at most point to where that source lives. Citations that hold up covers how to keep that pointer honest.

Corrections create a new version

When a memory is wrong, the fix should be a new version that supersedes the old one, not an edit that erases it. That keeps two things possible at once: the agent uses the corrected fact from now on, and anyone reviewing past work can still see what the agent believed at the time. Paired with an audit trail, versioned memory lets you explain a past decision instead of guessing at it.

How GoCux handles memory

In GoCux, Memory Graph keeps proposed memories apart from approved ones. A memory can be scoped to a session, a user, a project or the whole company, and the guidance is to pick the narrowest that fits. Each proposal carries its reason, a reference to where it came from, a data classification, a retention rule and an expiry. A correction is stored as a new version, and something said in a chat does not turn into company knowledge by itself. Memory stays inside the company boundary along with the rest of the work. The memory documentation covers the details.

What to write down before you turn memory on

• Who may approve memories at each scope, and who may promote one to company level.
• What a proposal must include before it can be reviewed: reason, source, scope, classification, retention, expiry.
• Which kinds of information are never stored, whoever proposes them.
• A default expiry for facts about the outside world, and who reviews memories when they expire.
• How corrections are made, and confirmation that each one creates a new version.
• That instructions found in documents, emails or web pages are never stored as team decisions.
• How to list everything the agent currently remembers at a given scope.

For approvals in general, see who may approve agent work; for how GoCux combines memory, approval and audit, see the governance page.