Why AI Agents Forget and How to Fix Their Memory

TL;DR:

• AI agents appear to forget when information never gets stored, can't be retrieved, drops out of context, or becomes stale.
• To find the cause, trace one concrete fact through the write path, retrieval step, and final prompt sent to the model.
• Durable memory combines short-term state, long-term storage, selective retrieval, and a way to update or remove old information. cognee supports that lifecycle through remember(), recall(), improve(), and forget().

An AI coding agent spends an afternoon finding the cause of an authentication bug, testing several fixes, and updating the right files. Bug solved — excellent. But two days later, starting a new session voids the whole process and sends the agent back to the beginning.

The same failure appears when a support agent repeats a question the customer answered in an earlier session or an operations agent loses track of a task after several tool calls.

A larger context window can postpone some of these problems, but it won't preserve state across sessions or guarantee that the right information returns when the agent needs it. Reliable continuity depends on the surrounding system: what it saves, how it scopes memory, what it retrieves, and what reaches the model.

This guide shows how to locate the failure and apply the simplest fix that solves it, from better thread state and context management to long-term memory for AI agents with cognee.

What Is the AI Agent Forgetfulness Problem?

The AI agent forgetfulness problem occurs when information the agent previously encountered can't be used when it becomes relevant again.

An agent can forget something even when nothing was ever deleted, with the fact still stored somewhere in a log file, a database row, or a closed conversation.

The failure usually occurs during capture, scoping, retrieval, context assembly, or later updates. Fixing the wrong link in that chain — for example, rewriting a prompt when the real issue is a broken retrieval query — just wastes effort without addressing the cause.

Let's pin a few terms down before we go on, since they tend to get thrown around interchangeably, and we'll be referring to them in the next sections:

For a broader overview of these layers, see our guide to AI agent memory.

Why Do AI Agents Forget?

Five situations account for most cases of agent forgetfulness — each is a specific point where the surrounding system either lost the information or failed to bring it back at the right moment.

State Doesn't Survive the Workflow

A base model doesn't carry application state across independent calls unless the surrounding system supplies it again. Things like conversation history, tool results, and unfinished tasks can vanish when a thread ends or work gets passed on to another agent.

Continuity depends on explicit checkpointing and clear rules for sharing state across those boundaries.

Context Window Limits and Compression

Every model call has a bounded context window. Once it fills up, the application has to remove, summarize, or selectively reload earlier information.

Even information that still fits within the context window may be used inconsistently when the prompt becomes long or noisy. Research on the "lost in the middle" effect found that models often handle information near the beginning or end of a long input more reliably than details buried between them.

Compaction can also remove useful context when a summary drops a rejected approach, file reference, or unresolved task.

The System Saves the Wrong Information

Weak write policies either miss valuable information or retain too much of it. Saving every message creates duplicates, temporary facts, and unverified claims that later compete with useful memory.

A better write policy favors future usefulness over completeness. Each memory should also carry the scope and source needed to use it safely later.

Retrieval Misses the Right Memory

Stored information only helps when the retrieval layer can find it. Common problems include:

• Searching the wrong dataset or user scope
• Queries that don't match the stored wording
• Similar but incorrect results ranking higher
• Missing links between related facts
• Old information outranking newer updates

These failures often look like storage problems from the outside, even though the required memory is available in the system.

Stored Knowledge Drifts Over Time

Without proper update and deletion rules, older memories remain available beside their replacements and may surface unpredictably.

Durable memory needs a way to correct, consolidate, supersede, and remove information as facts, preferences, and project decisions change.

How to Diagnose Where the Agent Is Forgetting

Before diagnosing the cause, it helps to recognize the symptom in the system. Forgetfulness rarely announces itself explicitly — it shows up subtly, but the way the agent starts to short-circuit usually points straight to the stage that should be looked at first.

Choose a repeated failure you're observing and trace one specific fact through the system before changing the model, prompt, or memory stack. Use something concrete, like a user preference, project decision, unfinished task, or verified bug fix.

Here's how to go about diagnosing the issue:

1. Define what the agent should remember

   Note down the exact information and when you expect it to return.

   Avoid vague tests such as "remember our conversation." Instead, go for something narrow like:

   The customer uses Okta and requires SCIM provisioning.

2. Check the intended scope

   Decide where the memory should remain available:

   • Current tool call
   • Active thread
   • Future sessions
   • One user or account
   • One project or dataset
   • Several authorized agents

   Many apparent memory failures come from reading or writing to the wrong scope.

