Your AI Agent Rejected a Stale Decision. Why Is It Still Remembering It?

Subtitle: Blocking an unsafe action is not enough. If an AI agent keeps retrieving the outdated decision that caused the failure, the same mistake can return in the next session.

I have been thinking about a particular problem with long-running AI agents.

We have become increasingly good at discussing how to stop an agent from executing an unsafe action. We validate permissions. We check the current state of a resource. We use version numbers, conditional updates, approval records and execution-time checks. These are important controls. They prevent an agent from acting on information that is no longer valid. But there is another question that deserves just as much attention:

What happens to the information that caused the agent to make the rejected decision in the first place?

Imagine an AI agent checking an order and recording that a refund is eligible. A few minutes later, another service processes the refund. The original agent eventually attempts the same operation, but the execution layer checks the current order version and rejects it.

Good, the system has prevented a duplicate refund. However, the original memory record still says:

Order: ORD-1042
Refund eligible: true
Source version: 12
Decision: refund_eligible

Nothing about the rejected execution automatically changes that record. A week later, another agent retrieves the same memory. It sees a previous decision stating that the customer was eligible for a refund. Depending on how retrieval and context construction work, it may treat that decision as useful evidence and propose the same action again.

The execution layer has learned that the decision is stale. The memory layer has not, and that is the gap I want to explore in this article. An AI agent should not only detect that a decision is based on stale information. It should also preserve that discovery in its memory system, connect it to the original decision and prevent the obsolete conclusion from being treated as the current truth.

This is not simply a memory-cleaning problem. It is a problem involving state management, provenance, event processing, retrieval consistency and system reliability.

1. The action was rejected. The decision survived.

Let's return to a simple example.

At 10:00 AM, an agent retrieves an order:

{
  "order_id": "ORD-1042",
  "version": 12,
  "payment_status": "paid",
  "refund_status": "not_processed",
  "refund_eligible": true
}

The agent evaluates the information and creates a decision record:

{
  "decision_id": "DEC-9001",
  "entity_id": "ORD-1042",
  "decision": "refund_eligible",
  "source_version": 12,
  "created_at": "10:00:00"
}

At 10:03 AM, another service processes the refund. The order changes to version 13.

At 10:04 AM, the original agent tries to execute its decision. The execution service checks the current order version and discovers that the agent is working with version 12 while the authoritative record is now version 13.

The operation is rejected.

if current_order.version != decision.source_version:
    raise StaleContextError(
        entity_id=decision.entity_id,
        expected_version=decision.source_version,
        current_version=current_order.version
    )

This is a useful protection. The agent cannot execute an operation based on an outdated snapshot. But look at what has not happened. The original decision record still exists. The vector database may still contain its embedding. A conversation summary may still mention that the customer was eligible for a refund. A long-term memory store may still associate the customer with that decision.

The system has rejected the action without correcting the information that produced it. This distinction matters because AI agents do not always operate in one continuous conversation. They may return to a task after several hours, receive a new instruction, or hand work to another agent.

A stale decision can outlive the workflow in which it was created. The problem is no longer limited to one failed transaction. It becomes a recurring source of incorrect reasoning.

2. Memory is not a single database

One reason this problem is easy to overlook is that we often talk about agent memory as though it were one storage location. In a real application, information can be distributed across several layers:

These layers do not necessarily share the same update mechanism.

For example, updating a structured record does not automatically remove its corresponding vector embedding. Updating a vector index does not necessarily change a conversation summary. A second agent may already have copied the old decision into its own context.

This means that memory correction needs to be designed as a coordinated process.

I would separate the problem into three responsibilities:

1. Decision history: Preserve what the agent believed and why.
2. Current validity: Establish whether that decision is still usable.
3. Retrieval eligibility: Control whether the decision can be presented as current information.

These responsibilities should not be collapsed into a single delete operation.

We need to know that the agent made a decision based on version 12. That is useful for debugging and auditing. But we also need to ensure that the same decision cannot be retrieved as an active conclusion after version 13 has superseded it.

3. Why deleting the old memory is not the answer

The first reaction might be straightforward: when StaleContextError occurs, delete the old memory. I would be careful with that approach.

Deleting the record removes evidence of what happened. It may make debugging difficult, particularly when an operation has financial, operational or compliance implications.

