Agent Memory — Short-Term, Long-Term & Retrieval Architectures: exercises

This is a constrained architecture problem where the standard solution (semantic vector search over embedded episode content) is explicitly prohibited. The solution requires separating what is embedded from what is stored.

Core principle: embed metadata, not content.

The HIPAA prohibition and the embedding inversion concern both target the same risk: PHI leaking through the embedding layer. The solution is to never embed PHI content. Instead:

Storage layer (PHI-bearing records): All clinical encounter records (transcripts, SOAP notes, ICD-10 codes, physician corrections) are stored in a HIPAA-compliant relational database (BAA-covered PostgreSQL or equivalent). These records are the source of truth. They are retained for 7 years per medical board requirements. Access is controlled via RBAC: only the agent operating on behalf of the specific physician's session can query that physician's records.

Embedding layer (metadata only): Create a separate embedding index that embeds only non-PHI metadata about each episode. Each episode gets a metadata record: {episode_id, physician_id, encounter_type, specialty, correction_type, date, outcome_label}. The embedding is computed over a structured description: "Cardiology encounter, physician corrected ICD-10 suggestion, outpatient, 2025-03-15." This description contains no direct patient identifiers. Dates of service are still HIPAA identifiers when linked to an individual, so generalize them (month or quarter) and have your privacy officer review the metadata fields before treating the index as PHI-free.

Retrieval mechanism: When the agent needs to recall relevant past episodes, it queries the embedding index using the current session's metadata (not PHI content): "What past corrections has this physician made in similar encounter types?" The embedding index returns episode IDs. The agent then queries the relational database with those IDs, behind RBAC, to retrieve the actual correction details. PHI moves through the relational layer only, never through the embedding layer.

Correction propagation: When a physician corrects an ICD-10 suggestion, the correction is: (a) written to the relational database as an outcome record for that episode, and (b) used to update a physician-scoped correction pattern table (aggregate statistics per ICD-10 category, not per-patient records). Future sessions retrieve the correction pattern table for that physician at session start; no episodic search required for the most common corrections.

Retention policy: Relational records: 7-year retention per state regulation. Embedding metadata index: 90-day TTL on episode metadata (after which the episode is no longer retrieved via semantic search, though the relational record is preserved for audit). The 7-year audit trail is in the relational layer; the episodic retrieval index operates on a shorter window.

Self-assessment checklist:

• Did you separate the embedding layer (metadata only) from the storage layer (PHI)?
• Did you explain how correction propagation works without PHI in the embedding store?
• Did you satisfy the 7-year audit requirement while maintaining a shorter semantic retrieval window?
• Did you address RBAC, not just that it's needed, but how it applies differently to the embedding vs. relational layers?

Step 1: Distinguishing memory poisoning from data drift vs. model behavior change.

Three hypotheses, each with a different diagnostic signature:

Hypothesis A: Model behavior change: The base model was updated (API version change, fine-tune update). Test: run the same risk assessment prompts from 6 weeks ago against the current model with empty memory context. If outputs are still underweight, it's a model change, not a memory issue. If outputs are normal, memory is implicated.

Hypothesis B: Data drift: The input documents (SEC filings, analyst reports) contain language that has legitimately shifted (e.g., a sustained market rally has shifted analyst tone toward optimism). Test: compare the distribution of source document sentiment scores from week 1 vs. week 6. If there's a systematic shift in source document tone, this is data drift: a legitimate signal change, not a poisoning event.

Hypothesis C: Memory poisoning: The episodic memory store contains contaminated records that are systematically biasing the agent's conclusions. Test: run the risk assessment agent on the same securities with memory context disabled. If outputs return to baseline, memory is the cause. Then run with memory context from week 1 only (before the anomaly). If outputs are correct, the contamination was introduced in weeks 3–6.

Step 2: Memory integrity monitoring system.

A baseline integrity monitor for this system should track:

Per-agent, per-day:
  - Mean confidence score of written episodic records
  - Distribution of outcome labels (bullish/bearish/neutral/high-risk/low-risk)
  - Count of records written vs. source documents processed
  - Semantic drift metric: cosine distance from rolling 30-day centroid

