Fixed Replay vs. Agent-Driven Recall in Lakebase Sessions and Memory

1.Sessions: a fixed replay at the start of every turn

Managed agent sessions store session state in Lakebase. Most often that state is conversation history: "the ordered transcript of messages, tool calls, and results that an agent reads at the start of a turn and appends to as it runs." The read happens in the framework's run loop, before the model reasons about anything. It is a fixed step, not something the model chooses.

The docs describe it as a direct mapping from framework operations to store calls. The history comes back complete and in order ("the service maintains a deterministic order for a session's items"), so each turn rebuilds the same context it had before, plus the new items. For conversational continuity, that is the property you want: a follow-up question needs the earlier turns every time, not only when the model happens to think of fetching them.

Sources1

2.Memory: an index you list, or a query you search

Managed agent memory solves a different problem. It holds "durable facts, preferences, and decisions that an agent recalls in later, separate conversations." Memories are tied to a subject rather than to one conversation, and the agent "recalls them whenever they are relevant, regardless of which conversation surfaced them." You cannot know ahead of time which past facts a new conversation will need, so recall from memory is query-driven in a way that session replay is not.

The store gives you two read operations, and they serve different purposes. List returns an actor's entries, "optionally filtered by session_id or a path prefix", and the docs position it for browsing: "Use this to browse or render an index of what an agent knows." Search takes a natural-language query and "returns the most relevant entries ranked by a full-text (BM25) relevance score."

A query-based search is not automatically dynamic retrieval. The getting-started sample has application code call search with a fixed query ("communication preferences") in a later conversation, so developer code chooses both the moment and the query. Retrieval becomes dynamic only when the model gets to make that call itself, which is the subject of the next section.

Sources23

3.Handing recall to the agent, but not the identity

To make memory retrieval dynamic, the docs give a specific recipe: "To let an agent decide when to save and recall memory, wrap the client operations as tools and instruct the agent on when to use them in its system prompt." The example below wraps the store's search and add calls as OpenAI Agents SDK function tools. Now the model writes the query, and it decides whether to call the tool at all. The docs note that the same pattern works with the Claude Agent SDK and other frameworks.

Look at what the model does not control. actor_id is a parameter of make_memory_tools, bound by the application when it builds the tools. It is not an argument the model fills in. That is deliberate: "Set the actor_id in trusted application code from the verified end-user identity. Never let the model choose whose memory to read or write." Dynamic retrieval moves the decision about *when* and *what* to the model. The question of *whose* memory stays fixed in code.

def make_memory_tools(memory_store, actor_id: str):
    @function_tool
    def search_memory(query: str) -> str:
        """Search long-term memory for relevant facts about the user."""
        results = memory_store.search(actor_id=actor_id, query=query, limit=10)
        return "\n\n".join(f"{r.memory.path}: {r.memory.content}" for r in results) or "No memory found."

    @function_tool
    def save_memory(path: str, content: str, description: str = "") -> str:
        """Save a durable, long-term memory about the user."""
        memory_store.add(actor_id=actor_id, path=path, content=content, description=description)
        return f"Saved memory at {path}"

    return [search_memory, save_memory]

agent = Agent(
    name="Support agent",
    instructions="Save durable user preferences and recall them when relevant.",
    tools=make_memory_tools(memory_store,  ? ="user-123"),
)

Sources2

4.Combining fixed replay and dynamic recall

These are not either-or choices. One agent usually mixes both styles, one per store. The docs recommend: "Use both together for most use cases: sessions give the agent continuity within a conversation, and memory gives it continuity across conversations." The two stores are linked by a write path, not a read path: "As a session accumulates, an agent (or your application) distills the durable facts out of it and writes them to memory." Either store also works alone: "Use sessions alone when you only need in-interaction state, or memory alone when your framework already manages session state."

Once you know the architecture, the choice follows. A deterministic chain fits a fixed history read plus memory recall run by application code. A single tool-calling agent can keep the fixed history read and add memory as a tool, taking on the tool-call guardrails that come with it.

Sources3

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.With dynamic retrieval the model decides everything about a memory lookup, including which user's memories to search.Why is that wrong?

   The model decides when to call the tool and what to search for. actor_id is always set in trusted application code from the verified identity.

   Covered in Handing recall to the agent, but not the identity

2. 2.Conversation history in a managed session is retrieved by relevance search, like long-term memory.Why is that wrong?

   Session items are kept in a deterministic order and read back chronologically at the start of a run. Relevance search is the memory store's operation.

   Covered in Sessions: a fixed replay at the start of every turn