Suppose an investigation takes place a month later. The team needs to answer:

• What did the agent believe at the time?
• Which version of the order did it use?
• Why was the action rejected?
• Which system identified the inconsistency?
• Was the original decision ever corrected?
• Did another workflow retrieve the same outdated information?

If we simply delete the original record, we lose part of that history. The better approach is to preserve the original decision while changing its validity.

For example:

{
  "decision_id": "DEC-9001",
  "entity_id": "ORD-1042",
  "decision": "refund_eligible",
  "source_version": 12,
  "status": "superseded",
  "superseded_by": "COR-9001",
  "created_at": "10:00:00"
}

We then create a correction record:

{
  "correction_id": "COR-9001",
  "entity_id": "ORD-1042",
  "invalidated_decision_id": "DEC-9001",
  "observed_version": 12,
  "current_version": 13,
  "reason": "source_version_mismatch",
  "status": "confirmed",
  "created_at": "10:04:00"
}

The important detail is that the correction does not claim that every historical statement about version 12 was false. It says something more precise:

The decision was based on version 12, and that decision is no longer valid for current decision-making because the authoritative entity has advanced to version 13. That distinction protects historical accuracy while preventing outdated information from being reused incorrectly.

4. Give memory a lifecycle

If we want memory to behave reliably, it needs an explicit lifecycle. A record should not remain indefinitely available simply because it was once valid. For decision records, I would start with three states:

          New decision
               |
               v
            ACTIVE
               |
       Staleness detected
               |
               v
             STALE
               |
      Correction confirmed
               |
               v
          SUPERSEDED

These states have different meanings.

ACTIVE

The decision has been recorded and is currently eligible for retrieval, subject to normal validation requirements.

STALE

The system has discovered that the decision depends on an outdated version or an invalidated source. It should not be used for an action until revalidated.

SUPERSEDED

A correction or newer decision has replaced the old decision for current use. The original record remains available for historical inspection. There is another important distinction: stale does not always mean superseded. Suppose the system detects a version mismatch but cannot retrieve the current record because the database is temporarily unavailable.

It knows that its old information may be invalid. It does not yet know what the new state is. The correct response is to mark the decision stale, block its use for sensitive actions and attempt to reconcile it later. It should not invent a replacement decision.

Similarly, if a new version is retrieved but the refund status is still unclear, the agent should not automatically conclude that the customer is ineligible. It needs a fresh evaluation against the authoritative state. Memory correction should establish what is known, not manufacture certainty.

5. What should happen when StaleContextError occurs?

This is where I think the original execution check can become more useful. A stale-context exception already contains valuable information:

• The entity involved.
• The version used by the original decision.
• The version currently observed.
• The decision that attempted execution.
• The workflow or execution identifier.

Instead of treating the exception only as a reason to stop an action, we can use it to initiate a correction workflow. I would structure the process like this:

              AI Agent
                 |
                 v
          Retrieves Memory
                 |
                 v
          Creates Decision
                 |
                 v
          Execution Gateway
                 |
           Version Check
                 |
          +------+------+
          |             |
        Match        Mismatch
          |             |
          v             v
       Execute     StaleContextError
                        |
                        v
                Memory Correction
                        |
                        v
                Mark Decision STALE
                        |
                        v
               Verify Current State
                        |
                        v
              Append Correction Record
                        |
                        v
              Update Retrieval Index
                        |
                        v
               Re-evaluate if needed

The correction workflow should not execute inside the same fragile path that rejected the original action. If the execution request fails because a database connection is unavailable, the system should not assume that the correction has been persisted successfully.

I would use a durable event or job for the correction process. For example:

{
  "event_type": "DecisionInvalidated",
  "event_id": "EVT-7001",
  "decision_id": "DEC-9001",
  "entity_id": "ORD-1042",
  "expected_version": 12,
  "observed_version": 13,
  "reason": "source_version_mismatch"
}

This event describes what happened. It does not itself prove that every memory layer has been updated. That is an important difference. Publishing an invalidation event is the beginning of the correction process, not the completion of it.

6. Designing a version-aware memory record

A useful memory record needs more than a sentence and an embedding. It needs enough metadata to establish where the information came from and whether it is still usable. Here is an illustrative structure:

