Lakebase Memory Retrieval: AI Search vs Structured Queries

1.Two ways to read a memory back

Once an agent has stored memories in Lakebase, it needs a way to get them back. Databricks keeps two kinds of agent state there. Session state is the transcript of a single interaction, and the agent loads it by the session's ID. Memory is the set of durable facts that should still matter in a later conversation that has nothing to do with this one. Sessions are a keyed read: the agent "reads it at the start of a turn and appends to it as the interaction runs." Nothing gets ranked, because the thread ID already identifies the right state. Memory is different. The agent "recalls them whenever they are relevant, regardless of which conversation surfaced them." Here the agent knows the topic, but not where the fact was stored.

Managed agent memory, which Databricks stores in Lakebase, offers both styles of retrieval. Each memory entry has an actor_id (whose memory it is), an optional session_id (where it was captured), and a required filesystem-style path such as /preferences/response-style.md. Together those three fields uniquely identify the entry. On top of this, the store exposes two read operations: list, which filters on the known fields, and search, which takes a natural-language query.

The two operations answer different questions. List returns the entries for an actor, optionally narrowed by session_id or a path prefix, and the docs suggest using it "to browse or render an index of what an agent knows." It is a structured query: the fields to filter on are part of the request. Search returns entries ranked by relevance to free text, scored with BM25. That fact matters later in this lesson. A memory search ranks by the words it shares with the stored text and description, not by embedding distance. This is why each entry's description is described as improving retrieval: the description adds words the query can match.

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."

Look at what this code fixes and what it leaves open. actor_id is passed in when the tools are built, and the model never chooses it. The docs say to set it "in trusted application code from the verified end-user identity." This is the pattern used even when the retrieval is a search: the structured part (whose memory) is set by the application, and only the open-ended part (what about) goes to relevance ranking.

Sources12

2.Structured query retrieval: when the agent already knows the key

The managed memory API is one case of a general rule. Some memories are records with typed columns: an account's tier, a decision tied to a ticket ID, the last order a user placed. Questions about them are lookups, filters or aggregates, so SQL answers them exactly. A Lakebase database can be registered in Unity Catalog "for unified governance and cross-source queries", and Databricks provides several tools that let agents query Unity Catalog tables.

The most deterministic option is a Unity Catalog function. The docs say to use one "when the query is known ahead of time and the agent provides the parameters." The function below takes a single input, filters a table with an equality WHERE clause, and returns at most one row. No ranking or embedding is involved: the agent gets the exact record or nothing.

CREATE OR REPLACE FUNCTION main.default.lookup_customer_info(
  customer_name_input STRING COMMENT 'Name of the customer whose info to look up'
)
RETURNS STRING
COMMENT 'Returns metadata about a particular customer, given the customer''s name, including the customer''s email and ID. The
customer ID can be used for other queries.'
RETURN SELECT CONCAT(
    'Customer ID: ', customer_id, ', ',
    'Customer Email: ', customer_email
  )
  FROM main.default.customer_data
  WHERE customer_name = customer_name_input
  LIMIT 1;

Note that "natural language" does not mean "use AI Search". Genie accepts plain-English questions, but it answers them by querying tables, so it is still structured retrieval. Questions like "What were the top 10 customers by revenue last quarter?" need the query to be computed (sort, aggregate, filter by date). Returning text that sounds similar would not answer them. So the deciding question is not whether the user typed English. It is whether the answer is a precise selection from records.

Sources34

3.Databricks AI Search: when the agent only knows what the memory is about

Structured retrieval fails when the agent cannot name the key. Suppose a user says "remember how I wanted those reports formatted?" The stored memory might say "prefers bullet summaries, no tables". The agent has no ID or path, and the two phrasings share almost no words. This is the problem Databricks AI Search (formerly Vector Search) addresses: it returns relevant rows "by finding the embeddings most similar to a query." Embeddings capture the meaning of text, so a paraphrase can still be retrieved.

AI Search supports more than one query mode, and the right one depends on how the query is worded. Pure similarity search handles paraphrase but can miss exact tokens. The docs recommend hybrid search for source data that contains "unique keywords such as SKUs or identifiers that are not well suited to pure similarity search." Hybrid search combines the vector results and the BM25 keyword results with Reciprocal Rank Fusion. For queries that are purely exact terms, full-text (BM25) search needs no embeddings at all. AI Search also supports filtering, so a search can be limited to structured attributes, for example one user's rows, before ranking.

