Why a Single Correction Shouldn't Become an Agent's Long-Term Memory

Opening Example: Procurement Exception

A purchasing assistant flags a supplier for missing materials. A business user corrects it: "This supplier is a historical project renewal; this purchase can follow an already-approved exception process." If the agent blindly records "This supplier doesn't need material checks," the next purchase might incorrectly skip verification. The correction applies only to the current project, approval, and rule — not universally.

Distinguish What to Remember

Long-term memory means persisting information beyond the current conversation (files, database records), not retraining the model. Anthropic's context engineering article describes structured notes and on-demand retrieval, but persistence alone doesn't guarantee reliability or future applicability.

Three categories must not share the same storage pipeline:

Personal preference (e.g., "Show me tables") — adjustable by the individual.

Task fact (e.g., "This batch purchase is approved") — requires business record evidence.

Enterprise rule (e.g., "All renewals are exempt") — requires confirmation by authorized personnel.

Mixing them blurs whether a stored item is an approved rule or a one-off comment.

Record Full Provenance and Scope for Each Correction

For the procurement exception, capture metadata before changing any review rule:

Memory type : Current project exception fact, not a general exemption rule.

Source & basis : Feedback provider, linked task, approval record and version.

Applicable scope : Specific customer, project, supplier, and purchase batch.

Visibility scope : Only personnel and services allowed to access the original business data.

Effective & expiry : Approval validity period and revocation handling.

Current status : Pending verification, active, or disabled, with confirmation log.

Validation requirement : Current project must reference correctly; other projects must not misuse.

Owner : Who confirms, maintains, and resolves disputes.

Fields can be auto-populated from task and business systems, but missing scope fields must never default to "company-wide." The exception stays in a pending-verification state until an authorized person validates approval and scope, then passes scenario-based retrieval tests before participating in subsequent tasks. Personal preferences bypass this business approval flow.

Validation Before Enabling: Test Applicable, Inapplicable, and Revoked Cases

Re-asking the original question and getting a correct answer doesn't prove the new memory worked. Verify retrieval: was the record fetched and injected into context? Compare results with and without the memory. Model self-reports are insufficient; a few samples don't prove stable improvement. Test across varying projects, customers, times, and identities to detect misapplication.

Prepare at least three sample types:

Cases where the memory should be used.

Similar-looking cases where it must not be used.

Cases where the original basis has been revoked .

Check both false positives (misuse) and false negatives (missed use). A full evaluation platform isn't mandatory initially; start with a few real, de-sensitized corrections, preserve pre-memory results, and compare candidate versions. The key is uncovering side effects, not just repeating the original success.

When the model, prompt, retrieval method, or tools change, the same memory may be interpreted differently. Important rules must be re-validated after such changes; unchanged content doesn't guarantee unchanged behavior.

Maintenance Grows with Memory Volume

"Save succeeded" is easy; "never misused again" is harder. When a rule is retired:

Mark the primary record as invalid.

Update retrieval indexes, caches, and any copies inside in-flight tasks.

Decide whether tasks that already referenced it can continue or must re-verify.

Stopping use for new tasks doesn't mean deleting history. Audits may need to know what an old task referenced. Retire usage and retain audit records separately.

Permission changes must propagate: past access doesn't imply current access. Copying content into a "shared memory" must not bypass original customer isolation and access controls.

What Deserves Long-Term Retention

If a temporary conclusion changes frequently, querying the business system directly is more reliable than maintaining a memory entry. If an experience cannot clearly define its applicability, don't rush to automate its decision participation.

Prioritize keeping content that has clear provenance and scope, sees repeated reuse, and has a designated maintainer. Everything else stays in task logs — not every conversation needs a long-term memory entry.

For the purchasing assistant, remembering to check exception approvals first is more valuable than remembering "this supplier can skip checks." Handling contradictory memories or agents is a separate challenge.

Reference

Anthropic, Effective context engineering for AI agents : https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents