Contextual Agentic Memory: What an Enterprise Agent Should Remember, Retrieve and Recheck

For: enterprise architects, AI engineers, security leaders, product owners and executives. The decision: what an agent may remember, what it must retrieve afresh, and what the service that owns the record must recheck before anything is committed.

‘Contextual Agentic Memory’ is a working label proposed here for memory handled in this way. It is not an established term or standard, and it is not a claim of invention: the pieces draw on published research, vendor documentation and security guidance, cited below.

A recalled refund is evidence, not permission

Illustrative scenario: a fictional composite written to make the point concrete. It does not describe a real organisation, and its figures are not reported outcomes.

A fictional online homewares retailer lets an assistant draft refunds for its service team. A customer reports that a lamp from order 7731 arrived cracked and asks for $140 back. The assistant searches its memory and finds a close precedent: case 2041, eight weeks ago, a $140 refund for a damaged lamp on order 7502, approved by a team leader. It also finds the returns policy as it stood then, and the refund runbook. It drafts a $140 refund and cites the precedent.

Everything it recalled was accurate when written. Four things have changed since.

The assistant was right to remember and would be wrong to act on the memory. The refund service owns the order, the policy and the authority checks. When the proposal arrives, it reads current conditions, finds three conflicts and declines to commit. It sends the exact proposal, the conflicts and the precedent to a named refund owner. The rest of this article describes the design that makes that outcome routine.

A larger prompt or a vector store does not settle what is current

Anthropic’s applied AI team describes context as a finite resource, calls the loss of recall as a window fills ‘context rot’, and recommends small, high-signal context. For long tasks it describes agents that write notes to memory outside the window and read them back later (Rajasekaran and colleagues, 2025). Memory outside the window is a design need, not an extra.

It also raises questions. When the memory is read back, is it still true, may this principal see it, and may it influence this action? A bigger window answers none of them. Nor does a vector index, which answers a narrower question: which stored text is most similar to this query. One vendor documents that its index is eventually consistent, so a changed record can take time to become visible to queries (Pinecone documentation). Products differ, so check the one you use. Similarity is still not currency, ownership or permission.

Two published notes make related points: The Model Is an Engine, Not the Database on keeping memory and permission state in stores you control, and Context Is Not a Prompt on correct material given for the wrong purpose.

Four kinds of memory, and a warning that the labels vary

Researchers and vendors borrow memory types from cognitive science. The CoALA paper describes working memory for the current decision cycle and three long-term memories: episodic, semantic and procedural (Sumers and colleagues, 2023). LangChain’s documentation uses the same three long-term kinds and calls per-conversation context ‘short-term memory’, defining semantic memory as facts and concepts, episodic memory as past events or actions, and procedural memory as rules for performing tasks. Park and colleagues (2023) store a complete record of an agent’s experiences, retrieve from it dynamically and synthesise reflections over time. The published Contextual Agentic Graph article groups agent memory differently again, as long-term knowledge, short-term task state and decision traces. The labels are useful. They are not a standard.

Usage varies. In CoALA, procedural memory is largely implicit knowledge in the model’s weights plus explicit knowledge in the agent’s code, and episodic and semantic memory may be absent in some agents. Many product teams use ‘procedural’ for stored instructions that can be retrieved and edited, as this article does for clarity. Nothing below depends on the names you choose. What matters is that each kind of content has an owner, a lifecycle and a limit on what it may do.

Memory, state, instructions and permission are four different things

Taxonomies say where information sits, not what it may do. The refund example needs a second split.

This split is a CAE interpretation. The Contextual Agentic Enterprise (CAE) is an architecture and operating model proposed by Contextual Agentic, and it is not an industry standard. Its working rule here is that memory may inform a proposal, while the owning system and current authority decide the effect. ‘Contextual agentic memory’ is a working label for memory handled that way, not an established term.

The Contextual Agentic Graph article describes one store design: a governed graph of claims. This article is store-neutral. Its lifecycle and controls apply whether memory sits in a graph, a relational table, a document store, a file directory or a vector index.

Memory has a lifecycle with eight steps

Each step needs a named owner and a control. The sequence is a CAE interpretation.