3. Inspect the write

   Confirm that the information was stored successfully and attached to the right session, user, project, or dataset.

   Also check when the write occurs. If the process exits before saving the final outcome, the agent may retain the investigation but lose the conclusion.

4. Inspect retrieval and context assembly

   Log the retrieval query and returned memories. Confirm that the required fact appears in the results and reaches the final prompt sent to the model.

   The result usually identifies the failing stage:

   What you find	Where the failure occurred
   The memory wasn't stored	Write path
   The memory exists but wasn't returned	Retrieval
   The memory was returned but didn't reach the model	Context assembly

5. Test whether the model used it

   Even correct context can produce a poor answer. Check whether the expected memory appeared in the prompt and whether the agent applied it correctly.

   Here is a generic template for checking memory retrieval. Feel free to change it depending on which agent framework you are using:

   # Replace with your framework's memory-store inspection
   
   from dataclasses import dataclass
   from typing import Any
   
   @dataclass
   class MemoryDiagnostic:
       expected_memory: str
       write_scope: dict[str, str | None]
       retrieval_query: str
       retrieved_memories: list[Any]
       final_context: str
       response: str
       memory_was_written: bool
       memory_was_retrieved: bool
       memory_reached_context: bool
       memory_was_applied: bool
   
   async def diagnose_memory_path(
       *,
       expected_memory: str,
       session_id: str | None,
       user_id: str | None,
       project_id: str | None,
       dataset_name: str | None,
       retrieval_query: str,
   ) -> MemoryDiagnostic:
       """
       Trace one expected memory through storage, retrieval,
       context assembly, and response generation.
       """
   
       write_scope = {
           "session_id": session_id,
           "user_id": user_id,
           "project_id": project_id,
           "dataset_name": dataset_name,
       }
   
       # inspect the memory store or write log
       memory_was_written = await check_memory_write(
           expected_memory=expected_memory,
           scope=write_scope,
       )
   
       # run the same retrieval call used by the agent
       retrieved_memories = await retrieve_agent_memory(
           query=retrieval_query,
           session_id=session_id,
           dataset_name=dataset_name,
       )
   
       memory_was_retrieved = any(
           expected_memory in str(memory)
           for memory in retrieved_memories
       )
   
       # assemble the exact context that will be sent to the model
       final_context = build_agent_context(
           retrieved_memories=retrieved_memories,
       )
   
       memory_reached_context = expected_memory in final_context
   
       # invoke the model through the production agent runtime
       response = await run_agent(
           query=retrieval_query,
           context=final_context,
       )
   
       # replace this basic check with a task-specific evaluator
       memory_was_applied = evaluate_memory_use(
           expected_memory=expected_memory,
           response=response,
       )
   
       return MemoryDiagnostic(
           expected_memory=expected_memory,
           write_scope=write_scope,
           retrieval_query=retrieval_query,
           retrieved_memories=retrieved_memories,
           final_context=final_context,
           response=response,
           memory_was_written=memory_was_written,
           memory_was_retrieved=memory_was_retrieved,
           memory_reached_context=memory_reached_context,
           memory_was_applied=memory_was_applied,
       )
   

Then run the same test in a fresh session to see if you've just fixed the current thread or created actual cross-session memory.

How to Fix AI Agent Memory Loss

Use the smallest intervention that addresses the failure you found. Some problems only need cleaner working state, while others need persistent storage and retrieval.

Quick Fixes for Agent Context Loss

These changes reduce agent context loss during long or tool-heavy workflows:

• Checkpoint the active state. Save the current objective, completed steps, tool results, and pending work so interruptions don't reset the task.
• Break up long runs. Smaller tasks create clearer boundaries and keep irrelevant history from accumulating.
• Reinject critical constraints. Stable instructions, permissions, and task requirements should return whenever they apply.
• Compact deliberately. Preserve decisions, unresolved questions, failed approaches, and the next action when summarizing older context.
• Trim noisy outputs. Large logs and raw API responses can crowd out the information the agent needs to continue.

Build Durable Memory in Layers

A durable stack usually adds these layers in order: capture the useful signal from a session, store it somewhere that survives past the session, retrieve selectively rather than replaying everything, and update or remove it once it changes.

What Should an AI Agent Remember?

Durable memory should focus on information that's likely to improve future work.

Each stored memory should include enough context to be used safely later:

• Who or what it belongs to
• Where the information came from
• When it was recorded or last updated
• Whether it's confirmed, temporary, or superseded

Conciseness with clear provenance will usually be more useful than completeness with noise. When facts change, update or replace the old entry instead of leaving both versions active.

How cognee Helps Fix Agent Forgetfulness