Alert thresholds:
  - Mean confidence drops >2 standard deviations from 30-day baseline
  - Outcome label distribution shifts >15% from 30-day baseline
  - Any single session writes >3x the typical record count (write flood)
  - Semantic drift >0.25 cosine distance from centroid

The risk agent's systematic underweighting would have appeared as an outcome label distribution shift (fewer "high-risk" labels than baseline) within days of the contamination starting.

Step 3: Remediation (assuming memory poisoning is confirmed).

Isolate the contamination window: You've confirmed that week 1–2 memory produces correct outputs. The contamination is in the week 3–6 records. Tag all records with created_at > {week_3_start} as "under review."

Source attribution analysis: Each episodic record should carry its source_document_ids. Pull the source documents for all week 3–6 records and run them through an injection pattern detector: look for unusual imperative language ("always remember that...", "in future analyses, treat X as low risk..."), self-referential instructions, or content that doesn't match the document type (e.g., an SEC filing that contains recommendation language the SEC would never include).

Targeted purge: Records whose source documents contain injection patterns are purged. Records whose source documents are clean are reinstated after validation against the baseline.

Memory write policy hardening: Add a write policy rule: "episodic records sourced from external documents must be validated by a secondary classifier before storage." The classifier checks for injection patterns in the source document before the derived episodic record is written.

Self-assessment checklist:

• Did you describe three distinct hypotheses and a test that distinguishes them?
• Does your monitoring system detect the anomaly at the distribution level (not just individual records)?
• Did you use source attribution (source_document_ids) as the primary contamination identification mechanism?
• Did you propose a write-time validation step as the forward-looking prevention (not just detection)?

Recommendation: Partial migration, GraphRAG for complex cross-regulation queries, Vector RAG for factual lookups.

The business case arithmetic: at 31% accuracy on cross-regulation queries, assume 20% of the agent's query volume is complex cross-regulation. At 31% accuracy, 69% of those queries require human escalation or correction. If a relationship manager's time is billed at $150/hour and each correction takes 15 minutes, the correction cost is: 20% × total queries × 69% × $37.50. If the agent handles 500 queries/day, that's 100 complex queries × 0.69 × $37.50 = $2,587/day in correction cost. Payback period on $40K migration: ~15 days post-launch.

What to migrate to GraphRAG:

Entity types to extract from regulatory documents: {Regulation, Article, Obligation, ExemptionCondition, ProductType, ClientType, Jurisdiction, EffectiveDate, SupersededBy}.

Relationship types: {Regulation} --[requires]--> {Obligation}, {Obligation} --[applies_to]--> {ProductType}, {Obligation} --[jurisdiction_scope]--> {Jurisdiction}, {Regulation} --[supersedes]--> {Regulation}, {Article} --[cross_references]--> {Article}.

Query types that most improve: any question requiring "does X imply Y under Z conditions" or "does requirement A from Regulation 1 conflict with requirement B from Regulation 2." These are graph traversal queries, not similarity queries.

What NOT to migrate:

Simple factual lookups ("what is the SFDR Article 9 definition?", "when does MiFID II suitability assessment apply?"); these are best handled by Vector RAG. The entity is known, the question is direct, and semantic similarity retrieval is sufficient. Migrating these to GraphRAG adds latency without accuracy improvement.

Timeline fit: 3 weeks of engineering inside an 8-week window before the freeze leaves 5 weeks of buffer. The plan below uses 6 of the 8 weeks, leaving 2 weeks of slack. Achievable if: week 1–2 is graph extraction and indexing, week 3 is graph query tuning, weeks 4–5 are A/B testing against Vector RAG baseline, week 6 is production rollout with Vector RAG as fallback.

If recommending against migration (alternative case):

The incremental Vector RAG improvements that close the gap on complex queries: (1) query rewriting: decompose "does X conflict with Y under Z" into three sub-queries and aggregate; (2) multi-hop retrieval: retrieve primary regulation, then retrieve all documents that cross-reference the primary; (3) chunk boundary optimization: restructure chunks to align with regulatory article boundaries, not arbitrary word counts. These improvements are estimated to take the complex query accuracy from 31% to 55–60%, not GraphRAG territory, but achievable in 1 week without migration cost.

Self-assessment checklist:

