Agent memory stops being a session trick and becomes infrastructure

Memory that survives the session

AgentMail now integrates with HydraDB, an open-source graph database, to give AI agents persistent memory for their inbox, the company says. A connector copies the email in an AgentMail inbox into a HydraDB database, storing the subject and body text plus sender, recipients, labels and attachment names and types for each message. Messages are keyed on their RFC Message-ID, so running the sync again updates a message instead of duplicating it, and reply links still connect when a parent and its reply arrive in different sync runs. For real-time memory, the integration ingests each email as it arrives through webhooks on message-received and message-sent events. m:…9339

The point is recall by meaning rather than by subject line: an agent can ask what discount a customer got and find the thread, and synced email is searched alongside any other app sources in the database by default. Memory can be scoped with a collection variable, so each agent or customer gets its own sub-tenant scope when many share one database. The setup needs an AgentMail account with an API key, a HydraDB account with an API key and a target database, and Python 3.9 or later. What used to be a session's context window is now a database an agent can query after the session ends. m:…9339

Memory with a schema

Oracle's developer blog describes the same idea with a database underneath. Mem0 Python can use Oracle AI Database as the durable vector store for application memory, with an Oracle provider connecting the Mem0 API to the storage layer. Each memory is stored as a row in an Oracle table, with the embedding in a vector column and the memory text plus metadata inside a JSON payload, and the application can add memories, search them later, filter on metadata, update and delete records, and inspect what was persisted. The tutorial was verified with mem0ai version 2.1.0 and uses a deterministic local embedder for the run. m:…6880

The design treats memory as a curated record, not a transcript. Application memory should be searchable, scoped, updated and deleted, the post argues, and retrieval scope is the first relevance boundary: before asking whether a memory is semantically relevant, the application narrows the search to the records belonging to the current user, agent, tenant, project or workflow. Update and delete operations keep memory aligned with the current state instead of treating every stored record as permanent truth, and separating memory operations from model calls reduces prompt noise. The notebook stores provided text directly as memory, avoiding external language-model extraction calls. One rule the post stresses: the embedding dimension in the Mem0 configuration must match the embedding model, or the storage path fails. m:…6880

Memory written into the model

Two preprints take memory inside the model itself. The first introduces test-time model-based reinforcement learning, a method that uses gradient descent during test time to encode episode-specific observations into a world model's parameters. The authors report state-of-the-art results on the Memory Maze 3D benchmark while maintaining performance parity on non-memory benchmarks such as DeepMind Control and Atari 100k — memory, in other words, without giving up general control. The second preprint builds an autoregressive diffusion world model that simulates environment responses, treating transitions as independent denoising steps to avoid the compounding errors of traditional autoregressive models, and reports accurate value estimation for language-model agents purely from pre-collected trajectories. m:…1187 m:…1201

A third preprint asks how to control memory once it persists. Jacobian-causal memory control represents authorized memory interventions through predicted influence signatures in a shared behavioral measurement space, gives a quadratic local-approximation bound for interventions under explicit smoothness and bounded-estimation assumptions, and includes a rollback mechanism that compares predicted against observed effects. The paper also defines an evaluation protocol comparing its approach against relevance, graph and policy-filtered retrieval baselines. It reports no benchmark measurements and provides no code or implementation artifacts, so it is a framework and a protocol, not a result. m:…5113

Why durability changes the design

The common thread is that memory is acquiring the properties of infrastructure: persistence, scope, lifecycle and rollback. An inbox that remembers across sessions, a vector store that scopes recall to one customer and deletes stale records, a world model that carries an episode in its weights, a control framework that can undo a bad intervention. The implication for developers is that memory stops being a prompt-engineering trick and becomes a component with the same questions as any other data store: who can read it, how long does it live, and how do you take it back. The teams building that component now will decide what agents remember — and what they are allowed to forget. m:…9339 m:…6880 m:…5113