Decide what is true, who may see it and how an agent recovers when an action goes wrong.
Authority, permissions, retrieval, memory, knowledge layers, tools and recoverable actions, framed as the data decisions a product manager owns, with a ten-worksheet toolkit for the data PRD.
Guide PDFs and toolkits download with paid Premium while it is active, or with complimentary access we have approved. Days earned through referrals open the rest of the site, not these files.
Authority / permission / memory / recovery
Pages
81
Chapters
31
Diagrams
28
Dated sources
48
Worksheets
10
What is an agentic database, and why does a PM decide its rules?
Most agent incidents that reach a customer are data incidents: an answer from wording that changed last week, a document shown to someone who lost access, a payment sent twice because a reply got lost, a deleted record that came back after a restore. None of them is fixed by a better model. Each is a decision about authority, freshness, permission or recovery that somebody had to make.
This guide follows one fictional claims assistant used by two insurers, from its first retrieval design to a platform choice, a deletion request and three incidents. You learn which system decides each fact, what an agent may remember and change, and how to defend the design to a privacy lawyer, a platform team or an interviewer.
THREE COMPLETE PAGES, FREE TO READ
Judge the reasoning before you decide.
Each preview is a real page from the PDF. Open one to read it at full size.
Page 22
Expect filtered search to behave differently
Why searching everything and then filtering by permission can return two passages when five exist.
Page 43
Catch the plausible wrong number
How a join turns one USD 6,200 payment into USD 12,400, and the defences that let managers trust totals.
Page 44
Design every action for the lost reply
The unknown state, the idempotency key and the re-check that stop a payment going out twice.
31 CHAPTERS / 6 PARTS
From the product decision to a design you can defend.
The data job
Separate answers, recommendations and actions, give every kind of state a contract, learn the database basics that decide outcomes and keep records you can explain.
01Separate answers, recommendations and actionsp. 7
02Sort the agent's state by what it is forp. 9
03Learn the database basics that decide outcomesp. 11
04Keep records you can explain laterp. 13
Retrieval with permissions
Start relational, take identity from the caller, question similarity search, filter before ranking, combine methods on evidence and keep the index fresh.
05Begin with one relational databasep. 16
06Let the session decide who is askingp. 18
07Understand similarity search well enough to question itp. 20
08Expect filtered search to behave differentlyp. 22
09Combine search signals on purposep. 24
10Keep the search index in step with the sourcep. 26
Memory and knowledge
Store memory people can correct, use graphs and time where they earn it, give each knowledge layer one job and keep caches from becoming authority.
11Remember only what people can fixp. 29
12Use a graph when relationships carry the answerp. 31
13Sort out graphs, ontologies, catalogs and featuresp. 33
14Use only what was knowable at decision timep. 35
15Stop caches and queues from deciding factsp. 37
Tools and actions
Shape tools like the job, fence generated SQL, design every action for the lost reply and resume long tasks without repeating them.
16Give the agent tools shaped like the jobp. 40
17Let the agent query, inside a fencep. 42
18Design every action for the lost replyp. 44
19Resume a long task without doing it twicep. 46
Choose and operate
Read the landscape and licences, start small, change safely, price per successful task, benchmark the real request, delete everywhere and release on evidence.
20Read the database landscape by workloadp. 49
21Start with the smallest architecture that keeps the rulesp. 51
22Change schemas and models while the agent runsp. 53
23Price the data layer per successful taskp. 55
24Benchmark the request your users actually sendp. 57
25Watch the signals that predict incidentsp. 59
26Delete everywhere, and recover without undoing the deletionp. 61
27Release on evidence, with gates that can say nop. 63
Prove and defend
Write the data PRD, work through three incidents, defend the design in a clinic and plan your first six weeks.
28Write the data PRDp. 66
29Three incident reviewsp. 68
30Design clinic: defend the data layerp. 70
31Your first six weeks as the PMp. 72
WORKED INCIDENTS
Three incidents, worked from the evidence.
Each fictional incident asks what a PM has to answer: which copy took on authority it was never given, who was told, what detection missed and which test now prevents a repeat.
Parser failure / average-lag alert
The endorsement that would not update
Find why adjusters quoted an old cap for three hours, and alert on the oldest open record per tenant.
Cache key / missing permission
The cached answer that crossed a role
Put the asker's permission version in every key and re-check permission before any cached read.
Lost reply / timestamp in the key
Two payments for one repair
Build idempotency keys from stable fields only and reconcile payments against approvals every day.
INCLUDED / 14 FILES
Ten worksheets for the data PRD.
The guide ships with ten editable worksheets and three spreadsheets that become the data section of a PRD and the evidence a privacy, platform or customer risk reviewer will ask for.
Start with the job and authority map and the data-contract register. Together they answer the two questions every reviewer asks first: which system decides, and where does every copy live?
These questions, concepts and lessons pick up where the chapters leave off. Each link also sits, clickable, in the chapter it supports, and keeps its own access level on the site.
In this guide it is an architecture, not a product: the stores, indexes and controlled interfaces that let an agent find evidence, remember approved facts, resume work and make authorised changes. It does not mean a database with a model inside it.
Do I need to know SQL to use this guide?
No. It is written for product managers. It shows a few short schema tables and examples so you can recognise them in a design review, but it never asks you to write a query.
Does it cover vector databases and RAG?
Yes, as decisions: similarity measures, filtered search, hybrid retrieval and reranking, freshness and permission checks, and when a dedicated vector engine earns its place over PostgreSQL with pgvector.
Which products does it cover?
PostgreSQL and pgvector, Qdrant, Weaviate, Mem0, Graphiti, Letta, Neo4j, Feast, Valkey and Redis, MCP servers, Spanner, TiDB, DynamoDB, Cosmos DB, Aurora, Neon, Supabase, BigQuery and more, with 48 sources checked in October 2026 and licence positions dated.
How current is it?
Product, licence and protocol facts are dated October 2026. Each chapter teaches the durable principle first, so the guide stays useful when products and licences change.
What is in the toolkit?
14 files: ten editable worksheets from the authority map to the incident review, plus CSV versions of the data-contract register, the platform scorecard and the cost model. Each has one worked example from the guide.
Will this help in AI PM interviews?
Yes. Chapter 30 is a design clinic of ten prompts with a scoring rubric and worked answers, and every chapter links to related practice questions and concepts on the site. Retrieval, memory and agent safety come up in most AI PM loops.
Is it included in Premium?
Yes. The full PDF and toolkit come with paid Premium while it is active, or with complimentary access we have approved, and there is nothing extra to buy. Anyone can read three full sample pages first. Days earned through referrals open the rest of the site, not the guide files.
How was it produced?
AI tools helped with research, source checks, drafting and the cover art. The diagrams are vector figures written in code. Halyard, its insurer customers and every person in its scenarios are invented. This edition is ready for publisher review, and automated or AI review is no substitute for an independent human editor signing it off.