Retrieval only works as well as what was written matches what gets searched for later — memory that's verified, scoped, and connected to its source is what makes retrieval actually reliable, rather than a rerun of the "close enough" guesswork that caused the forgetting in the first place.

Semantic search alone gets partway there. It finds passages similar to a query, but it doesn't know that two mentions of the same customer, bug, or decision refer to one underlying thing, or that a newer fact should replace an older one.

When the answer depends on how people, files, events, and decisions actually connect, an AI knowledge graph can complement vector search by representing those connections explicitly.

cognee combines both, and the four core operations of our engine cover much of the memory lifecycle described above:

Session memory stores immediate task context, while permanent graph memory preserves knowledge that should remain useful across future runs. With multi-user access control enabled, datasets and permissions keep retrieval scoped to the appropriate project, account, or knowledge base.

from typing import Optional
from uuid import UUID

import cognee

async def run_memory_lifecycle(
    *,
    session_update: str,
    validated_outcome: str,
    current_question: str,
    session_id: str,
    project_dataset: str,
    outdated_data_id: Optional[UUID] = None,
):
    # Keep temporary investigation context in session memory.
    # self_improvement=False prevents this write from automatically
    # being bridged into the permanent graph before the outcome
    # has been validated.
    await cognee.remember(
        session_update,
        session_id=session_id,
        self_improvement=False,
    )

    # Store a verified outcome in durable, dataset-scoped memory.
    await cognee.remember(
        validated_outcome,
        dataset_name=project_dataset,
    )

    # Session-first recall. With session_id and no datasets or
    # query_type, recall() matches session cache entries directly
    # and only falls through to the permanent graph when nothing
    # matches. Each result carries a "_source" key ("session" or
    # "graph") identifying where it came from.
    session_context = await cognee.recall(
        current_question,
        session_id=session_id,
    )

    # Dataset-scoped graph recall. This is a separate retrieval path
    # from session-first recall: it searches the permanent knowledge
    # graph within the named datasets.
    graph_context = await cognee.recall(
        current_question,
        datasets=[project_dataset],
    )

    # Enrich the project graph. When session_ids is provided,
    # improve() also applies session feedback weights to the graph,
    # persists the sessions' Q&A into permanent memory, and distills
    # session learnings before running default enrichment.
    await cognee.improve(
        project_dataset,
        session_ids=[session_id],
    )

    # Remove or supersede outdated information. Deleting a single
    # item requires its data_id together with the dataset it lives in.
    if outdated_data_id is not None:
        await cognee.forget(
            data_id=outdated_data_id,
            dataset=project_dataset,
        )

    # Other forget() scopes:
    #   await cognee.forget(dataset=project_dataset)  # entire dataset
    #   await cognee.forget(dataset=project_dataset, memory_only=True)
    #       # graph + vector memory only; raw files are kept so the
    #       # dataset can be re-processed with different settings
    #   await cognee.forget(everything=True)  # all data the user owns

    return {
        "session_context": session_context,
        "graph_context": graph_context,
    }

With cognee, the agent can carry recent context through the current workflow and retrieve connected knowledge from earlier work. Decisions can remain linked to their sources, affected files, previous outcomes, and later corrections instead of surviving only as isolated conversation fragments.

Implementation #1: A Coding Agent That Remembers Decisions

Coding agents should retain verified decisions, causes, affected files, and unresolved work that may shape a later task.

Here's what a sensible workflow looks like:

1. Keep the active investigation in session state.
2. Save the outcome only after the fix has been tested.
3. Attach the decision to the relevant files, services, and evidence.
4. Recall that context when a related task appears.
5. Update the memory when the implementation changes.

"""
Implementation #1: a coding agent that remembers decisions.

This is session one of the two-session test.

Run this code first, then run the eval code below as a
genuinely new session to test cross-session recall.
"""

import asyncio
import json
from uuid import UUID

import cognee

PROJECT_DATASET = "auth_service_decisions"
INVESTIGATION_SESSION_ID = "auth-refresh-bug-investigation"

INVESTIGATION_NOTES = """Investigating why refresh tokens remain valid after logout.
Current hypothesis: the refresh path doesn't check token revocation.
The proposed fix hasn't been verified yet.
"""

