An AI agent becomes harder to trust when every useful detail is treated as memory. A customer preference, a temporary project rule, a conversation transcript, and a reusable procedure do not have the same lifetime or owner. Putting them in one growing file makes it difficult to know what is still true, who approved it, and when it should be removed.
A safer design starts by separating the kinds of information an agent may use. The labels can vary by system, but the boundaries should be clear.
Four different things that get called memory
Durable facts
Durable facts are information expected to remain useful across tasks. Examples include a team’s approved service name, a system’s documented owner, or a stable preference that someone has chosen to retain. A fact still needs a source, an owner, a scope, and a review date. “Permanent” should never mean “never check again.”
Project context
Project context contains rules for a defined piece of work. It might say which repository is in scope, which routes must not change, or which acceptance checks are required for a release. That context should not silently become a rule for every other project. Give it a project identifier and an end condition.
Session history
Session history records what happened in a conversation or run. It can help an agent continue work, but it is not automatically a reliable fact. A session may contain an outdated instruction, a rejected idea, a temporary assumption, or sensitive information that should not be retained. Treat history as evidence to review, not as policy to reuse.
Reusable procedures
Procedures describe how to perform a repeatable task. They need a maintainer, a version, and a test or example that shows the procedure still works. A procedure is different from a fact because it can change when the tools, permissions, or site structure change.
This separation is an architectural idea, not a universal product standard. The useful question is what each item is allowed to influence, how long it should live, and who can correct it.
Give every item a lifecycle
Before storing a piece of information, record at least:
- Source: Where did the item come from? Record a document, decision, ticket, or conversation reference rather than relying on an unexplained statement.
- Owner: Who can confirm, update, or delete it?
- Scope: Which agent, project, customer, environment, or route may use it?
- Review date: When must someone check it again?
- Deletion rule: What event removes it, and can the owner prove that removal happened?
These fields make a memory review possible. They also expose entries that should never have been stored. Passwords, API keys, private tokens, and unrestricted copies of personal or customer records do not become safe because they have a label. Keep secrets in an approved credential system and give the agent the narrowest supported access it needs. Define retention with the responsible owner and applicable obligations. There is no universal retention period that fits every business record.
A handover that catches stale guidance
Consider a hypothetical handover for a website improvement project. The project record says the agent may inspect the staging site, edit one article template, and verify the page at two viewports. A session note from last month says the same template is already approved for production. A newer decision says production changes require a fresh backup and a separate launch check.
A poorly separated memory store may retrieve all three statements and act on the oldest convenient instruction. A better system applies scope and recency before action:
- Use the project rule because it is scoped to the current work.
- Reject the older production instruction because a newer decision changes the approval boundary.
- Keep the session note as history, but do not treat it as an active rule.
- Ask the current owner to resolve any conflict that remains material.
The same test works with synthetic records. Create two projects with similar names, add one valid fact to each, add an expired instruction to one project, and add a deliberately conflicting session note. The expected result is that the agent uses only the current, in-scope fact and routes the conflict for review. Do this before trusting a memory feature with real customer or operational data.
Review less information, more often
A memory review does not need to inspect every past conversation. Start with the items that can change an external outcome:
- Can this item send, publish, delete, purchase, approve, or change a record?
- Can another project or customer retrieve it?
- Is the source still available and consistent with the stored value?
- Has the owner or scope changed?
- Has the review date passed?
- Does the item contain a secret or unnecessary personal information?
- Can the system show what was used and why?
When the answer is unclear, the safer default is to leave the item unused until someone reviews it. Keeping less information can be the safer design. A smaller store with clear ownership is easier to correct than a large store that quietly accumulates exceptions.
Make deletion part of the design
Deletion should be a normal operation, not an emergency cleanup project. Define what ends a project, what expires a temporary rule, and what happens when a person asks for a record to be removed. Check the primary store, search indexes, caches, exports, and derived summaries that may retain copies. Keep an audit record of the deletion event without retaining the sensitive content that was removed.
Testing should cover both rejection and isolation. A stale item should fail its review check. A project-scoped item should not appear in an unrelated project. A deleted item should not return through a cached or generated copy. These are concrete acceptance checks, not assumptions about what a product’s memory label means.
Start with a small memory contract
For a first implementation, write a short contract that names the stores, their permitted contents, owners, review cadence, access boundary, and deletion path. Add a few synthetic facts and conflicting examples. Run the contract during ordinary agent tasks, then inspect the decisions it produces.
We can help decide which operational knowledge belongs in an agent, who owns it, and how it stays current. See AI and Automation for the related service area.
Source lead: an archived post about separating facts, project context, sessions, and procedures. It is an architectural prompt, not a universal product standard.