AI Agent Memory: Keep Business Records Separate From Model Inferences

Three different stores

Keep transactional truth in an authoritative database with permissions and audit history. Keep source knowledge in a document or retrieval index where every passage links back to an owner and version. Keep inferred preferences or summarized conversations in a separate memory service with confidence, timestamps, purpose and a correction mechanism.

Retrieval should rank relevant context but must not silently promote model-generated text into an authoritative record. If an assistant proposes a change to a payment status, enrollment record or permission, that change belongs in the source system's validated workflow, not a memory write.

Time and conflicting evidence

Facts change. A customer may prefer email this month and telephone next month. A product may move from prototype to released. Preserve effective dates and source timestamps, then label older statements as superseded rather than presenting both as current.

A memory response should be explainable: which source supplied it, whether it came from a user, observation or model inference, and what access checks were applied. When evidence is incomplete, the system should say so.

Worked example: a user preference collides with a business record

Imagine a learning platform stores an authoritative enrollment record in PostgreSQL. A conversation summary says that the learner prefers to study on weekends. The enrollment record determines course access; the preference helps propose a study schedule. The preference must never silently change payment status, enrollments, marks, permissions, or other authoritative states. This is an illustrative design example, not a claim about an existing NexisHub customer.

A safe retrieval result includes the memory text, source type (user statement or model inference), capture time, scope, optional confidence, and a link to the authoritative record when one exists. If the learner later says that Saturday classes no longer work, the update should supersede the old preference while preserving the original record's audit history where justified.

An acceptance test asks the same question twice across two unrelated user accounts. The second account must receive no fragments, embeddings-derived summaries, or source links from the first account. This test should also cover caches, background jobs, exported reports, and vector search filters, not only the primary database query.

A minimal permission-aware memory contract

Define a memory envelope with subject ID, tenant ID, purpose, source reference, created and last-confirmed timestamps, expiration policy, data category, and whether the item is verified or inferred. Before retrieval, bind the request to the authenticated tenant. Before presentation, check that the user is permitted to see both the memory and its underlying source.

Use a write gate for high-consequence operations. A memory can suggest that a student is ready for the next mathematics topic, but only an approved assessment or teacher decision should update a formal mastery record. Similarly, a support summary can recommend an invoice follow-up but cannot mark an invoice paid. These controls reduce the chance that fluent text becomes an unearned source of truth.

Measure accuracy with contradiction tests, forgotten-data retrieval tests, and source-attribution coverage. A useful target is not simply more remembered facts: it is fewer repeated questions without an increase in stale, unauthorized, or fabricated context.

Apply the idea to a real page

Begin with one page that matters to the organisation and inspect it as a complete information object. Identify its subject, audience, purpose, important claim, supporting evidence, and next action. Then compare those decisions with the page title, main heading, navigation label, summary, links, and structured data. When those layers disagree, repair the underlying meaning before adding more content.

For this guide, the first practical pass should examine respect sources of truth, isolate tenants and users, make forgetting practical, track time and provenance. Do not treat the list as a scorecard that produces an authoritative number. Use it to ask which conditions exist, which are uncertain, and which change would make the page more useful to a person as well as a retrieval system.

Build an evidence record

A useful implementation record names the page or entity, the observation date, the source of the observation, the change made, the expected mechanism, and the limitation that still applies. Technical evidence may include status codes, rendered output, links, metadata, or accessibility results. Editorial evidence may include a source, author, publication date, review decision, or correction record. Keep these classes visible instead of merging them into a single confidence label.

The record should also explain what has not been measured. If an article has not been observed in an external answer system, say so. If a recommendation is based on documentation rather than a controlled experiment, say so. Clear limits make a publication more credible because readers can distinguish established practice from a proposal that still needs testing.

Diagnose failure before prescribing volume

When a page performs poorly in a discovery workflow, classify the failure before recommending more articles. Access problems include blocked routes, unstable responses, rendering gaps, incorrect canonicals, and weak navigation. Interpretation problems include ambiguous names, vague headings, missing definitions, and conflicting descriptions. Evidence problems include unsupported claims, unclear authorship, stale sources, and missing limitations. Each category has a different remedy.

A diagnosis should be reproducible by another person. Include the page, question, date, observed result, expected result, and the smallest reasonable next step. This prevents a common editorial failure in which a team publishes volume to compensate for a technical or conceptual problem that the extra pages cannot solve.

Make ownership explicit

Assign responsibility across the complete lifecycle. Engineering may own rendering, response behaviour, canonical URLs, feeds, and deployment. Content or research may own definitions, sources, examples, and revisions. Product or subject experts may verify capabilities and boundaries. Analytics may preserve samples and distinguish observed outcomes from estimates. A page is more maintainable when these responsibilities are visible.

Ownership does not mean every page needs a large process. A small team can use a lightweight review record with an owner, a review date, the evidence checked, and the decision taken. The important point is that no one has to guess who should correct a misleading claim, replace a broken source, or investigate a change in discovery behaviour.

Measure useful change

Choose a measure that matches the intervention. If the change repairs a canonical, inspect canonical consistency and crawl paths. If it clarifies a definition, review extraction and representation across a fixed question set. If it adds evidence, check whether readers can reach and evaluate the source. If it improves accessibility, test the actual interaction rather than inferring success from the presence of markup.

Do not claim a business result from a technical change without a suitable observation window and comparison. Discovery surfaces are variable, and several changes often happen together. Preserve the baseline and describe alternative explanations. A measured improvement can be valuable without being presented as proof that one edit caused every downstream outcome.

Maintain the page after publication

Publication is the start of a maintenance period, not the end of the work. Review product descriptions when the product changes. Recheck current statistics and specifications on an appropriate interval. Watch for broken links, redirects, withdrawn sources, outdated examples, and new terminology that could confuse the page's identity. Historical sources may remain appropriate; age alone is not a reason to remove them.

Keep a version history for material changes. State what changed, why it changed, which sections are affected, and whether the conclusion changed. If a serious error is found, use a correction or retraction process rather than quietly rewriting the old claim. This preserves reader trust and creates a useful record for future research.

What would change the conclusion?

A strong technical article states the evidence that would support revision. For this subject, that might be a controlled comparison, a larger observation sample, a change in platform documentation, a reproducible failure across several sites, or a source that contradicts the current interpretation. Naming that evidence keeps the article open to improvement rather than turning a practical framework into doctrine.

Readers should leave knowing what they can apply now and what still requires validation. The durable recommendation is to improve access, meaning, evidence, and accountability. The uncertain recommendation should remain labelled as uncertain. That distinction is central to responsible content for both humans and machines.