# Step 3 happens inside this payload: the decision is stored together
# with the files it affects, the rejected alternative, and the tests
# that verified it, so recall can bring the whole picture back.
VERIFIED_OUTCOME = json.dumps(
    {
        "type": "verified_bug_fix",
        "issue": "Refresh tokens remained valid after logout",
        "cause": (
            "The refresh-token path didn't check whether "
            "the token had been revoked."
        ),
        "fix": "Added Redis-backed token revocation checks",
        "affected_files": [
            "auth/refresh.py",
            "auth/logout.py",
        ],
        "rejected_approaches": [
            {
                "approach": "Shorter refresh-token expiry",
                "reason": (
                    "It reduced the exposure window but didn't "
                    "support immediate revocation."
                ),
            }
        ],
        "verification": {
            "status": "tested",
            "tests": [
                "logout revokes the active refresh token",
                "revoked tokens fail during refresh",
            ],
        },
    },
    indent=2,
)

async def keep_investigation_in_session() -> None:
    # Step 1: unverified investigation details stay in session memory.
    # self_improvement=False prevents this write from being bridged
    # into the permanent graph before the outcome has been validated.
    await cognee.remember(
        INVESTIGATION_NOTES,
        session_id=INVESTIGATION_SESSION_ID,
        self_improvement=False,
    )

async def remember_verified_bug_fix():
    # Step 2: only the tested outcome goes into durable memory.
    result = await cognee.remember(
        VERIFIED_OUTCOME,
        dataset_name=PROJECT_DATASET,
    )
    return result

async def recall_decision_context(question: str, *, only_context: bool = False):
    # Step 4: a related task in any later session recalls the decision
    # from dataset-scoped graph memory. With only_context=True this
    # returns the retrieved context without an LLM completion, which
    # lets an evaluator check retrieval and application separately.
    return await cognee.recall(
        question,
        datasets=[PROJECT_DATASET],
        only_context=only_context,
    )

async def update_bug_fix_memory(*, revised_outcome: str, outdated_data_id: UUID):
    # Step 5: when the implementation changes, store the replacement
    # first, then remove the superseded record so both versions never
    # stay active at once. The data_id comes from the RememberResult
    # of the original write (result.items[0]["id"]).
    await cognee.remember(
        revised_outcome,
        dataset_name=PROJECT_DATASET,
    )
    await cognee.forget(
        data_id=outdated_data_id,
        dataset=PROJECT_DATASET,
    )

async def main() -> None:
    await keep_investigation_in_session()
    print(f"Session memory written to session '{INVESTIGATION_SESSION_ID}'.")

    result = await remember_verified_bug_fix()
    print(result)
    for item in result.items:
        # Keep this id if you later need to supersede the decision
        # with update_bug_fix_memory().
        print(f"Stored decision data_id: {item.get('id')}")

if __name__ == "__main__":
    asyncio.run(main())

Evaluating memory persistence

In the first session, resolve a real bug and store the cause, fix, and affected files.

Then, start a fresh session and ask:

Why did we choose this implementation, and which files would need review before changing it?

The test passes when the agent retrieves the earlier reasoning and uses it in the new task rather than repeating the investigation.

"""
Session two: evaluate whether the coding agent's memory survived.

Run this code as a fresh process to evaluate the approach we built above.
It checks the two stages the diagnostic framework separates:

- Retrieval -- did the stored decision come back from dataset-scoped
  recall? Checked against the exact identifiers the decision was stored
  with (file paths, the revocation mechanism).
- Application -- did the final answer actually use the decision?
  Graded by an LLM judge with structured output instead of brittle
  substring matching, so paraphrased answers still pass and answers
  that merely echo keywords without the reasoning still fail.

Exit code 0 means both stages passed. Pass ``--cleanup`` to also
remove the demo dataset afterwards so the test can rerun from scratch.
"""

import asyncio
import json
import sys

from pydantic import BaseModel, Field

import cognee
from cognee.infrastructure.llm.LLMGateway import LLMGateway

from coding_agent_memory import PROJECT_DATASET, recall_decision_context

RECALL_QUESTION = (
    "Why does this project use Redis-backed token revocation, "
    "and which files should be reviewed before changing it?"
)

# What a passing answer must actually use, stated as facts rather than
# keywords. The judge grades meaning, so wording can differ.
EXPECTED_DECISION_POINTS = [
    (
        "Redis-backed revocation was chosen because the rejected "
        "alternative, shorter refresh-token expiry, could not revoke "
        "tokens immediately after logout."
    ),
    "auth/refresh.py should be reviewed before changing the implementation.",
    "auth/logout.py should be reviewed before changing the implementation.",
]

# Exact identifiers from the stored decision. Substring matching is
# appropriate here because this checks what retrieval returned, not
# how the model phrased its answer.
RETRIEVAL_MARKERS = [
    "auth/refresh.py",
    "auth/logout.py",
    "revocation",
]

