Memory Types and Persistent Memory with Lakebase

What it is

An agent's memory is any information it brings back into the context window that was not in the current request. Memory comes in different scopes, and each scope belongs in a different store.

The exam tests two skills: spotting when an agent reads from the wrong memory for the need, and knowing which durable store (a Delta table or Lakebase) the state must live in so it survives the run.

How it works

The memory types

Long-term memory is usually distilled from sessions rather than copied from them whole.

Spotting the mismatch

The mismatch runs in two directions, and the symptom tells you which.

Delta-backed state versus an in-context scratchpad

A scratchpad is notes the agent keeps in its own context. It is cheap, but it disappears on a restart or a compaction, and nobody outside the run can read it.

A Delta-backed state object is required when any of these holds:

• The task spans several runs, jobs or days, and a later run must continue where the last stopped.
• Other agents, jobs or people must read the state, or audit it later.
• The state is exact data (processed record IDs, counts, approval flags) that a summary must not blur.
• A crash or compaction would otherwise lose work and cause repeated or skipped steps.

For a short, single-run reasoning chain, a scratchpad is fine. Worked case: a job reconciles 40,000 invoices in batches of 2,000 and fails at batch 13. With progress only in context, the next run cannot tell what finished; a Delta table of completed batch IDs lets it resume at batch 13.

Persistent session memory with Lakebase

Lakebase is the Databricks managed Postgres (OLTP) database, built for low-latency lookups of agent state. With LangGraph, a checkpointer saves the graph state after each step, and passing the same thread ID resumes the conversation after an interruption.

In an async agent, use LangGraph's AsyncPostgresSaver with an async connection pool to the Lakebase instance, await setup() once to create the checkpoint tables, and pass the saver to compile.

from langgraph.checkpoint.postgres.aio import AsyncPostgresSaver
checkpointer = AsyncPostgresSaver(pool)
await checkpointer.setup()
graph = builder.compile(checkpointer=checkpointer)
config = {"configurable": {"thread_id": "case-4812"}}
await graph.ainvoke({"messages": [user_msg]}, config)

The databricks_langchain package also offers a Lakebase-backed CheckpointSaver used with an instance name. Newer Databricks docs describe managed agent sessions and agent memory stores, both backed by Lakebase, with memory pipelines that distill durable facts from sessions into memory.

How the exam asks about this

• "Mid-conversation the user changes the delivery city, but the agent keeps using the city saved in its profile memory." The fact is in the current session; read session history before long-term memory.
• "A multi-day data migration agent repeats batches after every restart." Keep progress in a Delta-backed state table, not a scratchpad.
• "An async LangGraph agent must resume threads stored in Lakebase." AsyncPostgresSaver with the async pool, await setup(), then compile(checkpointer=...) and the same thread_id.