from dataclasses import dataclass
from datetime import datetime
from typing import Optional


@dataclass
class DecisionMemory:
    decision_id: str
    entity_id: str

    decision: str
    source_version: int
    source_system: str

    created_at: datetime
    status: str

    superseded_by: Optional[str] = None
    invalidation_reason: Optional[str] = None
    correction_version: Optional[int] = None

A record might look like:

memory = DecisionMemory(
    decision_id="DEC-9001",
    entity_id="ORD-1042",
    decision="refund_eligible",
    source_version=12,
    source_system="order-service",
    created_at=datetime.utcnow(),
    status="active"
)

The most important fields are not necessarily the decision itself. They are:

source_version

Which version of the authoritative entity supported this decision?

source_system

Where did the information originate?

status

Can this record currently participate in decision-making?

superseded_by

Which correction or replacement record changed its validity?

invalidation_reason

Why did the system stop treating the decision as current?

These fields create a relationship between the agent's reasoning and the system state that supported it. Without that relationship, memory retrieval can return a conclusion without exposing the conditions under which it was reached. That is dangerous.

A statement such as "customer is eligible for a refund" looks simple when retrieved as natural language. But the same statement becomes much less trustworthy when we discover that it was based on an older version that is no longer current.

7. Implementing a correction handler

Let's turn the idea into a small Python example. The following is illustrative application code. It shows the responsibilities of a correction handler rather than a complete production implementation.

class StaleContextError(Exception):
    def __init__(
        self,
        entity_id,
        decision_id,
        expected_version,
        current_version
    ):
        self.entity_id = entity_id
        self.decision_id = decision_id
        self.expected_version = expected_version
        self.current_version = current_version

        super().__init__(
            f"Stale decision for {entity_id}: "
            f"expected version {expected_version}, "
            f"current version {current_version}"
        )

The correction handler receives the exception and creates a durable correction request.

def handle_stale_decision(error, correction_store):

    correction = {
        "entity_id": error.entity_id,
        "decision_id": error.decision_id,
        "expected_version": error.expected_version,
        "current_version": error.current_version,
        "reason": "source_version_mismatch"
    }

    correction_store.enqueue(
        correction,
        idempotency_key=(
            f"{error.decision_id}:"
            f"{error.current_version}"
        )
    )

    return {
        "status": "correction_pending",
        "decision_id": error.decision_id
    }

There are two deliberate choices here. First, the handler does not directly rewrite every memory store. It creates a durable correction request.

Second, it uses an idempotency key. Why?

Because correction events can be delivered more than once. A worker might process an event and crash before acknowledging it. The event may then be delivered again. Without idempotency, the system could create duplicate correction records or perform unnecessary index updates. The correction worker can then perform the actual state transition:

def process_correction(event, memory_repository):

    memory = memory_repository.get(
        event["decision_id"]
    )

    if memory is None:
        return "decision_not_found"

    if memory.status == "superseded":
        return "already_corrected"

    if memory.source_version != event["expected_version"]:
        return "version_conflict"

    memory_repository.mark_stale(
        decision_id=memory.decision_id,
        reason=event["reason"],
        observed_version=event["current_version"]
    )

    return "correction_recorded"

This example deliberately stops at marking the decision stale. It does not automatically create a new decision saying that the customer is no longer eligible. That conclusion requires a fresh read and a new evaluation. This separation is important because a version mismatch tells us that the old decision cannot safely be reused. It does not tell us everything about the new business state.

8. The database must protect the correction too

There is a subtle race condition here. Imagine this sequence:

1. Decision DEC-9001 was created against version 12.
2. A stale-context event reports that version 13 is current.
3. Before the correction worker processes the event, another workflow retrieves version 14.
4. A newer decision is created against version 14.
5. The delayed correction event arrives.

If the correction handler blindly updates every record associated with the entity, it could invalidate information that is newer than the event itself.

The correction must be tied to the exact decision and source version. An illustrative SQL update could look like this:

UPDATE decision_memory
SET
    status = 'stale',
    invalidation_reason = 'source_version_mismatch',
    observed_version = :current_version
WHERE
    decision_id = :decision_id
    AND source_version = :expected_version
    AND status = 'active';

The WHERE clause is doing important work.