JUDGE_SYSTEM_PROMPT = """You evaluate whether an AI agent's answer used specific
remembered decision points. You are given the answer and a list of expected
points. For each point, decide whether the answer conveys its substance --
exact wording is not required, but the reasoning must be present, not just
a passing keyword mention. Sort each point into supported_points or
missing_points, set memory_was_applied to true only when every point is
supported, and explain your grading briefly."""

class MemoryUseEvaluation(BaseModel):
    supported_points: list[str] = Field(
        description="Expected points whose substance appears in the answer."
    )
    missing_points: list[str] = Field(
        description="Expected points the answer fails to convey."
    )
    memory_was_applied: bool = Field(
        description="True only if every expected point is supported."
    )
    explanation: str = Field(description="Brief grading rationale.")

async def evaluate_memory_use(
    response: str, expected_points: list[str]
) -> MemoryUseEvaluation:
    return await LLMGateway.acreate_structured_output(
        text_input=json.dumps(
            {"answer": response, "expected_points": expected_points},
            indent=2,
        ),
        system_prompt=JUDGE_SYSTEM_PROMPT,
        response_model=MemoryUseEvaluation,
    )

async def main() -> int:
    # Stage 1: retrieval. only_context=True returns what recall found
    # without generating an answer from it.
    context_results = await recall_decision_context(
        RECALL_QUESTION, only_context=True
    )
    retrieved_context = "\n".join(
        getattr(result, "text", str(result)) for result in context_results
    )

    memory_was_retrieved = all(
        marker.lower() in retrieved_context.lower()
        for marker in RETRIEVAL_MARKERS
    )
    print(f"memory_was_retrieved: {memory_was_retrieved}")

    if not memory_was_retrieved:
        missing = [
            marker
            for marker in RETRIEVAL_MARKERS
            if marker.lower() not in retrieved_context.lower()
        ]
        print(f"Markers missing from retrieved context: {missing}")
        print("Failure is in the retrieval stage; skipping the answer check.")
        return 1

    # Stage 2: application. The same recall call, now producing the
    # answer the agent would actually use.
    answer_results = await recall_decision_context(RECALL_QUESTION)
    answer = "\n".join(
        getattr(result, "text", str(result)) for result in answer_results
    )
    print(f"\nAgent answer:\n{answer}\n")

    evaluation = await evaluate_memory_use(answer, EXPECTED_DECISION_POINTS)
    print(f"memory_was_applied: {evaluation.memory_was_applied}")
    for point in evaluation.supported_points:
        print(f"  [supported] {point}")
    for point in evaluation.missing_points:
        print(f"  [missing]   {point}")
    print(f"Judge rationale: {evaluation.explanation}")

    return 0 if evaluation.memory_was_applied else 1

async def cleanup() -> None:
    await cognee.forget(dataset=PROJECT_DATASET)
    print(f"Removed demo dataset '{PROJECT_DATASET}'.")

if __name__ == "__main__":
    exit_code = asyncio.run(main())
    if "--cleanup" in sys.argv:
        asyncio.run(cleanup())
    sys.exit(exit_code)

Here's a more thorough, dedicated post on how to give an AI coding agent persistent memory.

Implementation #2: A Business Agent That Preserves Account Context

Business agents need clear boundaries around who and what a memory belongs to — account details, prior outcomes, open requests, and confirmed preferences should remain available without leaking into another customer's context.

A support or sales workflow could:

• Recall account context when the interaction begins.
• Keep temporary conversation details in session memory.
• Save verified outcomes after the interaction.
• Replace outdated preferences or account facts.
• Preserve the source and date of important claims.

"""
Implementation #2: a business agent that preserves account context.

Every memory write lands in the scopes defined by the table above.

Running this code seeds one shared policy and handles one support
interaction for each of two accounts. Run the eval code in the next
snippet after this one to verify that no memory crosses an account boundary.

Deployment requirement: dataset-scoped retrieval is only enforced with
``ENABLE_BACKEND_ACCESS_CONTROL=true`` and an isolation-capable backend
set (Ladybug/LanceDB/SQLite/Postgres). In single-user mode the
``datasets`` argument does not scope search -- everything shares one
graph, and the eval's isolation checks will (correctly) fail. Set
these in your ``.env`` (cognee loads it with override=True, so shell
environment variables alone won't take precedence):

    ENABLE_BACKEND_ACCESS_CONTROL="true"
    GRAPH_DATABASE_PROVIDER="ladybug"
"""

import asyncio
import json
from datetime import date
from typing import Optional

from pydantic import BaseModel, Field

import cognee
from cognee.infrastructure.llm.LLMGateway import LLMGateway

ORG_DATASET = "org_policies"

