Day 3 · Lesson 2 — Context Engineering: Sessions & Memory

Sessions: The Workbench

The "now" of a conversation, and how to keep it from rotting.

A session is the container for a single conversation: its history and its working memory. Simple in theory, until you hit a stateless runtime, a growing token bill, and a hard rule that one user's data must never touch another's. This lesson is the workbench and how to keep it tidy.

Recall first (spacing)

From Lesson 1: the session is the workbench; what's the filing cabinet?

The system prompt
Long-term memory
The vector database

Memory, curated knowledge across sessions. The session is temporary and task-specific; this lesson is all about managing that temporary desk well.

What a session is: events + state

Every session is tied to one user and holds two things:¹

Events — the chronological history: user input, agent response, tool call, tool output. The append-only transcript.
State — a structured "scratchpad" of working data for the current task (e.g. what's in the shopping cart). The agent mutates it as it reasons.

A production runtime is stateless; it keeps nothing after a request. So the session must be saved to a database and reloaded at the start of every turn. That reload is on the hot path, which makes session performance a first-class concern.¹

Keeping the workbench from rotting: compaction

As the conversation grows, the history sent each turn balloons, hitting context-window limits, cost, latency, and context rot. Compaction trims it while preserving what matters. Three strategies, simplest to smartest:¹

KEEP LAST N       sliding window: keep the most recent N turns, drop the rest
TOKEN TRUNCATION  add messages newest-first until a token budget is hit
RECURSIVE SUMMARY older turns replaced by an LLM-generated summary, prefixed
                  to the recent verbatim messages   (expensive → run in background)

And you must decide when to compact, the trigger:

Count-based — over a token/turn threshold ("good enough" for most).
Time-based — after a lull in activity.
Event-based — when a task or topic concludes (semantic).

Compaction is really memory generation applied to one session, distilling the transcript into key facts. That's the bridge to Lesson 3.

Multi-agent: one desk, or many?

When several agents collaborate, the architecture must decide how they share history:¹

Shared, unified history — all agents read/write one log. Best for tightly coupled tasks with a single source of truth.
Separate, individual histories — each agent is a black box; only final outputs are shared (via agent-as-a-tool or A2A). Best for loose coupling.

A wrinkle worth knowing: because each framework couples its session schema to its own objects, an ADK agent can't natively read a LangGraph session. True cross-framework sharing needs a framework-agnostic layer, memory (Lesson 3), which stores processed facts, not raw events.

The governance layer, on sessions

Governance overlay · Day 3 Lesson 2

A session is user data — isolation is non-negotiable

The paper's most emphatic security rule: strict isolation. A session belongs to one user; the store must enforce that one user can never reach another's data (ACLs, authn/authz on every request). That's I Identity + C Compliance. Best practice: redact PII before it's ever persisted, shrinking the breach blast radius (C). And per-agent cryptographic identity (SPIFFE IDs) on every session-driven call yields an auditable trail (E Evidence).

Ladder read: deterministic event ordering + TTL retention policies + isolation are exactly the L3 Controlled disciplines. A session store without ACLs and PII redaction is a data-leak waiting at L1.

Through your three lenses

Individual (IC)

Pick a compaction strategy on purpose (keep-N is fine to start) and run summarisation in the background. Never leave the full transcript growing unbounded into the context window.

Team

For multi-agent work, decide shared vs separate history deliberately; it shapes coupling and debuggability. And agree a session retention (TTL) policy as a team norm.

Organisation

Mandate strict per-user isolation + PII redaction before persistence as a platform requirement, with a managed session store on the hot path. This is a compliance line, not an optimisation.

Check the reflex

Recall, don't re-read.

A session's two components are —

Vectors and embeddings
Prompts and completions
Events and state

Events = the chronological transcript (user/agent/tool); state = the working scratchpad the agent mutates. Both scoped to one conversation, one user.

The most emphatic session security rule is —

Strict per-user isolation
Always use a graph database
Never compact history

Isolation via ACLs + authn/authz: one user must never reach another's session. Plus redact PII before persisting. Identity and compliance, enforced.

Replacing older turns with an LLM-generated digest is —

Token truncation
Recursive summarization
Strict isolation

Recursive summarization is the smartest and priciest option, so run it in the background. Keep-N and token truncation just drop old messages; summarization preserves their gist.

Carry this into the week

Answer two questions for one agent: what happens to its history at turn 500? (compaction or crash?) and could user A ever see user B's session? (isolation or incident?). Both have to have crisp answers before production.

Go deeper (primary source)

Context Engineering (Day 3), "Sessions" pp.12–26; the ADK docs show the compaction plugins (ContextFilterPlugin, EventsCompactionConfig) in practice.

Notes

Milam, Gulli & Nawalgaria, Context Engineering: Sessions, Memory (Day 3), "Sessions" pp.12–26 (events & state; production considerations; compaction strategies & triggers; multi-agent history).

Up next → Day 3 · Lesson 3: Memory vs RAG — the filing cabinet. Why memory makes an agent an expert on the user while RAG makes it an expert on facts, and the declarative-vs-procedural split.