It prevents a correction intended for one specific decision from changing an unrelated or newer decision. In a production system, I would also record the affected row count. If zero rows are updated, the worker should not simply assume success. The record might already have been corrected, deleted, or changed by another process. It should inspect the current state and classify the result.

For stronger guarantees, the decision update and correction record should be written in the same database transaction. A simplified pattern:

BEGIN;

UPDATE decision_memory
SET
    status = 'superseded',
    superseded_by = :correction_id
WHERE
    decision_id = :decision_id
    AND source_version = :expected_version
    AND status = 'active';

INSERT INTO memory_corrections (
    correction_id,
    decision_id,
    entity_id,
    expected_version,
    observed_version,
    reason
)
VALUES (
    :correction_id,
    :decision_id,
    :entity_id,
    :expected_version,
    :observed_version,
    'source_version_mismatch'
);

COMMIT;

This is a simplified example. A real implementation would check whether the update affected the expected record before inserting or finalising the correction. If the transaction fails, neither operation should be treated as committed.

The goal is to avoid a situation where the correction record says that memory was superseded, but the original record remains active, or the reverse.

9. Updating a vector database is a separate problem

Structured memory is only part of the challenge. Many agent systems retrieve information through embeddings and vector search. Suppose the original decision was converted into an embedding:

Customer ORD-1042 is eligible for a refund.

That embedding may remain searchable even after the structured decision record has been marked stale. This is one of the most important details in the architecture. Updating the database row does not automatically guarantee that vector retrieval will stop returning the old information. There are several ways to address this.

Option 1: Filter by metadata

Store the decision status and source version alongside the embedding.

For example:

{
  "decision_id": "DEC-9001",
  "entity_id": "ORD-1042",
  "source_version": 12,
  "status": "superseded"
}

Retrieval can then exclude superseded records:

results = vector_store.search(
    query="Can this order be refunded?",
    filter={
        "status": "active"
    }
)

This is useful, but only if the vector store's metadata is updated reliably and the search implementation actually applies the filter.

Option 2: Delete or replace the old embedding

The system can remove the obsolete vector or replace it with a reference to the correction record.

This reduces the chance of accidental retrieval, but deletion should not mean losing the audit history. The structured decision record should remain available.

Option 3: Retrieve, then validate

The retrieval layer can return candidate memories and check their status against the authoritative memory repository before placing them in the agent's context. This adds latency, but it creates a stronger boundary between semantic similarity and current validity. For important decisions, I prefer not to let vector similarity determine whether a fact is current. A vector database can tell us that two pieces of text are semantically similar. It cannot, by itself, establish that a decision is still valid.

The retrieval layer needs to respect the record's lifecycle.

10. The correction event can fail, too

There is a temptation to treat memory correction as a small background task.

I would not. It is part of the system's reliability boundary. Consider a few failure scenarios.

The correction event is never delivered.

The execution layer blocks the action, but the correction request is lost. The old memory remains active. A durable event queue, transactional outbox or equivalent mechanism can reduce this risk. The application should record the correction request durably before considering the correction workflow safely handed off.

The correction worker processes the event but crashes before acknowledging it.

The event is delivered again. This is where idempotency matters. Processing the same correction twice should produce one logical correction, not two conflicting records.

The structured store is updated, but the vector index is not.

The original embedding remains searchable. The system needs to track index-update status and either retry the update or validate the structured record during retrieval.

The correction event arrives out of order.

An old event for version 13 arrives after a newer correction for version 14. The correction handler must compare versions and avoid allowing an older event to overwrite a newer state.

The authoritative service is unavailable.

The system knows that the original decision is stale, but cannot establish the current business state. It should keep the decision unusable for sensitive actions and retry reconciliation later.

These are not unusual edge cases in distributed systems. They are normal consequences of asynchronous processing. A reliable memory architecture must expect them.

11. Memory correction should not create false certainty

There is another risk worth discussing. When an agent discovers that a decision is stale, it may be tempting to replace it immediately with the opposite conclusion.

For example:

Old memory:
Refund eligible = true

New memory:
Refund eligible = false

But this is not necessarily correct. The only thing the version mismatch establishes is that the old decision was based on an earlier version. The new version might show:

• The refund has already been processed.
• The order has been cancelled.
• The payment is still under investigation.
• A partial refund has been issued.
• The order is eligible under a different policy.
• The customer has received a manual adjustment.