ACME_DATASET = "account_acme"
ACME_SESSION_ID = "acme-conversation-8842"

GLOBEX_DATASET = "account_globex"
GLOBEX_SESSION_ID = "globex-conversation-3317"

# Policies and product constraints: shared organizational knowledge,
# available to every account's recall.
ORG_POLICY = (
    "Company policy for all accounts: invoices are issued on the 1st "
    "of each month, and refunds above $500 require manager approval."
)

class InteractionOutcome(BaseModel):
    """What the agent concluded from one support interaction."""

    reply_to_customer: str = Field(description="The agent's answer to the request.")
    confirmed_preferences: list[str] = Field(
        description="Preferences the customer explicitly confirmed."
    )
    open_actions: list[str] = Field(description="Actions still pending after the reply.")
    promised_follow_up: Optional[str] = Field(
        default=None, description="Any follow-up the agent committed to."
    )

async def remember_org_policy(policy_text: str) -> None:
    await cognee.remember(policy_text, dataset_name=ORG_DATASET)

async def recall_account_context(request: str, *, account_dataset: str, only_context: bool = False):
    # Retrieval is scoped to this account's dataset plus shared
    # organizational knowledge -- never another account's dataset.
    # [In production, connect the dataset scope to the authenticated
    # user's permissions so the boundary is enforced, not just chosen.]
    return await cognee.recall(
        request,
        datasets=[account_dataset, ORG_DATASET],
        only_context=only_context,
    )

async def keep_conversation_in_session(conversation: str, *, session_id: str) -> None:
    # Current conversation and pending actions stay in session memory.
    # self_improvement=False keeps unverified conversation details from
    # being bridged into permanent memory automatically.
    await cognee.remember(
        conversation,
        session_id=session_id,
        self_improvement=False,
    )

async def run_business_agent(request: str, context: str) -> InteractionOutcome:
    # Stand-in for the production agent runtime: one structured-output
    # call that answers the request using the recalled context. The
    # prompt forbids speculation because everything this call returns
    # gets written to memory: an invented "would you also like..."
    # stored as an open action is exactly the save-the-wrong-
    # information failure durable memory is supposed to avoid.
    return await LLMGateway.acreate_structured_output(
        text_input=json.dumps({"customer_request": request, "recalled_context": context}),
        system_prompt=(
            "You are a customer support agent. Answer the request using "
            "the recalled account and policy context. Record only "
            "preferences the customer explicitly stated in this request, "
            "and only actions this request actually requires. Never "
            "invent, offer, or speculate about changes the customer did "
            "not ask for, in the reply or in the recorded fields."
        ),
        response_model=InteractionOutcome,
    )

async def handle_account_memory(
    *,
    current_request: str,
    account_id: str,
    account_dataset: str,
    session_id: str,
) -> InteractionOutcome:
    # Recall account context when the interaction begins.
    account_context = await recall_account_context(
        current_request, account_dataset=account_dataset
    )
    context_text = "\n".join(
        getattr(result, "text", str(result)) for result in account_context
    )

    outcome = await run_business_agent(request=current_request, context=context_text)

    # Keep the conversation and its pending actions in session memory.
    await keep_conversation_in_session(
        json.dumps(
            {
                "customer_request": current_request,
                "agent_reply": outcome.reply_to_customer,
                "pending_actions": outcome.open_actions,
            },
            indent=2,
        ),
        session_id=session_id,
    )

    # Store only the verified outcome, not the entire transcript.
    # Provenance (source and date) is set by the system, not the model,
    # so recalled claims stay traceable to where they came from.
    verified_interaction_outcome = json.dumps(
        {
            "type": "verified_account_update",
            "account_id": account_id,
            "confirmed_preferences": outcome.confirmed_preferences,
            "open_actions": outcome.open_actions,
            "promised_follow_up": outcome.promised_follow_up,
            "source": f"support conversation {session_id}",
            "verified_at": date.today().isoformat(),
        },
        indent=2,
    )
    result = await cognee.remember(
        verified_interaction_outcome,
        dataset_name=account_dataset,
    )
    for item in result.items:
        # Keep this id to supersede the fact later with
        # update_account_fact() when the preference changes.
        print(f"[{account_id}] stored outcome data_id: {item.get('id')}")

    return outcome

async def update_account_fact(*, revised_fact: str, outdated_data_id, account_dataset: str):
    # Replace outdated preferences or account facts: write the
    # replacement first, then remove the superseded record so both
    # versions never stay active at once.
    await cognee.remember(revised_fact, dataset_name=account_dataset)
    await cognee.forget(data_id=outdated_data_id, dataset=account_dataset)