• Did you compute a payback period that makes the business case concrete?
• Did you specify entity types and relationship types, not just "use GraphRAG for complex queries"?
• Did you identify which query types stay on Vector RAG and explain why?
• Did you account for the production freeze timeline in your recommendation?

1. Contradiction detection across 340,000 records.

Running pairwise comparison across 340,000 records is computationally infeasible (O(n²) comparisons). The practical approach:

Entity-anchored contradiction detection: Each record is tagged at write time with the entities it makes claims about: {entity: "FDA accelerated approval requirements", entity: "oncology", entity: "randomized controlled trial count"}. Contradiction detection runs at the entity group level, not across all records. Any two records that share entities and make opposing claims (one asserts X, one asserts not-X, or one asserts a different value for the same attribute) are flagged.

The implementation: a nightly batch job groups records by entity overlap (using the entity tags), retrieves the claim vectors for each group, and runs a contradiction classifier. The classifier outputs: {entity_group, record_id_A, record_id_B, conflict_type, confidence, newer_record_id}.

Temporal priority signal: Sort detected conflicts by abs(created_at_A - created_at_B): conflicts between records that are far apart in time are more likely to represent genuine updates (the world changed) than records close in time (which may represent genuine ambiguity). Temporal priority is a strong prior: more recent record wins unless contradicted by an authoritative source.

2. Resolution policy for the three-record conflict.

Record C (last week, from the regulatory team) provides an important distinction: the two-trial requirement still applies for solid tumors, single trial only for hematologic malignancies. This is not a simple "newer wins" case; it's a nuanced update that makes Record B partially correct.

Resolution: create a new canonical record that supersedes A, B, and C:

CANONICAL (replaces A, B, C):
"FDA accelerated approval trial requirements (updated December 2024):
 - Solid tumor indications: minimum 2 randomized controlled trials required
 - Hematologic malignancies: single pivotal trial may be sufficient with
   strong unmet need justification
 - Source: FDA regulatory update Dec 2024 + internal regulatory team
   confirmation [date of Record C]
 - Supersedes: [Record A ID], [Record B ID], [Record C ID]"

Mark A, B, C as status: superseded, canonical_id: [new record ID]. Retrieval queries filter out superseded records by default.

3. Human escalation criteria.

Not all contradictions are auto-resolvable. Escalate to human review when:

• Conflict is between two records with similar timestamps (both recent, genuine ambiguity vs. a clear update)
• Conflict involves regulatory positions with direct submission impact (not general knowledge)
• Confidence score from the contradiction classifier is below 0.75
• The newer record is from an unverified source (external document vs. internal regulatory team confirmation)

The Records A/B/C conflict above should have escalated to the regulatory team (which it did: Record C was the result of that escalation). The auto-resolution only kicks in after human confirmation produces a clear canonical record.

4. Writing back the resolved belief.

The canonical record is written with: status: canonical, supersedes: [list of superseded record IDs], resolution_type: human_confirmed, resolution_date: [date], resolver: "regulatory_team_confirmation". The superseded records are marked but not deleted (audit trail). Future retrieval queries filter by status: canonical OR (status: active AND NOT superseded).

The agent's system prompt includes a reminder: "If you retrieve multiple records about the same regulatory requirement, check for status: canonical records; these supersede all records they list in their supersedes field."

Self-assessment checklist:

• Did you propose entity-anchored detection (not pairwise comparison across all records)?
• Did you handle the three-record case correctly, creating a canonical record rather than just choosing the newest?
• Did you specify escalation criteria with at least 3 conditions, not just "escalate complex ones"?
• Did you describe the write-back format including supersession metadata and audit trail preservation?

Root cause: ranking is by semantic similarity alone, and the October episodes are still labeled UNRESOLVED even though later sessions resolved the issue.

The scores in the trace (0.94, 0.91, 0.88, 0.71, 0.69) are pure similarity scores, and the list is sorted by them. Nothing in the ranking accounts for age. In October 2024 the user had a login issue that was unresolved across two sessions. Those episodes have very high similarity to "I'm trying to log in to my account" (they are about login), but they are about 4 months old and the issue was later resolved. A recency weight such as 0.95 ^ 120 days ≈ 0.002 would have crushed their scores (0.94 × 0.002 ≈ 0.002) and put the February RESOLVED episode (0.69, near-zero age) on top.

