The platform's data does not live in one place. It is scattered across the run state of in-flight agents, long-term memory, the vector and graph indexes, telemetry traces, the audit log, and the usage ledger — each with a different shape, volume, consistency requirement, and sensitivity. Treated as a set of independent stores, this estate becomes ungovernable: you cannot say with confidence where a customer's data is, how long it lives, or that you have truly deleted it. This chapter consolidates the data layers scattered through the book into one architecture with one lifecycle.

27.1 The data classes

Begin by naming the distinct classes of data a platform holds, because each demands different treatment. Operational state is the run-state object (Ch. 5) — small, strongly consistent, short-lived. Memory (Ch. 10) persists across sessions. Knowledge is the RAG corpus and its derived vector and graph indexes (Ch. 11). Telemetry is high-volume trace and metric data (Ch. 18). Audit is the immutable, long-retained compliance record (Ch. 17). Usage is the metering ledger (Ch. 25). Configuration is the versioned prompt, policy, and tenant artifacts. Conflating these — one retention policy, one store, one sensitivity class for all — is the root of most data-governance failures.

27.2 Agent state as a versioned schema

The run-state object of Chapter 5 is a data contract, and like any contract it changes over time — yet agent runs can live for hours or days, so a deploy may need to resume a run that was started against an older schema. This is the schema-migration problem, sharpened by long-lived state. The disciplines are familiar from databases: carry an explicit state_version, keep changes forward- and backward-compatible (add optional fields, never repurpose existing ones), and version the reducers that mutate state. Durable engines provide direct support — Temporal's workflow versioning/patching, for instance, lets new code branch on whether a run predates a change so in-flight runs finish on the logic they started with. Treat agent state with the same migration rigour you would a production database, because that is what it is.

27.3 Lineage and provenance

The hardest data questions a platform must answer are about derivation. Which source document produced this embedding? Which chunks grounded this answer? What training set was this fine-tuned model built from (Ch. 28)? Without lineage — provenance metadata threading every derived datum back to its source and its tenant — you cannot attribute a citation, debug a bad retrieval, reproduce an evaluation, or, most consequentially, guarantee deletion. Lineage is what makes the data estate auditable rather than merely stored.

27.4 One lifecycle, applied uniformly

Every datum, whatever its class, moves through the same lifecycle: ingest → derive → use → retain → erase. The platform's job is to apply that lifecycle uniformly and govern it from one place — a single retention-and-residency policy keyed by data class and tenant, rather than per-store afterthoughts. The payoff is the property Chapter 17 demanded: when a deletion request arrives, lineage lets you find and erase every derived copy — embeddings, graph nodes, caches, summaries, training sets, backups — not merely the primary record. Residency is enforced the same way: each class is region-pinned, and lineage proves no derived copy escaped its region.

27.5 Choosing the operational store(s)

A recurring question is whether to split operational data across stores — a relational database for accounts and a document database for conversations, say. It is worth answering from first principles, because the intuitive split is not always the cleaner one. First, "chat data" is not one thing: the run state lives in the durable-execution engine and is the system of record (Ch. 29), not a free-floating log; memory goes to the vector and graph stores (§10.4, Ch. 11); telemetry goes to the trace backend (Ch. 18); audit goes to append-only storage (Ch. 17). The only slice genuinely up for debate is the conversation transcript — the message history rendered to the user.

For that slice, the default should be the relational system you already run: Postgres with a JSONB column handles semi-structured messages well, and keeping it in one database means one backup-and-DR story, one tenant-isolation mechanism (Ch. 26), one provable-erasure path (Ch. 16), and transactional consistency with the rest of your data. Introducing a second operational database — MongoDB, say — doubles every one of those surfaces and gives up cross-store transactions, which is why splitting usually adds operational complexity rather than removing it. A separate store earns its place when a real driver appears: write throughput or horizontal scale beyond comfortable single-Postgres limits, genuinely document-shaped access, or schema volatility that JSONB ergonomics cannot absorb — at which point a document store (MongoDB) or a wide-column store (Cassandra, ScyllaDB) is the right reach. This is polyglot persistence applied honestly: each data class to the store that fits, but minimize the number of stateful systems you operate, and let scale and access patterns — not an a-priori "relational versus document" aesthetic — decide when to add one.