async def main() -> None:
    await remember_org_policy(ORG_POLICY)
    print(f"Org policy stored in shared dataset '{ORG_DATASET}'.")

    acme_outcome = await handle_account_memory(
        current_request=(
            "We require every invoice to include a purchase-order number. "
            "Can you make sure our invoicing is set up that way?"
        ),
        account_id="acme",
        account_dataset=ACME_DATASET,
        session_id=ACME_SESSION_ID,
    )
    print(f"[acme] reply: {acme_outcome.reply_to_customer}")

    globex_outcome = await handle_account_memory(
        current_request=(
            "Please send all support updates by email only, never by "
            "phone. Does anything change about how we receive refunds?"
        ),
        account_id="globex",
        account_dataset=GLOBEX_DATASET,
        session_id=GLOBEX_SESSION_ID,
    )
    print(f"[globex] reply: {globex_outcome.reply_to_customer}")

if __name__ == "__main__":
    asyncio.run(main())

Evaluating scope impermeability

The key test here is to run the same query under another account and confirm that none of the first customer's memory appears. Run the test code below after running the agent above to ensure data from one scope doesn't bleed into another:

"""
Scope tests for the business agent's account memory.

Run the business agent first. Each check maps to one row of
the article's scoping table, and the core of the suite is isolation:
memory written during one account's conversation must never surface in
another account's retrieval.

- Account isolation (both directions) -- confirmed facts stay inside
  the account dataset they belong to.
- Session isolation -- one conversation's details don't appear among
  another conversation's session entries, with a positive control
  proving session recall works at all.
- Shared organizational knowledge -- policies are the one scope that
  should reach every account, proving isolation isn't just recall
  returning nothing.
- Provenance -- a recalled outcome can be traced back to the
  conversation that produced it.

Isolation checks run against retrieved context (only_context=True)
rather than generated answers, so they test what retrieval returned,
not how a model happened to phrase it. Exit code 0 means every check
passed. Pass ``--cleanup`` to remove the three demo datasets.

Run with the same environment as the seeding script. Isolation holds
only when ``ENABLE_BACKEND_ACCESS_CONTROL=true`` with an
isolation-capable backend set (Ladybug/LanceDB/SQLite/Postgres); in
single-user mode the dataset argument does not scope retrieval, and
this suite fails -- which is the scope leakage it exists to detect.
"""

import asyncio
import sys

import cognee

from business_agent_memory import (
    ACME_DATASET,
    ACME_SESSION_ID,
    GLOBEX_DATASET,
    GLOBEX_SESSION_ID,
    ORG_DATASET,
    recall_account_context,
)

# Leak markers are anchored to the other account's identity, its
# conversation, and the exact facts it stored -- not generic
# vocabulary. Generic keywords ("po number", "email") collide with an
# agent's own incidental wording and report false leaks; identifiers
# and stored phrasings only appear when the other account's memory
# actually crossed the boundary.
ACME_FACT_MARKERS = ["acme", "purchase-order", "purchase order"]
GLOBEX_FACT_MARKERS = ["globex", "email only", "never by phone", "do not call"]
ORG_POLICY_MARKER = "manager approval"
ACME_PROVENANCE_MARKER = ACME_SESSION_ID  # "support conversation acme-conversation-8842"

def context_text(results) -> str:
    return "\n".join(getattr(result, "text", str(result)) for result in results).lower()

def report(name: str, passed: bool, detail: str = "") -> bool:
    status = "PASS" if passed else "FAIL"
    print(f"[{status}] {name}" + (f" -- {detail}" if detail else ""))
    return passed

async def check_account_isolation() -> bool:
    # Ask each account the question whose answer belongs to the OTHER
    # account, through the same recall path the agent uses in
    # production. Nothing may come back.
    globex_view = context_text(
        await recall_account_context(
            "What invoice requirements does this account have?",
            account_dataset=GLOBEX_DATASET,
            only_context=True,
        )
    )
    leaked_to_globex = [m for m in ACME_FACT_MARKERS if m in globex_view]

    acme_view = context_text(
        await recall_account_context(
            "How should support updates be delivered to this account?",
            account_dataset=ACME_DATASET,
            only_context=True,
        )
    )
    leaked_to_acme = [m for m in GLOBEX_FACT_MARKERS if m in acme_view]

    ok = report(
        "account isolation",
        not leaked_to_globex and not leaked_to_acme,
        f"leaked into globex: {leaked_to_globex or 'none'}, "
        f"leaked into acme: {leaked_to_acme or 'none'}",
    )
    return ok

