Operate agent memory through drift, deletion and misleading recall

Pattern 08 companion: Python example · Behavioral tests · Example license

An empty result can be correct

An incident assistant asks for a queue runbook and receives no eligible record because the only available revision is obsolete. That is not necessarily a retrieval outage. It may be the correct enforcement of a compatibility boundary. The caller should distinguish no matching evidence, no authorized evidence and a failed retrieval operation without revealing the existence of protected records to an unauthorized user.

Define those outcomes in your service contract before adding dashboards. If every empty result is counted as an error, operators will be tempted to relax filters just to improve the metric. If every empty result is treated as success, an indexing failure can go unnoticed. Measure the reason categories internally and expose only the safe explanation appropriate to the caller's identity and task.

Architecture and request sequence

Component diagram for Operate agent memory through drift, deletion and misleading recall — Original reference architecture by Sandeep Belgavi. Arrows show the responsibilities and transitions described below.

Request sequence for Operate agent memory through drift, deletion and misleading recall — Illustrative sequence for this design; failure and recovery variants are explained in the article.

Freshness is an operational promise

The reference excludes records at or after their expiry and requires an exact revision match. A real runbook system needs an owner who renews or replaces guidance, not simply a background job that extends every expiry. Renewal should mean that applicability was checked under the organization's process. A fresh timestamp on stale instructions is worse than an honest expired record because it hides uncertainty from the incident responder.

Test the minute when a record crosses its expiry boundary and the release that changes the target-system revision. Keep a representative incident corpus so retrieval can be compared before and after an index rebuild or scorer change. A retrieval improvement that returns more documents may reduce answer quality if those documents are outdated, contradictory or distracting. Track relevance and applicability as separate judgments.

Deletion must reach derived state

The teaching store deletes one active row in one tenant. A production memory system may also have vector indexes, caches, conversation summaries, generated reports and backups. Deleting the source row does not automatically remove those derivatives. Maintain a source-to-derived-record relationship and define which copies are deleted, invalidated or retained under an explicit policy.

Test deletion by querying through the actual serving path after the operation completes, not just by checking the primary table. If deletion is asynchronous, expose a truthful status and prevent the supposedly removed content from being newly retrieved. Existing reports may need a revoked-evidence marker rather than a silent rewrite. The appropriate retention behavior depends on the application, but the dependency graph should make the decision enforceable.

Evaluate retrieval without leakage

Create labeled queries covering healthy incidents, stale runbooks, cross-tenant matches, contradictory notes and no-answer cases. Keep related incidents together when splitting calibration and acceptance sets so near-duplicate logs do not make the retriever appear more capable than it is. Tune ranking parameters on one set and retain a separate set for release decisions. Record the exact corpus and scorer version with every result.

Use the evaluation foundations to distinguish retrieval precision from final answer correctness. A cited answer can still misread its evidence, while an uncited answer can accidentally be right. Test citation existence, applicability and faithful interpretation separately. The original lexical fixture is not a benchmark for embedding models; it gives a stable baseline for authorization, expiry and deterministic ordering that should survive provider changes.

Cost, traces and permissions

Record candidate count after filtering, scoring latency, returned bytes, empty-result category and source revision identifiers. Avoid logging entire sensitive passages merely to improve observability. At the provider boundary, measure remote ranking calls and input volume; a top-three result limit does not prevent thousands of candidates from being sent to a reranker. Introduce a bounded candidate stage before expensive ranking when measurements justify it.

Use separate identities for ingestion, maintenance and retrieval. A retriever usually needs read access to authorized evidence, not permission to overwrite runbooks or erase audit records. A model proposing a memory update should produce a candidate for validation, not directly modify authoritative procedures. Test whether a poisoned retrieved passage can request a broader namespace or trigger a write; the gateway must reject that request independently of the model's wording.

Acceptance and controlled evolution

The companion tests establish scoped deletion, restart persistence, expiry and revision exclusion, deterministic ranking and inert treatment of document text in the local implementation. They do not establish distributed deletion completion, provider privacy or model resistance to injection. Add those checks at the relevant deployed boundaries rather than treating a passing unit suite as a complete operational sign-off.

Roll out a new scorer in shadow mode against the same authorized candidates, compare disagreements and inspect costly or unsafe changes before switching users. Keep the old scorer version and corpus snapshot long enough to explain regressions. When evidence is missing, prefer an explicit investigation step over speculative memory completion. The best operational memory is not the one that always returns something; it is the one whose returned context can be justified for the current decision.