1. Capture. Record an event or knowledge item only for a stated purpose. Keep raw evidence apart from model-written summaries, and link each summary to its source.
2. Classify. Attach sensitivity, tenant, subject, source and owner at capture, and decide retention and correction rules before personal or confidential content enters a store.
3. Store. Keep past events, knowledge and approved procedures in separate sources with separate owners and write paths. The technology is a design choice. Anthropic’s memory tool shows one option: files under a directory, with the application running the file operations and owning validation, size limits and expiry.
4. Retrieve. Filter by tenant, principal and purpose before search and inside the store, not by asking the model to behave. OWASP lists permission-aware access control and strict dataset partitioning among its mitigations for vector and embedding weaknesses. Database row-level security is one example of enforcing this inside the store. PostgreSQL’s documentation says superusers and roles with the BYPASSRLS attribute always bypass it, that table owners normally do too, and that referential-integrity checks can leak information through covert channels, so it is one mechanism and not a cross-tenant guarantee.
5. Assemble. Build the working context for one task: bounded, labelled by kind, with evidence marked as evidence, instructions kept apart, and a note of what was left out.
6. Check. Before the agent proposes, compare timestamps and versions and surface conflicts instead of silently choosing one. Before the service commits, it rechecks current state and authority itself.
7. Correct. A named steward supersedes wrong memory, keeps the old version with the reason, and propagates the correction to summaries, embeddings and caches. A rejected claim stays visible as rejected.
8. Retire or delete. Expire memory that is unused, unverified or past retention, and delete on a valid request, including derived data and, where the rules require, backups and logs. Duties vary by jurisdiction and need legal review. Do not promise that deletion reaches every copy until you have verified it.

Each record needs eight controls

Metadata is a claim until something enforces it. The write path should refuse an item that lacks the fields below, and retrieval should refuse to return one.

OWASP’s agentic list names memory and context poisoning (ASI06) and suggests mitigations that map onto this table: validate content before writing it, segment memory by user session and domain, require provenance and detect suspicious updates, expire unverified memory, weight retrieval by trust and tenancy, and stop an agent automatically re-ingesting its own outputs. They are risk themes, not a claim of sufficiency.

Five risks, and where each is stopped

Stale approvals. The refund case: a real approval, for a different case and an older policy, treated as current. Bind each approval to one exact payload, version and time, and have the service check authority itself. How long an approval should live is the authority owner’s decision.

Cross-tenant leakage. OWASP warns of context leakage between users or queries when tenants share a vector database, and lists permission-aware access control and strict partitioning as mitigations. Enforce tenant and purpose inside the store before retrieval, and test with seeded records. Whether a shared index with filters is acceptable, or each tenant needs its own store, is a deliberate decision that depends on the data.

Sensitive data retention. OWASP’s guidance on sensitive information disclosure includes least privilege, sanitisation, and clear retention and deletion policies. NIST’s generative AI profile treats data privacy as a risk area, suggests a retention policy for testing and evaluation records, and lists data retention requirements among the factors for decommissioning a system. Anthropic’s memory tool documentation advises validating and stripping sensitive data before a write, not relying on the model’s judgement. Legal duties, and the reach of deletion into derived copies, stay open.

Prompt injection. OWASP describes indirect prompt injection as input from external sources, such as files or websites, changing a model’s behaviour. It says it is unclear whether fool-proof prevention exists, and lists least privilege, human approval for high-risk actions, labelling untrusted content and adversarial testing as ways to reduce impact. Any retrieved text, including a stored customer message, is untrusted data. The service’s independent checks limit the damage: an injected instruction might propose a refund, but should not make the service commit one that current policy and authority forbid. That limits blast radius. It does not prevent injection.

Memory poisoning. OWASP describes attackers seeding or altering stored context, such as memory tools, summaries, embeddings and RAG stores, to skew later reasoning and tool use. Its separate data and model poisoning item covers training, fine-tuning and embedding data. Restrict write paths, require provenance, review high-impact changes and keep snapshots for rollback. Detection stays open: nothing cited here shows that a technique reliably catches a plausible but wrong record.

The service rechecks before it commits, and reconciles when the answer is unknown

The proposal now reaches what CAE calls the Commit Boundary: the point where a proposal would become an externally observable effect, here money leaving the business. There the owning service, not the agent, runs the checks against current conditions.

1. The exact request. Is this the refund that was proposed: order, amount, reason and request key?
2. Current order state. Is the order paid and delivered, not already refunded, and within the refundable balance?
3. Current policy. Which version applies today, and is the order inside its window?
4. Current customer record. Is there an open dispute, hold or merge that changes what may be paid?
5. Current authority. Which delegation applies to this requester, with what limit, and was an approval above it given for this exact payload?
6. A recorded result. Permit, escalate or deny, with the versions and reasons written down.

