Day 3 · Synthesis Checkpoint
No new ideas. A retrieval workout, the kind that makes it stick.
Day 3 had one spine: context is assembled fresh each turn, from a session (the now) and memory (across time), and both are personal data you must curate and protect. Rebuild it from memory before revealing. The struggle is the learning.
Five lessons, one progression. Recall each core idea, then check.
CONTEXT LOOP (L1) stateless model → assemble context every turn
(fetch→prepare→invoke→upload); enemy = context rot
SESSIONS (L2) the "now": events + state; stateless runtime → persist;
compact (keep-N / truncate / summarize); strict isolation + PII
MEMORY vs RAG(L3) RAG = expert on facts (shared); memory = expert on the
USER (isolated); declarative (what) vs procedural (how)
GENERATION (L4) LLM-driven ETL: extract (by topic) → consolidate
(merge/update/delete + forget); provenance = trust; async
RETRIEVAL/RISK(L5)score relevance+recency+importance; place in prompt vs
history; risks: isolation, poisoning, exfiltrationThe through-line: session and memory are the two engines that beat context rot (one for the conversation, one across conversations), and both are regulated personal data.
Recall the workbench/filing-cabinet split and why each exists.
Session = the workbench: one conversation's events + state, temporary, on the hot path, strictly isolated per user. Memory = the filing cabinet: extracted, consolidated facts persisted across sessions, curated by an LLM-driven ETL, run async.
Symbiosis: sessions are the raw source memories are generated from; memory is a key way to compact sessions. Session compaction and memory generation are the same move, distilling signal from a noisy transcript.
Shuffled across the day, with links to Days 1–2. Pick before you're sure.
Context must be assembled every turn because the model is —
L1. Statelessness: persistence lives outside the model, in sessions and memory.
The most emphatic session security rule is —
L2. ACL isolation + PII redaction: one user must never reach another's session.
Memory makes an agent an expert on —
L3. Memory = personal assistant (the user); RAG = research librarian (world facts).
The self-editing stage that merges, updates, and deletes memories is —
L4. Consolidation reconciles new info with old, and forgets the stale. Memory's core value.
Ranking memories on similarity alone surfaces —
L5. Blend relevance + recency + importance; similarity alone pulls conceptually-close-but-old memories.
A user injecting false facts to corrupt persistent memory is —
L5. Memory poisoning: sanitise/validate before committing to memory. (Day 2's prompt-injection thinking, applied to knowledge.)
Expensive memory generation should run —
L1/L4. Background/async: it's the "upload" step; blocking would stall the user.
The Day-3 reflex on a fresh case. Answer before revealing.
Remember (memory, not RAG): per-user facts: order numbers, past issues, preferences. Define topic definitions so "meaningful" is explicit; product specs stay in RAG. Generate async at session end; consolidate to avoid duplicate/stale tickets.
Retrieve: blend relevance + recency + importance; put a stable profile in the system prompt, pull episodic issue-history into the turn. Keep it under the hot-path latency budget.
Three risks: (1) isolation: ACLs so user A never sees user B's history; (2) poisoning: sanitise before commit so a user can't plant false account facts; (3) exfiltration: anonymise anything shared app-wide. Plus PII redaction throughout.
Name these cold and Day 3 has done its job.
Design the context a stateful agent needs turn by turn; split session vs memory vs RAG correctly; build a memory pipeline that extracts, consolidates, and forgets; retrieve and place memories well; and name the isolation, poisoning, and exfiltration risks with their controls. That's Day 3, met.
Day 3 consolidated. ✓ Context is assembled, sessions hold the now, memory holds the user, all curated, all protected.
Up next → Day 4, Agent Security & Evaluation: the densest governance overlap of the series, where Google's 7-pillar security model lines up almost one-to-one with your VERDICT framework.