async def check_session_isolation() -> bool:
    # Session recall falls through to the permanent graph when nothing
    # matches, so filter to entries recall labels source="session" --
    # the scope this check is about.
    results = await cognee.recall(
        "What did the customer ask about invoices and purchase orders?",
        session_id=GLOBEX_SESSION_ID,
    )
    session_entries = [r for r in results if getattr(r, "source", None) == "session"]
    session_text = context_text(session_entries)
    leaked = [m for m in ACME_FACT_MARKERS if m in session_text]
    isolated = report(
        "session isolation",
        not leaked,
        f"acme conversation markers among globex session entries: {leaked or 'none'}",
    )

    # Positive control: Globex's own conversation IS retrievable from
    # its session, so the isolation pass above isn't vacuous.
    own_results = await cognee.recall(
        "support updates email phone refunds",
        session_id=GLOBEX_SESSION_ID,
    )
    own_entries = [r for r in own_results if getattr(r, "source", None) == "session"]
    control = report(
        "session recall positive control",
        "email" in context_text(own_entries),
        f"{len(own_entries)} session entries returned",
    )
    return isolated and control

async def check_shared_org_knowledge() -> bool:
    # Shared organizational knowledge is the one scope that should
    # reach every account.
    globex_view = context_text(
        await recall_account_context(
            "What is the refund approval policy?",
            account_dataset=GLOBEX_DATASET,
            only_context=True,
        )
    )
    return report(
        "shared org knowledge reaches accounts",
        ORG_POLICY_MARKER in globex_view,
        f"looking for '{ORG_POLICY_MARKER}'",
    )

async def check_provenance() -> bool:
    # A recalled outcome should be traceable to the conversation that
    # produced it.
    acme_view = context_text(
        await recall_account_context(
            "Where did this account's invoice requirement come from, "
            "and when was it confirmed?",
            account_dataset=ACME_DATASET,
            only_context=True,
        )
    )
    return report(
        "provenance retrievable",
        ACME_PROVENANCE_MARKER.lower() in acme_view,
        f"looking for source '{ACME_PROVENANCE_MARKER}'",
    )

async def main() -> int:
    results = [
        await check_account_isolation(),
        await check_session_isolation(),
        await check_shared_org_knowledge(),
        await check_provenance(),
    ]
    print(f"\n{sum(results)}/{len(results)} checks passed.")
    return 0 if all(results) else 1

async def cleanup() -> None:
    for dataset in (ACME_DATASET, GLOBEX_DATASET, ORG_DATASET):
        await cognee.forget(dataset=dataset)
        print(f"Removed demo dataset '{dataset}'.")

if __name__ == "__main__":
    exit_code = asyncio.run(main())
    if "--cleanup" in sys.argv:
        asyncio.run(cleanup())
    sys.exit(exit_code)

cognee supports multi-user deployments with dataset-level permissions, tenant access, and isolated retrieval.

How to Measure Agent Memory Quality

Memory quality depends on whether relevant information returns at the right time and improves the agent's work.

Not every system needs all eight of these instrumented from day one. Application success and task improvement are the two that tell you whether memory is actually helping — start there, and add the rest as usage grows and specific failures start showing a pattern.

Compare the task with no external memory, session state only, and long-term retrieval enabled. Then rerun it after correcting and deleting a stored memory.

The final two tests reveal whether the system can adapt as its knowledge changes. A memory layer that recalls old information accurately but can't update or remove it will become less reliable over time.

Trace the Break, Then Fix It

AI agent forgetfulness can start anywhere along the memory path: capture, storage, retrieval, context assembly, or later updates. The fastest fix is to trace one concrete fact through that path and repair the point where it disappears.

Checkpointing and cleaner context management can stabilize the current workflow. Cross-session continuity needs persistent memory, selective retrieval, clear scope, and a way to replace information as it changes.

FAQ

Can several AI agents share the same memory?+

Yes, as long as the memory layer supports shared scope and permissions. Each entry should retain its source, owner, and access rules so agents only retrieve information they're authorized to use.

Does an AI agent need a vector database for memory?+

No. Vector search helps retrieve semantically similar information, but agent memory may also use caches, relational databases, document indexes, or knowledge graphs. Many systems combine several storage and retrieval methods.

What happens if the agent recalls something incorrect?+

Treat anything recalled the same way you'd treat any other context handed to the model: useful, not automatically correct. Provenance and timestamps help the system judge whether a recalled fact is still current, but the agent should still be able to flag uncertainty rather than treating every recalled memory as settled fact. If a wrong memory keeps resurfacing, correcting it explicitly is more reliable than assuming it'll age out on its own.