Sources5

4.Memories live in Postgres, AI Search indexes read lakehouse tables

There is a practical limit here that exam scenarios can test. An AI Search index is built from a source table, which must be "a Delta Lake table, streaming table, or managed table using Iceberg v3 or above." A Lakebase Postgres table is none of these. If memories are written to Lakebase and the agent needs semantic recall over them, there are two documented options.

Option 1: search inside Lakebase. Lakebase Search "adds hybrid vector and keyword search to Lakebase projects" through Postgres extensions. lakebase_vector adds an approximate nearest-neighbour index type (lakebase_ann) that is compatible with pgvector. lakebase_text adds BM25 indexes (lakebase_bm25). The same decision rule applies: use vector search for natural-language questions, keyword search for "names, codes, and exact-term lookups where wording matters", and hybrid search when a query mixes the two. A benefit of this option is that the memory row, its structured columns and its search index all live in one database. One detail to note: BM25 builds corpus statistics when the index is created, "not incrementally".

-- Vector similarity search
SELECT id, title
FROM documents
ORDER BY embedding <=> '[0.1, 0.2, 0.3]'
LIMIT 5;

-- BM25 keyword search (lower score = more relevant)
SELECT id, title,
  body_tsv <@> to_bm25query(to_tsvector('english', 'database'), 'documents_body_bm25') AS score
FROM documents
ORDER BY score
LIMIT 5;

-- Create a vector search index
CREATE INDEX documents_embedding_idx ON documents
  USING  ?  (embedding vector_cosine_ops);

Option 2: move the data to the lakehouse first. Lakebase Change Data Feed captures every insert, update and delete, and each change is "stored as a new row in a Unity Catalog managed Delta table, batched and flushed every ~15 seconds." These Delta tables hold change history, with one row per change, not the current state of each memory. The sources provided here do not describe an end-to-end pipeline from Lakebase memory to an AI Search index. Treat that bridge as something you would design yourself, not as a documented pattern.

Sources567

5.Deciding from the query type

On the exam, a scenario usually gives you a memory store and one specific question the agent must answer. Work through it in order. First, can the agent name the record by actor, session, path, ID or another typed column? If so, use a structured query. Second, does the answer require computation over records (counts, ranges, latest, top-N)? That is also a structured query, through SQL or Genie, even if the question is phrased in English. Third, does the agent know only the topic? Then use ranked search, and choose vector search for paraphrase, keyword search for exact tokens, or hybrid for a mix. Fourth, where does the data live? Lakebase Search ranks rows inside Postgres, while AI Search indexes lakehouse tables. Many real requests combine these. The usual pattern is to fix the structured part (whose memory) in application code and run the search only over that subset.

Sources62

Exam traps

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

1. 1.Managed agent memory's search operation finds entries by embedding (vector) similarity.Why is that wrong?

   Managed memory search ranks entries by a full-text BM25 relevance score. It matches on shared words, which is why the description on each entry improves retrieval.

   Covered in Two ways to read a memory back

2. 2.If the user asks in natural language, the agent should retrieve with AI Search.Why is that wrong?

   Genie answers natural-language questions by querying Unity Catalog tables, which is structured retrieval. What decides the mechanism is whether the answer is an exact selection or computation over records, not whether the input is English.

   Covered in Structured query retrieval: when the agent already knows the key

3. 3.Pure vector similarity search is the best choice for memories identified by SKUs, error codes or other identifiers.Why is that wrong?

   Exact identifiers are poorly served by similarity alone. Use hybrid or full-text search, or a structured lookup if the identifier is a key column.

   Covered in Databricks AI Search: when the agent only knows what the memory is about

4. 4.An AI Search index can use a Lakebase Postgres memory table as its source.Why is that wrong?

   AI Search index sources are lakehouse tables (Delta, streaming or Iceberg v3+). For semantic search directly over Postgres rows, use Lakebase Search.

   Covered in Memories live in Postgres, AI Search indexes read lakehouse tables