The correction process should therefore distinguish between two operations:

1. Invalidating the old conclusion.
2. Establishing a new conclusion.

They are related, but they are not the same. A correction record might say:

{
  "decision_id": "DEC-9001",
  "status": "superseded",
  "reason": "source_version_mismatch",
  "replacement_decision_id": null
}

Only after retrieving the current order and evaluating the applicable business rules should the system create a replacement decision. That decision should have its own identifier, source version and provenance. This prevents the memory layer from becoming another place where the agent turns uncertainty into a confident statement.

12. What happens when multiple agents share the same memory?

The problem becomes more interesting in multi-agent systems. Imagine three agents:

• A customer support agent.
• A refund processing agent.
• A customer history agent.

The customer support agent retrieves an old decision and passes it to the refund agent. The refund agent checks the current order version and rejects the operation.

However, the customer history agent may already have stored the original decision in its own memory. Updating one shared database does not necessarily correct every copy of the information. This is why a correction should identify the original decision and its source, not merely say that an entity has changed. A useful event might look like:

{
  "event_type": "DecisionSuperseded",
  "decision_id": "DEC-9001",
  "entity_id": "ORD-1042",
  "source_version": 12,
  "observed_version": 13,
  "correction_id": "COR-9001"
}

Agents that maintain local memory can use this event to identify records derived from the original decision. But there is an important limitation. An agent may have copied the conclusion into a summary without preserving the original decision ID. In that case, the system may not be able to identify the exact derived memory automatically.

That is an argument for provenance-aware memory design. When one agent passes a decision to another, the message should carry enough information to trace its origin:

{
  "claim": "refund_eligible",
  "entity_id": "ORD-1042",
  "decision_id": "DEC-9001",
  "source_version": 12,
  "source_system": "order-service"
}

The receiving agent should not treat the message as a fresh authoritative fact. It is a claim with provenance. This distinction becomes increasingly important as agents delegate tasks, share context and create their own summaries. A stale conclusion should not become more trustworthy merely because it has passed through three agents instead of one.

13. A retrieval layer that understands superseded decisions

The correction process is incomplete if the retrieval layer does not understand what happened. Consider two memories:

Memory A:
Order ORD-1042 was eligible for a refund.
Source version: 12
Status: superseded

Memory B:
Refund for ORD-1042 was processed.
Source version: 13
Status: active

A simple semantic search may find both. The retrieval system needs to distinguish between historical relevance and current decision relevance. I would separate retrieval into two stages.

Stage one: Candidate retrieval

Use semantic search to find potentially relevant memories.

Stage two: Validity filtering

Check whether those memories are active, whether their source version is still acceptable and whether their provenance is available.

Illustrative code:

def retrieve_current_memories(
    query,
    entity_id,
    vector_store,
    memory_repository
):

    candidates = vector_store.search(
        query=query,
        entity_id=entity_id,
        limit=10
    )

    valid_memories = []

    for candidate in candidates:

        memory = memory_repository.get(
            candidate["decision_id"]
        )

        if memory is None:
            continue

        if memory.status != "active":
            continue

        valid_memories.append(memory)

    return valid_memories

This is intentionally simple. A real system would also consider permissions, tenant boundaries, source versions, expiry policies and whether the memory is suitable for the requested operation. Most importantly, the system should not confuse historical retrieval with permission to act. Sometimes an old decision is exactly what the agent needs. For example, when investigating why a refund was rejected last week, the superseded decision is relevant.

When deciding whether to issue a refund today, it should not be presented as current eligibility. The retrieval system, therefore, needs to understand the purpose of the query. Historical questions and current operational decisions require different retrieval policies.

14. How I would test this architecture

A memory correction mechanism should be tested beyond the happy path. It is not enough to verify that a record changes from active to superseded. The important question is whether the stale decision can return through another route.

I would start with a test matrix like this:

I would also add a regression test that reproduces the original problem. The test should:

1. Create a decision against version 12.
2. Change the authoritative entity to version 13.
3. Trigger StaleContextError.
4. Process the correction.
5. Start a completely new agent session.
6. Ask the agent whether the order is eligible for a refund.
7. Verify that the old decision is not returned as an active fact.

The new session is important.