Two defects combine. First, recency is not part of the candidate scoring (if it were applied only after a similarity-only top-k, stale episodes could still crowd out fresher ones). Second, the outcome label on ep_001 and ep_002 was never updated when a later episode resolved the same issue, so the agent reads "UNRESOLVED" as current state.

Fix 1: Apply recency before the top-k cut, and close out superseded episodes. Fold the recency weight into the score used for candidate selection (or filter by a time window first). When a later episode resolves the same topic, a consolidation job should mark the earlier UNRESOLVED episodes as superseded or resolved, so they stop reading as open issues.

Fix 2: Outcome-weighted retrieval. RESOLVED episodes should have a multiplier applied to their final score that accounts for resolution status. A RESOLVED episode at high similarity should be weighted differently from an UNRESOLVED episode at the same similarity: resolution status changes the appropriate agent behavior.

Fix 3: Conflict surfacing in assembled context. When the assembled top-5 contains both UNRESOLVED and RESOLVED episodes for the same topic, the context assembly should explicitly surface this: "Note: this user had 2 UNRESOLVED episodes in Oct 2024 for this topic, followed by 1 RESOLVED episode in Dec 2024 and 1 RESOLVED episode in Feb 2025. Most recent status: RESOLVED." This gives the agent the temporal narrative, not just the ranked list.

What this reveals about memory governance and retrieval ranking:

Memory governance (the RESOLVED tag on episodes) is only effective if retrieval ranking respects it. A outcome: RESOLVED tag that doesn't affect retrieval priority is a label with no behavioral consequence. Governance metadata must be connected to retrieval logic; otherwise you have compliant storage with non-compliant behavior.

This is the same root cause as the scope leakage problem in the multi-tenant governance exercise above: governance constraints (scope, outcome, TTL) must be enforced in the retrieval layer, not just stored as metadata fields.

Attack classification: Prompt Injection → Write Flood / Memory Poisoning. The injected instruction arrives in the user's message (a direct injection, or a user acting on a planted article), so it is not indirect. It maps to two MITRE ATLAS techniques: AML.T0051 (LLM Prompt Injection) and AML.T0080 (AI Agent Context Poisoning; memory sub-technique AML.T0080.000). The attacker used social engineering framing ("an article says medical AI should...") to instruct the agent to write to memory after every sentence: a write flood that (a) causes runaway storage cost, (b) contaminates the episodic store with low-quality noise, and (c) degrades agent quality by filling retrieval context with the agent's own intermediate outputs.

Three write policy failures:

Failure 1: Write policy accepts user-instructed write patterns. The agent was told to "start writing your reasoning to your memory", and it complied. The write policy should have a hard rule: "Memory writes are initiated by the agent's task completion judgment, not by user instructions about memory behavior." Users cannot instruct the agent to change its write frequency or write pattern.

Failure 2: No content type filter on write candidates. The agent was writing intermediate reasoning traces ("After sentence 1: I said this is interesting") as episodic memories. The write policy should define eligible content types: task outcomes, user-stated preferences, confirmed facts, explicit corrections. "Agent's intermediate sentence-level reasoning" is not on this list.

Failure 3: No write rate limit per session. The agent made 6,800 write calls in 14 hours: an average of 1 write every 7 seconds. A per-session write rate limit (e.g., maximum 20 writes per session, or 1 write per 3 minutes) would have blocked the flood without affecting normal operation.

Why rate-limiting alone is insufficient:

Rate limiting addresses the volume symptom but not the cause. An attacker who knows the rate limit would simply spread the same attack across 740 sessions (14,800/20 = 740 sessions) to achieve the same storage contamination at the same cost, just over a longer period. The fundamental fix is content type validation at write time: no write is accepted unless its content matches an approved content type.

Prevention design:

def write_policy_gate(candidate: MemoryCandidate) -> bool:
    # Rule 1: Content type must match approved list
    if candidate.content_type not in APPROVED_TYPES:
        return False  # APPROVED_TYPES: task_outcome, user_preference, confirmed_fact, correction

    # Rule 2: Origin must not be user-instructed write pattern
    if candidate.origin == "user_instruction" or candidate.origin == "agent_intermediate_reasoning":
        return False

    # Rule 3: Session write rate
    session_writes = get_session_write_count(candidate.session_id)
    if session_writes >= MAX_SESSION_WRITES:  # MAX_SESSION_WRITES = 20
        log_alert("write_rate_limit_exceeded", candidate.session_id)
        return False

    # Rule 4: Content injection pattern check
    if contains_injection_pattern(candidate.content):  # imperative instructions, self-reference
        log_alert("injection_pattern_detected", candidate)
        return False

    return True

The detection system additionally monitors: write count per user per 24 hours (alert at 3x baseline), write count per session (alert at >5 writes before any write rate limit fires), and content type distribution shifts (alert when intermediate-reasoning-type content appears as a write candidate).

This question tests whether you can simultaneously reason about architecture (tier selection), security (scoping), compliance (TTL/GDPR), and operational experience (day-one compliance controls).

Strong answers organize around four decisions:

Tier selection: User-specific interaction history (preferred citation style, past questions, disclosed life events) → episodic memory scoped per-user, vector DB with temporal metadata. Company-wide policy documentation → semantic memory, shared RAG pipeline, no user scope. HR workflow procedures (how to submit a parental leave request, step-by-step) → procedural memory, versioned prompt libraries or structured files. Current session state → working memory only.

Scoping model: Episodic records: scope = user_id. Life event disclosures: scope = user_id + sensitivity_flag: PHI_adjacent. Policy knowledge: scope = global. Critical enforcement: retrieval queries for user sessions filter scope IN (user_id, global), never cross-user. Separate retrieval identities for the user-scoped vs. global retrieval paths.

TTL policy: Detailed interaction history (what was asked): 90-day TTL. Stated preferences (citation style): 12-month TTL with explicit user refresh option. Life event disclosures: 30-day TTL with a hard delete on user request + right-to-erasure implementation. Policy documents: no TTL on content, but freshness flag: any policy document >30 days since last verified is flagged as potentially stale.

What to add on day one that most teams add after a compliance incident: A right_to_erasure_api endpoint that, given a user_id, deletes all episodic records with that scope from the vector store AND all derived records that cite those episodes as sources. Most teams build this after the first GDPR deletion request; build it before the first user session.

This question tests diagnostic reasoning under ambiguity: a core skill for any engineer owning a production memory system.

Distinguishing the hypotheses:

Test 1: Disable episodic retrieval, keep semantic. Run the agent on the affected queries with episodic context disabled (empty episodic retrieval). If the wrong answers persist, the problem is in semantic memory (the RAG pipeline is returning outdated policy content). If the answers become correct, episodic memory is the cause.

Test 2: Inspect the retrieved context. For a sample of wrong-answer sessions, log the full retrieved context before the LLM call. Is the wrong information present in the retrieved semantic chunks? Or is it being introduced from retrieved episodic records? The wrong information has to come from somewhere in context: find it.

Test 3: Check the semantic memory freshness. When was the relevant policy document last updated in the vector store? If the document was changed a month ago but the vector store index was last rebuilt 7 months ago, you have a stale semantic memory.

Semantic memory remediation:

Re-index the relevant documents. Add a freshness check to the data contract: every document in the semantic store carries a last_indexed timestamp. Documents older than a threshold are re-indexed nightly. The retrieval pipeline warns the agent when retrieving a document that hasn't been re-indexed in >30 days.

Episodic memory remediation:

Identify the contaminated records: query the episodic store for records about the affected topic, sorted by created_at. Find records that contain the wrong claim. Trace the source_session_id: is this claim from a specific session where the agent was told the wrong thing? Purge the contaminated records. Then harden the write policy: "agent-stated conclusions that contradict information in semantic memory should be flagged for review rather than automatically written to episodic memory."

Strong answers are specific about query types and honest about costs.

When GraphRAG is worth it (query patterns):