For order 7731, checks 3, 4 and 5 fail. The service escalates and records why. The case 2041 approval appears on the reviewer’s screen as context, not as a reason to commit.

Illustrative scenario continued: still fictional. Later that day the agent proposes a $60 refund on order 7740, delivered 12 days ago, no dispute, inside its $100 limit. The service commits it, but the reply is lost and the call times out. Do not assume the refund did not happen, do not create a new request, and ask what happened before doing anything else.

• The action carries a request key, generated once per intended refund and stored with the proposal before the first send.
• On timeout the outcome is recorded as unknown. The agent neither retries nor reports a failure.
• The gateway reads the refund’s status from the service using that key. The refund service has to offer a status lookup for this to work.
• If the refund succeeded, record it and stop. If no such request exists, recheck current conditions, because policy or authority can change during a delay, then send the same request again with the same key.
• If the status is pending or unavailable, hold the case and alert the refund owner. Do not issue a new key.

Provider behaviour differs. Stripe documents that, in its v1 API, it saves the status code and body of the first request made with a key and returns them on retries, including server errors. It compares incoming parameters with the original and errors if they differ, and may remove keys once they are at least 24 hours old. A saved server error is returned again on a retry, so a failed first attempt cannot always be re-run under the same key. Its v2 API works differently: retries do not repeat successful operations, and Stripe retries failed or partly failed work to completion where it can. The IETF is drafting an Idempotency-Key header field (draft-ietf-httpapi-idempotency-key-header-08, 22 October 2026), a work in progress and not a standard. Neither establishes how your own refund service behaves. It must implement, document and test its own rules, including what a key means after expiry. None of this guarantees exactly-once execution. Evidence-First Decision Records covers keeping what is needed to reconstruct the decision later.

Text description of Figure 1. The picture shows six bands from top to bottom: people, memory, controls, context, action, and current state and authority. Evidence flows down from memory through the controls into a working context made of labelled evidence and approved instructions. A proposal crosses the commit boundary only after the owning service checks the current order, policy and delegated authority, which live outside memory. The reviewed outcome flows back to memory as evidence, not as permission. On a phone the same content appears as a single narrow column with the commit boundary as a dashed line between the proposal and the system of record.

Evaluate the whole task, not only retrieval

Retrieval scores can look healthy while the system acts on a stale approval. Measure the chain from question to business outcome. This table says how each measure could be taken. It gives no benchmark figures, because any figure would depend on your data, tasks and definitions.

Set thresholds with the service owner and hold out cases for independent review. Evaluation Is Not a Test Phase covers building these gates early, and What an A/B Test Cannot Tell You About an Agent covers the limits of one comparison method.

People review exceptions and correct memory

When the service escalates, a reviewer needs more than a refusal: the proposed action, the recalled evidence with its source and age, the current state the service read, and the specific conflicts. The reviewer can approve within their own authority, deny, or send the case back with a reason.

Correction is a separate act. If the memory was wrong or out of date, the reviewer or a memory steward files a correction against the item itself, not a chat message to the agent. The item is superseded with a reason, derived copies are updated, and the decision and correction are recorded together.

Service owners keep the rules of the system of record. They should sample escalations and reversals on a schedule, and treat a pattern, such as a policy change that never reached the retrieval index, as a fix to the source or pipeline. Every reviewed exception is a candidate for the evaluation set. NIST’s generative AI profile gives weight to after-action review and incident reporting, and the same habit applies.

A short checklist for executives

• Who is the named business owner of each memory source, and who owns the system of record the agent acts on?
• Which decisions may an agent commit alone, which need a person, and who issues each delegation?
• Can we show how long a customer’s data stays in memory, and how a correction or deletion reaches summaries and indexes?
• What happens when a remembered approval is out of date, or a response times out?
• Which measures, against which baseline, show that the work improved, and who reviews failures?

An implementation checklist for engineering teams

Application requires organisation-specific architecture, security, privacy, legal, regulatory, operational, safety, accessibility, commercial and governance review, together with appropriate approvals.