If the test only checks the original conversation, it may miss the exact problem we are trying to solve: stale information returning through persistent memory. I would also test the case where vector retrieval returns the old embedding despite the structured record being corrected. That is a realistic failure if indexing and correction are asynchronous.

15. What should we measure?

Memory correction needs operational visibility. Otherwise, the system may appear healthy because execution failures are being blocked while stale records continue to accumulate. Some useful measurements include:

One metric deserves particular attention: the rate at which superseded memories are retrieved as current information. A vector search returning an old record is not automatically a failure. It might be useful for historical investigation. The failure occurs when the retrieval pipeline presents that record as valid evidence for a current decision.

That distinction should be reflected in monitoring. We should not optimise memory systems simply to remove old information. We should make sure old information is used in the right context.

16. The architecture I would aim for

Putting these pieces together, the architecture becomes:

                  AI Agent
                     |
                     v
              Memory Retrieval
                     |
                     v
             Provenance Validation
                     |
                     v
              Decision Creation
                     |
                     v
              Execution Gateway
                     |
              Version Validation
                     |
           +---------+---------+
           |                   |
         Valid               Stale
           |                   |
           v                   v
        Execute           Reject Action
                               |
                               v
                       Durable Correction
                               |
                               v
                       Memory State Update
                               |
                               v
                      Supersession Record
                               |
                 +-------------+-------------+
                 |                           |
                 v                           v
          Vector Index Update          Agent Memory Events
                 |                           |
                 +-------------+-------------+
                               |
                               v
                      Retrieval Validation
                               |
                               v
                      Future Agent Sessions

There are a few design principles behind this structure.

The execution layer owns the decision to execute.

The language model should not be responsible for deciding whether a stale decision is acceptable.

The memory layer owns historical continuity and validity metadata.

It should preserve the original decision while making its current status explicit.

The retrieval layer owns context eligibility.

Semantic similarity should not override record status, provenance or version constraints.

The correction workflow owns reconciliation.

It should handle retries, duplicate events, index updates and incomplete corrections. These responsibilities should be independently observable. A system should be able to tell us whether an action was rejected, whether its memory was corrected, whether the vector index was updated and whether a future retrieval respected that correction. One successful execution check does not prove that the rest of the system is healthy.

17. The mistake I would avoid

There is one implementation shortcut I would avoid: treating memory correction as a prompt instruction.

For example, after a stale-context error, the system might tell the model:

The previous refund decision was stale.
Do not use it again.

This may help within the current conversation. But it is not a durable correction. The instruction can disappear when the session ends. Another agent may not receive it. A vector search may retrieve the original memory without retrieving the warning. A summarisation process may omit the correction entirely.

The model cannot reliably enforce a memory lifecycle through natural-language instructions alone. The application needs to persist the correction and enforce its status outside the model. A useful way to think about this is:

• A prompt can explain that a memory is stale.
• A structured record can establish that it is stale.
• A retrieval policy can prevent it from being used as current information.
• An execution check can prevent it from authorising an action.

Each layer has a different responsibility. We need all of them.

18. Memory needs a way to change its mind

When I think about reliable AI agents, I increasingly see memory as more than a mechanism for retaining context. It is also a system for managing the validity of information over time.

An agent can make a reasonable decision at 10:00 AM. The underlying state can change at 10:03 AM. At 10:04 AM, the execution layer can correctly reject the original decision. But the engineering work is not finished at 10:04 AM.

The system still needs to ensure that the rejected decision does not silently return at 4:00 PM, the following morning or in another agent's workflow a week later.

That requires more than a better prompt or a larger context window.

It requires provenance, version-aware records, explicit memory states, durable correction events, retrieval filtering and a way to verify that the correction has reached the systems that use the memory.

I also think we need to be careful about what we mean by forgetting.

In an operational system, forgetting should not necessarily mean deleting history. It should mean preventing information that is no longer valid from influencing a current decision.

The original record may still be valuable. It tells us what the agent believed, which source version it used and why the execution layer rejected it.

But it should no longer have the authority to influence a new refund decision. That is the distinction between remembering an event and treating it as truth. The execution layer protects the action. The memory layer protects future reasoning. The retrieval layer connects the two.

An AI agent is not truly correcting a mistake if it keeps remembering the mistake as a valid decision.