In one paragraph

Agents lose state when a session ends unless something captures and restores it. The problem is addressed from several angles: a 426-token prompt script that appends to a flat log, a DynamoDB backend that snapshots sessions and can offload large values to S3, a virtual filesystem that organizes memory as browsable URI-addressed files, a normalizer that converts transcripts from 15 runtimes into one validated schema, and a research model that writes directly to its own context window to cut compute. What counts here: libraries, stores and models that give agents memory, managed context or durable state across sessions.

The main approaches

Memory prompts and scripts

A small prompt instructs the agent how to read and write its own memory using shell-like commands. No server, no embeddings, no cloud account. OptMem does this with a 426-token prompt and two local files.

Storage backends

A library wires an existing storage service into an agent SDK so sessions, memory, and context persist across turns. strands-dynamodb-storage maps the Strands Agents SDK’s storage interface onto DynamoDB, with optional S3 offload for large values.

Context databases

A server organizes all agent context into a typed, addressable structure the agent can search and browse. OpenViking stores resources, memories, and skills under viking:// URIs with scoped semantic search.

Session trajectories

A library parses raw session transcripts from multiple runtimes into a single validated schema for training, evaluation, and inference. trajectory supports 15 agent runtimes and produces a records array with a fixed role taxonomy.

Context models

A research approach trains or prompts a model to manage its own context window as a writable file, trading context rewriting for lower FLOPs. context-language-models reports, for the zero-shot version, 21.5% fewer FLOPs with 11.4% higher accuracy on BrowseComp-Plus.

Map of the theme

flowchart LR
  t["Agent memory and context"]
  t --> f1["Memory prompts and scripts"]
  t --> f2["Storage backends"]
  t --> f3["Context databases"]
  t --> f4["Context models"]
  t --> f5["Session trajectories"]
  f1 --> r1["VictorTaelin/OptMem"]
  f2 --> r2["aws/strands-dynamodb-storage"]
  f3 --> r3["volcengine/OpenViking"]
  f4 --> r4["facebookresearch/context-language-models"]
  f5 --> r5["letta-ai/trajectory"]

Where the new ideas are

context-language-models proposes that the model itself should edit the context window, with online RL and evolved natural-language instructions to improve that behavior. The zero-shot results (up to 65% more improvement at equal compute on a multi-repo swarm task) are the most concrete evidence that context management can live in the model, not just in a storage layer.

OptMem uses fixed-width append-only lines so position is identity and every lookup is a single file seek, which makes a binary summary tree navigable with no database at all.

OpenViking adds three-tier summaries (abstract, overview, full content) so an agent can judge relevance before committing to reading a full document, reducing unnecessary context load.

Side by side

Repo	Approach	Storage medium	Session persistence	Semantic search	Multi-runtime support
volcengine/OpenViking	Context database	Server-side filesystem under viking:// URIs	Yes, via session commit and memory extraction	Yes, scoped to path	Yes, integrations for Claude Code, Codex, Cursor, TRAE, OpenCode, LangChain and others
letta-ai/trajectory	Session trajectories	Schema-validated in-memory records array	Not stated	Not stated	Yes, 15 runtimes
VictorTaelin/OptMem	Memory prompts and scripts	Local append-only flat text log	Yes, log persists across sessions	No, regex search only	Yes, agents that read AGENTS.md or CLAUDE.md
aws/strands-dynamodb-storage	Storage backends	DynamoDB, with optional S3 offload for oversized values	Yes, snapshot and reload per turn	Optional, via DynamoDB vector indexes	Not stated
facebookresearch/context-language-models	Context models	Model’s own context window	Not stated	Not stated	Not stated

How the idea moved

flowchart LR
  n1["started Jan 2026<br/>volcengine/OpenViking"]
  n2["started Jul 2026<br/>letta-ai/trajectory"]
  n3["started Jul 2026<br/>VictorTaelin/OptMem"]
  n4["started Aug 2026<br/>aws/strands-dynamodb-storage"]
  n5["started Sep 2026<br/>facebookresearch/context-language-models"]
  n1 --> n2 --> n3 --> n4 --> n5

• started Jan 2026 · OpenViking · Adds: Organizes agent memory, knowledge, and skills as a browsable viking:// filesystem with three-tier summaries and scoped semantic search, reaching 80–83% accuracy on the LoCoMo long-conversation benchmark across three agent integrations, versus 24–57% on their native memory.
• started Jul 2026 · trajectory · Adds: Normalizes session transcripts from 15 agent runtimes into one schema-validated records array with stable tool-call IDs and a listTrajectories function for discovering local session stores.
• started Jul 2026 · OptMem · Adds: Gives any agent cross-session memory through a 426-token prompt and a local append-only log with a binary summary tree, requiring no server, database, or cloud account.
• started Aug 2026 · strands-dynamodb-storage · Adds: Maps the Strands Agents SDK’s storage interface onto DynamoDB with optional TTL expiry, optional vector search via DynamoDB vector indexes, and opt-in S3 offload for values that exceed DynamoDB’s item-size limit.
• started Sep 2026 · context-language-models · Adds: Treats the context window as a writable file that the model manages itself, zero-shot or steered by evolved natural-language instructions or online RL, reporting 21.5% fewer FLOPs with 11.4% higher accuracy on BrowseComp-Plus for the zero-shot version.

Easily confused

This theme might be confused with general RAG pipelines or vector database libraries. The difference is scope: RAG pipelines retrieve documents to answer a query and stop there. The approaches here keep or prepare state that belongs to a specific agent, such as its memories, its own context window or its session records, rather than just fetching relevant documents on demand. Some tools (OpenViking) do include RAG-style retrieval, but it serves the agent’s ongoing memory, not a one-shot question-answering task.

Gaps nobody has filled

• No approach here reports how retrieval quality changes as stored memory grows or ages. OpenViking reports one LoCoMo accuracy figure per integration, and OptMem reports lookup time at a million memories.
• No approach here isolates summary quality: OpenViking reports end-to-end accuracy and token savings, but no repo has a metric for whether tree nodes or three-tier abstracts keep the facts an agent needs.