1. Separate remembered evidence, business state, instructions and permission, each with an owner and a write path.
2. Stamp source, writer, valid-from, valid-until, recorded-at, version, tenant, sensitivity, purpose and retention at write time, and reject writes that lack them.
3. Keep raw evidence and model-written summaries apart, and link each summary to its sources.
4. Enforce tenant, principal and purpose in the retrieval service, before search, and test with seeded cross-tenant records.
5. Label every context item by kind, keep instructions out of retrieved evidence, and treat retrieved text as untrusted data.
6. Version context assembly and tool configuration, and log what was selected and what was dropped.
7. Treat writes to shared or high-impact memory as candidates for review, and log the writer.
8. At the service, recheck the exact payload, current state, policy version, customer flags and delegated authority. Ignore any claim about permission that comes from memory.
9. Generate a request key per intended action before the first send, store it with the proposal, compare parameters on replay, and define what the key means after expiry.
10. On a timeout, record the outcome as unknown, read status by key, and retry or escalate only by documented rules.
11. Build correction and deletion paths that reach derived stores, set a service level for propagation and test it.
12. Test a stale approval, a changed policy, an instruction injected into a stored event, a poisoned summary, a cross-tenant probe and a lost response, on every change to retrieval or assembly.
13. Instrument the seven measures above and agree thresholds with the service owner.

What is sourced, what is interpretation, what is open

Sourced. Context is finite and notes outside the window are a recognised technique. The four labels appear in the literature and vendor documentation with different definitions. OWASP lists the five risks above. One vendor documents eventual consistency, one provider documents its idempotency behaviour, one database documents its row-security limits, and the IETF header is a draft.

CAE interpretation. The four-way split, the lifecycle, the controls, the recheck at the Commit Boundary and both checklists are proposals for discussion, not tested practice.

Open. No validated benchmark exists for this design and none is claimed. Whether one taxonomy will emerge, how well poisoning can be detected, jurisdiction-specific retention duties and provider-specific reconciliation behaviour are unresolved. The design has not been deployed or tested in production.

Key takeaways

• Memory outside the prompt is necessary and is not authority. Remembered evidence can inform a proposal, and the owning system and current authority decide the effect.
• Keep four things apart: remembered evidence, authoritative business state, instructions and permission to act.
• Treat memory as a lifecycle with an owner and a control from capture to deletion, including correction of derived copies.
• The service that owns the record rechecks exact payload, current state and delegated authority at the Commit Boundary, and reconciles an unknown outcome by reading status before any retry.
• Measure the whole chain, from retrieval relevance to business outcome, and publish no benchmark you have not run.

Sources and further reading

• The Contextual Agentic Enterprise, Chapters 4, 5 and 21 (chapter titles as listed on the book page).
• A LinkedIn discussion on agent memory, shared by short link. It prompted the topic. The page could not be opened for this article, so nothing is taken from it. Author credit to be added before publication.
• Sumers, T. R., Yao, S., Narasimhan, K. and Griffiths, T. L. (2023, revised 2024) “Cognitive Architectures for Language Agents”, arXiv:2309.02427.
• Park, J. S. et al. (2023) “Generative Agents: Interactive Simulacra of Human Behavior”, arXiv:2304.03442 (v2, August 2023; venue not confirmed here).
• Rajasekaran, P. et al. (2025) “Effective context engineering for AI agents”, Anthropic Engineering, 29 September 2025.
• Anthropic, “Memory tool”, Claude API documentation.
• LangChain, “Memory overview”. One vendor’s usage, not a standard.
• OWASP GenAI Security Project, LLM01:2025 Prompt Injection, LLM02:2025 Sensitive Information Disclosure, LLM04:2025 Data and Model Poisoning and LLM08:2025 Vector and Embedding Weaknesses.
• OWASP GenAI Security Project (2025) “OWASP Top 10 for Agentic Applications for 2026”, 9 December 2025, item ASI06. The item text is in the PDF linked from the resource page.
• NIST (2024) “Generative Artificial Intelligence Profile, NIST AI 600-1”, July 2024. A companion to a framework intended for voluntary use.
• PostgreSQL Global Development Group, “Row Security Policies”, PostgreSQL 18 documentation. One database mechanism, cited as an example.
• Pinecone, “Check data freshness”. One vendor’s documented behaviour.
• Stripe, “Idempotent requests”, API reference, covering v1 and v2 behaviour. One provider’s documented behaviour, not an endorsement.
• Jena, J., Dalal, S. and Tishkin, D., “The Idempotency-Key HTTP Header Field”, Internet-Draft, version 08, 22 October 2026. A work in progress.

The book develops memory and context at length

The book treats this ground in its chapters on enterprise knowledge and organisational memory, on context engineering and in-context adaptation, and on memory, continual learning and adaptive enterprise intelligence. More about the book.

This article is part of CAE Field Notes, a series accompanying the book, The Contextual Agentic Enterprise.