Agentic Memory on Databricks: Deploy DB Agent with Databricks Lakebase

Register: becloudready.com/webinar/db-agent

Fully on Databricks: we deploy the open-source DB Agent live, with Lakebase as the database and, via the pgvector extension it ships natively, as the vector store for agentic memory too, one instance doing both jobs, no separate vector service to provision.
The real problem: enterprises run agents against different databases in different security zones for good reason, and giving them shared memory usually means either a data leak or no memory at all.
The fix: a redaction-first pattern, every interaction passes through a second LLM call that produces a sanitized summary (entities by ID and type, never literal values) before it's written to Lakebase, so other agents get context without ever seeing the underlying data.

You'll leave knowing:

• How to deploy DB Agent on Databricks with Lakebase as both database and vector store
• Why pgvector on Postgres beats a bolted-on vector service: similarity ranking, TTL filtering, and self-exclusion in one indexed query, no client-side filtering
• What agentic memory actually means, and why most of what's marketed under that name doesn't survive contact with enterprise security boundaries
• The summarize-then-store redaction pattern, and why it has to be a second LLM call, not a filter
• What broke in real testing (a silent embedding bug), and what the fix looked like