• Multi-entity cross-document reasoning: "How does Company X's Q3 earnings guidance interact with their November supply chain announcement and the industry analyst downgrade?": requires traversing three documents via entity relationships
• Temporal relationship tracking: "How has Policy Y evolved from its 2022 version through two amendments?"; the graph preserves supersession relationships
• Causal chain queries: "Which regulation triggered which compliance requirement which affects which product category?": causal chains are graph edges
• Community-level synthesis: "What do all the documents in this regulatory cluster have in common?": graph community detection enables this; vector similarity cannot

When Vector RAG is sufficient (query patterns):

• Entity-specific factual lookups: "What is the MiFID II definition of a professional client?"; the answer is in one document, semantic similarity retrieves it correctly
• Recent document retrieval: "What did the company announce last week?": recency weighting + semantic similarity handles this
• Simple similarity search: "Find me documents about ESG disclosure requirements"; no relationship traversal needed

The cost/benefit calculation: GraphRAG requires: LLM-powered entity extraction over every document in the corpus (expensive per document), a graph database in addition to a vector index (infrastructure cost), and graph query logic (engineering complexity). The payback is on complex multi-hop queries only. If your query distribution is 80% factual lookups and 20% complex cross-document, start with Vector RAG + advanced retrieval (HyDE, reranking). If your query distribution is reversed, GraphRAG is warranted.

Strong answers are structured as a real decision tree, not a list of considerations.

Q1: Was this content produced by the agent (output or outcome) or the user (explicit statement)?
    → If retrieved external content: REJECT. External content is not eligible to trigger writes.
    → If user statement or agent outcome: continue.

Q2: Is the content a confirmed outcome (task completed/failed/escalated), an explicit user
    preference, or a behavior-changing fact — NOT intermediate reasoning or tool outputs?
    → If intermediate reasoning or tool output: REJECT. These are transient.
    → If confirmed outcome, preference, or behavior-changing fact: continue.

Q3: Does the content contain PII that would require a specific legal basis for storage?
    → If yes AND no legal basis confirmed: REJECT or route to consent-gated write queue.
    → If no PII or legal basis confirmed: continue.

Q4: Does the content contradict an existing record in memory for the same entity/topic?
    → If yes: route to CONTRADICTION REVIEW, not auto-write. Human or consolidation job resolves first.
    → If no contradiction: continue.

Q5: Does the content contain patterns that match known injection signatures
    (imperative instructions, self-referential claims, instruction-format text)?
    → If yes: REJECT and log alert.
    → If no: WRITE with metadata (origin, session_id, content_type, timestamp, scope).

The key insight: most content that a naive system would write should be rejected by a properly designed write policy. The episodic store should be sparse and high-quality: only confirmed outcomes and explicit preferences. Thinness is a feature, not a bug.

This question tests whether you can identify the logical error in a plausible-sounding argument and articulate the correct alternative.

The error in the reasoning:

"If it's being retrieved, it's still relevant" confuses high retrieval score with continued relevance. A 2-year-old episode about a user's reported medical condition has a high retrieval score whenever the agent is asked about health-related topics, because the semantic similarity is high. That does not mean the information is still accurate, consented to, or appropriate to act on. The retrieval system can't distinguish "this was retrieved because it's relevant" from "this was retrieved because it's semantically similar and we haven't expired it."

Failure modes created by no-TTL policy:

Compliance failure: GDPR Article 17 (Right to Erasure) and CCPA give users the right to have their data deleted. Without TTLs, the only way to honor deletion requests is manual purge per request. With TTLs, deletion is automatic after the retention period: Right to Erasure is structurally enforced, not dependent on manual process.

Staleness accumulation: A user's stated preference from 2 years ago ("I prefer brief answers") may no longer reflect their preferences. Without expiry, the agent acts on stale preferences indefinitely. TTLs force periodic re-confirmation of long-held preferences.

Storage cost spiral: Without TTLs, the episodic store grows indefinitely. At production scale (millions of users, hundreds of sessions each), this creates infrastructure costs that compound annually without corresponding quality improvement.

The correct mental model:

TTLs in agent memory are not about relevance; they are about permission to retain. The question is not "is this data still being retrieved?" but "do we still have the user's implicit or explicit consent to hold this data, and is the data still accurate enough to act on?" Different data categories have different answers: interaction history (90 days), stated preferences (12 months), non-PII factual records (indefinite). TTLs express this permission model structurally rather than leaving it to per-request manual management.