---
title: "The Composable CDP: How Customer Data Stopped Moving"
date: 2026-06-19
summary: "A framework for the warehouse-native generation of customer data: what 'no data egress' actually buys, why reverse ETL became the last mile, how multi-cloud clean rooms split the work, and where the lock-in really went."
standfirst: "Customer data stopped moving, and the work came to it. The Composable CDP negates the word in the canonical definition that followed David Raab's April 2013 coinage — packaged — by leaving the unified profile in the warehouse and reading it in place, so the copy tax never lands on the profile: cross-cloud or internet egress runs roughly $87.50–$230/TB, and the packaged model pays it once per copy. The category's origin is demand-side: Gartner's 2025 Magic Quadrant found only about 22% of marketers reporting high business-user utilization. Publicis agreeing in May 2026 to acquire LiveRamp for roughly $2.5 billion turns owning your own substrate from a governance preference into a competitive one. Composable does not escape lock-in; it relocates it to the warehouse, the component hardest to leave."
canonical: https://nofluffadvisory.com/writing/the-composable-cdp-how-customer-data-stopped-moving/
---

When a foundational identity-and-connectivity rail gets acquired and absorbed, every team that quietly depended on it has to answer the same question: what do we rebuild, and where does it now live?

The honest answer is that you do not rebuild the old stack. You rebuild a different one — and the most consequential change is not which vendor you swap in, but a decision about whether your customer data moves at all.

For two decades the unspoken default was that data moves. It moved from your systems into a platform, from that platform into a second platform, and from there into the tools that actually did the work. Every hop was a copy. Every copy was a cost, a liability, and a small surrender of control. The category emerging now is defined by refusing that default.

> [figure: A vendor-neutral three-layer stack. Top: the Connectivity layer (walled gardens, measurement, programmatic) — the activation destinations. Middle, highlighted: the Data layer (data management and collaboration, audience marketplace) — the no-egress zone where the composable CDP and clean rooms live. Bottom: the Identity layer (identity graph, cross-device, universal IDs), resolved inside the warehouse. A vertical spine on the right shows the composable activation layer reading from Data, resolving through Identity, and pushing into Connectivity. Thesis: rebuild the data layer without a third-party identity spine — the warehouse becomes the source of truth.]

It helps to see the modern stack in three layers — connectivity at the top (the walled gardens, measurement systems, and programmatic platforms where activation actually lands), identity at the bottom (graphs, cross-device resolution, universal IDs), and the data layer in the middle, where management and collaboration happen. The interesting action is in that middle layer, and the interesting move is architectural: rebuild the data layer so the source of truth never leaves the warehouse you already own.

That move has a name. It is the **Composable CDP**, and it is best understood not as a product but as the third generation in a lineage.

The decision-table companion to this essay — what moves, what stays, and where identity resolves across packaged, composable, and reverse-ETL architectures — is the [comparison page](/standards/composable-cdp-vs-reverse-etl-vs-packaged-cdp/).

## Naming the negation

David Raab coined the term *Customer Data Platform* in April 2013. The canonical definition that followed — packaged software that creates a persistent, unified customer database accessible to other systems — contains the word that the next generation set out to destroy: **packaged**.

A Composable CDP is an architectural pattern, not a single bundled application. Instead of buying one system that collects, stores, unifies, and activates customer data, you assemble interchangeable best-of-breed components for each stage on top of a cloud data warehouse you already operate. Its defining property is *warehouse-native* and *zero-copy*: the unified profile lives in the warehouse — Snowflake, BigQuery, Redshift, Databricks — and is read in place rather than ingested into a vendor-owned store. Profiles, segments, scores, and activation logs are computed and written back inside the warehouse, governed by your own security and access controls.

> The category is defined by what it refuses to do, not by a feature it adds: the word "packaged" is exactly what "composable" set out to negate.

The framing itself was borrowed. *Composable* arrived from Gartner's composable-enterprise and Packaged Business Capabilities constructs around 2020 — the idea of building systems from interchangeable, API-bounded parts. The application to customer data emerged when data teams noticed something obvious in hindsight: their first-party data was already centralized in a cloud warehouse, which made a second proprietary copy inside a packaged CDP redundant. The enabling mechanism — reverse ETL — was popularized by activation vendors around the same time.

## Three generations, three problems

The lineage is a record of successive problem-solving, not fashion. Each generation fixed its predecessor's core failure and inherited a new one.

> [figure: Three generations of customer data as successive problem-solving. Gen 1, the DMP, solved cross-site anonymous audience scale but had no persistent identity and is collapsing under cookie deprecation. Gen 2, the packaged CDP, solved persistent first-party profiles but duplicated PII into a proprietary store, created lock-in, and underdelivered — only about 58 percent saw real value. Gen 3, the composable CDP, removed duplication and lock-in by keeping data in the warehouse, trading multi-vendor complexity and latency. Arrows show each generation inheriting the prior one's unsolved problem. Anchors: David Raab coined Customer Data Platform in April 2013; composable framing was inherited from Gartner around 2020. The lineage is a ladder of trade-offs, not a verdict.]

The first generation was the [data management platform](/writing/the-dmp-and-programmatic/). DMPs solved cross-site audience scale for advertising by aggregating anonymous third-party-cookie data into short-lived segments. What they never had was persistent identity or genuine first-party profiles — and as third-party cookies decayed and privacy regulation tightened, that gap hollowed out the core. The economics that once made addressable audiences a [hundred-billion-dollar question](/writing/the-future-of-addressability-100b/) shifted underneath them.

The second generation, the packaged CDP, solved the identity problem directly: persistent, identity-resolved, known-customer profiles in a single vendor-managed application. In practice it is the layer where a brand maps [a foundational identity graph](/writing/guide-how-i-d-build-a-delta-air-lines-campaign-for-possible-in-miami/) and powers [psychographic and behavioral personalization](/writing/behavioral-prediction-framework-for-advertising/). But it solved identity by duplicating customer data — including PII — into a proprietary store, which brought vendor lock-in, high fixed cost, long implementations, and, repeatedly, disappointing realized value.

The third generation removed the duplication and the lock-in by leaving the data in the warehouse and paying per component. Its new trade-offs are real: multi-vendor integration complexity, a buyer shift toward data engineering, and replication latency that can blunt real-time loops.

> Each generation fixed its predecessor's core failure — and introduced a new one. The lineage is a ladder of trade-offs, not a verdict.

## The disappointment that created a category

A category defined by negation needs proof that the thing it negates fell short. That proof exists. By the measures the analyst community tracks, only about **58%** of CDP deployments delivered significant value; **30–50%** of CDP projects miss their first-year value target; and Gartner's 2025 Magic Quadrant found only about **22%** of marketers reporting high business-user utilization — alongside persistent concern about PII duplication.

This is a demand-side origin story, not a technology push. Composable did not win because warehouses got a clever new feature. It won because the bundled promise underdelivered often enough that buyers went looking for an architecture that asked them to copy less and own more.

## No data egress: the architecture and its economics

The defining property of the warehouse-native model is simple to state and consequential to enforce: **no customer data is persisted outside your own cloud warehouse.** Profiles, segments, scores, and activation logs are computed and written back in place. Because the guarantee is enforced by your own security and access controls rather than a vendor's promise, governance becomes a property of the architecture.

> [figure: Two architectures side by side. Left, the packaged ingest-and-store CDP: sources are copied into a proprietary CDP store, then copied again into each activation tool. Every hop adds an attack surface, a consent point, a deletion target, and pays the egress tax again. Right, the warehouse-native zero-copy CDP: sources land in the cloud data warehouse, which holds the single governed copy where profiles, segments, scores, and logs are computed in place; only the resolved segment is transmitted to tools — never raw records. The tools come to the data, warehouse-agnostic across Snowflake, BigQuery, Redshift, Databricks. A price ribbon shows egress costs: zero for ingress and same-region, about twenty dollars per terabyte cross-region, and roughly eighty-seven to two hundred thirty dollars per terabyte cross-cloud or to the internet.]

The economic argument is not rhetorical. It is grounded in real cloud egress pricing. Moving data *in* costs nothing; same-region transfer costs nothing; cross-region transfer within a cloud runs on the order of **$20/TB**; and cross-cloud or internet egress runs roughly **$87.50–$230/TB** depending on provider and region. The packaged model pays a version of that tax repeatedly — once to copy data into the CDP, and again to copy it into each activation tool. The zero-copy model pays it never for the profile itself; it transmits only the resolved segment.

> Keeping data in place is free; moving it out is metered. The packaged model pays that tax once per copy. Zero-copy pays it never.

> [figure: A vertical bar chart of cloud egress cost per terabyte. Ingress (data in) costs zero. Same-region transfer costs zero. Cross-region within the same cloud costs about twenty dollars per terabyte. Cross-cloud or internet egress costs roughly eighty-seven dollars fifty at the low end and about two hundred thirty dollars per terabyte at the high end. The caption: a packaged CDP pays a version of this tax once per copy; a zero-copy model pays it never.]

Governance compounds the case, and it connects directly to [why portability and interoperability matter](/writing/data-portability-and-application-interoperability-what-is-all-the-fuss-about/). Every copy of customer data is a new attack surface, a new place to enforce consent, and a new target for a deletion request. Keep one governed copy and you enforce access controls, audit trails, residency rules, and the right to be forgotten *once* — instead of chasing the same record across five vendor systems.

> Each copy of customer data is a new attack surface, a new place to enforce consent, and a new target for a deletion request.

## Structural, not incidental

The contrast with the ingest-and-store CDP is structural, not a matter of degree. A bundled CDP ingests, stores, and activates inside one proprietary system, which forces an organization into an awkward choice: is the source of truth for customer data the CDP, or the warehouse? Answering "the CDP" fragments the truth and creates a second silo outside the modern data stack — business logic re-implemented inside a black box.

The composable approach refuses the choice. It reuses warehouse-resident infrastructure — the same dbt-defined metrics analytics already trusts — so the logic is not rebuilt in a place no one can audit. And the deeper enabler of collaboration is *no-copy data sharing*: the warehouse grants a read-only reference through its metadata and services layer rather than transferring bytes. Shared data consumes zero storage in the consumer's account, access is near-instantaneous, and the consumer pays only for the compute used to query it.

> [figure: A vertical layered stack of the composable CDP. At the base is the cloud data warehouse or lakehouse — Snowflake, BigQuery, Redshift, Databricks — the single governed source of truth, zero-copy. Stacked on top, bottom to top: storage and unification (identity resolution in SQL, reuse of dbt-defined metrics), analytics and understanding, segmentation and audience (no-code), and at the top the activation and reverse-ETL layer, the last mile that syncs resolved audiences out to operational tools. To the side is a collaboration layer: no-copy clean rooms with a symmetric multiparty collaboration API. Each stage is a best-of-breed component; the profile is read in place, never copied into a proprietary store.]

## Reverse ETL: the last mile

If the warehouse is the source of truth, something has to carry the truth to the tools where people actually work. That something is reverse ETL — and it earns its place as the activation layer by inverting a fifty-year-old pattern.

> [figure: Reverse ETL inverts the fifty-year pattern, shown as three stacked rows. ETL, from the 1970s: source apps, transform on a separate engine, then load into the warehouse — writing schemas you own. ELT, around 2012 with cloud warehouses: source apps load raw into the warehouse, then transform in place — also writing schemas you own. Reverse ETL: warehouse modeled tables are mapped, diffed, and synced out to operational SaaS such as CRMs, ad platforms, email service providers, and support tools, where it must conform to third-party destination APIs. The warehouse stops being only a destination for analysis and becomes a source for action.]

Classic ETL (IBM, 1970s) extracts from source systems, transforms on a separate engine, and loads into the warehouse. ELT (cloud warehouses, roughly 2012 onward) loads raw data first and transforms in place. Both end *in* the warehouse, writing schemas you own. Reverse ETL runs the pipeline the other direction: it syncs cleaned, modeled data *out* of the warehouse and into the operational SaaS tools business teams live in — CRMs, ad platforms, email systems, support desks — making warehouse data actionable without anyone writing SQL or living in a dashboard.

The mechanism is unglamorous and exact. A scheduled or event-triggered query runs against modeled tables; because warehouses cannot emit change-data-capture logs for arbitrary SQL, the tool *diffs* the current result set against a snapshot of the prior run to find what changed, maps fields to each destination's schema, and writes only the changed rows to each destination's API. Cadence spans event-driven sub-minute syncs, five-to-fifteen-minute polling, and hourly or daily batch. Unlike ETL and ELT — which write to schemas you control — reverse ETL must conform to third-party destination APIs, which makes it genuinely harder to engineer per destination.

> [figure: The reverse-ETL sync mechanism as a four-step pipeline. Step one, query: a scheduled or event-triggered SQL query runs against modeled tables or dbt models. Step two, diff: the tool snapshots the current result set against the prior run to find changes, because warehouses cannot emit change-data-capture logs for arbitrary SQL. Step three, map: fields are mapped to each destination's schema. Step four, write: only the changed rows are written to each destination's API, so incremental syncs minimize calls and cost. A cadence spectrum runs from event-driven sub-minute, through five-to-fifteen-minute polling, to hourly or daily batch. A boundary note: this is not event collection, not anonymous-to-known identity resolution, and not sub-second lookups — one component of a CDP, not a substitute.]

> Reverse ETL is what turns data infrastructure you already pay for into a composable CDP.

The term, notably, was named rather than invented. The category emerged around 2018 and went mainstream by 2021, driven by activation vendors describing themselves as pushing data *out* of the warehouse. No single person formally coined it; it was a category-naming event.

## What reverse ETL is not

Discipline about the boundary is what keeps the whole thesis honest. Reverse ETL is one component of a CDP, not a substitute for one. It does not collect events — there is no SDK, no event stream. It does not resolve anonymous-to-known identity. It does not serve sub-second profile lookups, native messaging, or AI decisioning. It operates strictly *downstream* of collection, assumes a unified customer table already exists, and activates pre-built segments on a batch-to-near-real-time schedule.

> Reverse ETL is one component of a CDP, not a substitute for one — it activates a unified table it assumes already exists.

If you arrived here weighing the two head-to-head, the comparison has its own page: [CDP vs. Reverse ETL Is the Wrong Question](/writing/cdp-vs-reverse-etl/) — the decision table, the three scenarios, and the trap on each side.

That boundary also names the model's honest cost: **latency**. Historically, batch reverse-ETL syncs have trailed packaged CDPs on real-time personalization. The no-egress model's real trade-off is not capability, it is freshness — which is why hybrid patterns that pair warehouse-native ownership with a real-time path keep appearing.

## Multi-cloud clean rooms: collaboration without the copy

No-copy sharing does not stop at the edge of one organization. The same primitive — reference, not copy — is exactly what [clean rooms](/writing/how-clean-rooms-will-power-the-future-of-digital-marketing-in-2025/) generalize across companies, letting parties collaborate on customer data without moving it. It is the natural endpoint of the [zero-party and cookieless](/writing/data-clean-rooms-and-zero-party-data-powerful-solutions-for-a-cookie-less-future/) trajectory.

> [figure: Before and after topologies for clean-room collaboration. Left: the rigid one-to-one provider and consumer model, where every pair of participants needs its own room, so rooms grow with the square of the number of partners — a combinatorial mesh. Right: the symmetric multiparty model driven by a Collaboration API, where a central owner assigns flexible roles — Owner, Data Provider, Analysis Runner — and any party can contribute data, submit templates, and set per-template access, letting an ecosystem scale to dozens of partners without N-squared complexity. Underneath both is the reference-not-copy primitive: parties collaborate without moving data.]

The architecture has matured in a specific way. The rigid 1:1 provider/consumer model — where every pair of participants needs its own room, so rooms multiply with the square of the partner count — is giving way to a symmetric, multiparty design driven by a collaboration API. An owner assigns flexible roles (owner, data provider, analysis runner); any party can contribute data, submit query templates, and specify per-template access. The result is that an ecosystem can scale to dozens of partners without combinatorial room sprawl, on the same "reference, not copy" foundation.

Positioned in the lineage, this is the *collaboration layer* of the warehouse-native stack — sitting beside reverse ETL, which is the *activation layer*. The warehouse vendor owns the privacy-safe join; the composable layer owns resolution and activation. That division of labor matters: it makes the activation layer an interoperability beneficiary, not a competitor to the clean room it reaches into.

## But isn't that just a clean room?

This is the question that trips everyone up — fairly, because from a distance the two look almost identical. Both keep data in place. Both talk about "collaborating without copying." Both increasingly run on the very same warehouses. So where is the line?

The line is the **verb**. A clean room is a privacy-safe *compute* environment: its job is to run an approved **join** across two or more parties' data so that neither side ever sees the other's raw rows. A composable CDP is an *activation* layer: its job is to **sync** one party's resolved data out to the operational tools that act on it. One computes a result; the other delivers a segment.

> [figure: Clean room versus composable CDP, shown as a relay rather than a rivalry. Left panel, the clean room or DCR at layer two: brand data and publisher data feed a privacy-safe join with a governed query where no raw rows cross, producing an approved audience. Its question: who can we reach together, safely? It involves two or more parties and protects them from each other; its verb is join or match. A hand-off arrow passes the approved audience to the right panel, the composable CDP at layer three: the approved audience, or your own unified profile, goes through reverse ETL out to operational tools like a DSP, CRM, and email service provider. Its question: now go reach them. It involves one party and its verb is sync or activate. Thesis: the clean room negotiates the audience; the composable CDP executes it.]

The cleanest test is to ask *who is being protected from whom*:

- A **clean room** protects two parties **from each other** — the brand cannot see the publisher's user-level rows, and vice versa. It exists precisely because there is a counterparty.
- A **composable CDP** has no counterparty to hide from. The thing it guards against is *unnecessary copies of your own data*. It is a single-player governance story, not a two-player one.

| | Clean room (DCR) | Composable CDP |
|---|---|---|
| **Layer** | L2 — privacy-safe compute | L3 — activation |
| **Core verb** | join / match | sync / activate |
| **Parties** | 2+ (cross-organization) | 1 (your data → your tools) |
| **Protects** | parties from each other | data from extra copies |
| **Output** | an approved result, kept in the room | a segment delivered into a tool |
| **Does data egress?** | no — raw rows never leave | yes — the resolved segment, by design |

Which is exactly why they are **complementary, not competing** — they are a relay:

1. The **clean room** answers *"who can we reach together, safely?"* — a brand and a publisher compute a privacy-safe overlap and produce an approved, matched audience, with no raw PII ever exposed.
2. The **composable CDP** answers *"now go reach them"* — it takes that approved audience (or your own first-party profile) and activates it: a sync to the DSP, the CRM, the email platform.

A clean room without an activation layer leaves the approved audience **stranded in the room**; a composable CDP without a clean room **cannot lawfully combine** two parties' data in the first place. Each is the other's missing half.

So why the constant conflation? Because the modern warehouse now offers *both* — a clean-room capability **and** the home for the composable CDP's data — on one platform. The same vendor sells you the governed join and the activation tooling stacked on top of it. But they remain different *functions* even under one roof: one is where the privacy-safe match happens; the other is what carries the result to the place it does work. Same building, different floors.

## Or just rent an identity spine?

The other thing the composable model gets confused with sits one layer beneath activation: the **identity-and-connectivity utility**. You onboard your data to a third party, it resolves that data to a shared, industry-wide ID, and syndicates it out across the open ecosystem. Call it *identity-infrastructure-as-a-service* — you rent a neutral spine and the rails that ride on it.

That is different in kind, not degree. Its whole proposition is **reach**: a shared ID that publishers, platforms, and partners all speak, so your audience can be matched and activated almost anywhere. You pay for that reach with a **dependency on a third party** — and, historically, with copies of your data into its environment.

The warehouse-native model makes the inverse bet: **own the substrate instead of renting the spine.** Identity is resolved inside your own warehouse and governance — your keys, your match logic, or a clean-room join with a named partner — with no third-party spine sitting in the middle of your first-party data.

| | Rent the spine (identity utility) | Own the substrate (composable) |
|---|---|---|
| **Identity resolved** | in a third-party graph (a shared ID) | in your own warehouse, or a clean-room match |
| **Data movement** | onboarded / copied to the utility | zero-copy — stays home |
| **Optimizes for** | reach across the open ecosystem | control + governance |
| **Open-web reach** | native — the shared ID is everywhere | needs a bridge (universal ID / clean room) |
| **Core risk** | dependency on a non-neutral spine | no shared ID of your own |

The honest nuance holds here too: it is not purely either/or. A warehouse-native stack still usually **bridges to a shared ID at the activation edge** — a universal ID, or a clean-room match — because your internal keys do not reach the open web on their own. What changes is *posture*: the shared spine becomes a component you call for reach, not the system of record you depend on.

And this is where the opening of this essay stops being abstract. The case for owning the substrate sharpened the moment the industry's most-used neutral spine stopped being neutral. In **May 2026, Publicis agreed to acquire LiveRamp** — the dominant identity-resolution-and-connectivity layer — in an all-cash deal valued at roughly **$2.5 billion, expected to close by the end of 2026**. The stated logic was data and "agentic" capability for the AI era.

But neutrality was the *entire value* of a spine everyone routed through. The day an **agency holding company** owns the rails your first-party data and identity travel on, every rival holding company — and every brand wary of feeding a competitor — gains a concrete reason to stop depending on the spine and rebuild the data layer they control. The deal does not end the utility model; it turns "own your own substrate" from a governance preference into a competitive one. (The quiet irony: the utility had already moved warehouse-native and into clean rooms — migrating toward the very architecture its acquisition now accelerates.)

## The lock-in swap: where the weight actually went

Here is the critique the category's marketing tends to skip, and the most important thing to put on a stack diagram honestly. Composable does not escape lock-in. It *relocates* it.

> [figure: The lock-in swap, in two states. State A, the packaged era: customer data is trapped inside one vendor application — a black box — which is application-layer lock-in. State B, the composable era: thin best-of-breed tools for identity, segmentation, and reverse-ETL activation are bolted on top of the cloud warehouse, but the warehouse now concentrates storage, the identity graph, compute, and the SQL dialect every pipeline is written against — the highest-switching-cost component. Separately, each reverse-ETL destination is another copy of PII, so data-processing agreements, audits, breach vectors, and deletion complexity scale with the number of vendors. Net: application-layer lock-in goes down while infrastructure-layer lock-in goes up. Lock-in was relocated, not removed.]

The packaged era concentrated lock-in at the application layer: your customer data sat inside one vendor's black box. The composable era dissolves that — thin, swappable tools for identity, segmentation, and reverse-ETL activation bolt onto infrastructure you own. But the dependency does not vanish; it migrates to the one component that is hardest to leave. The warehouse becomes the single point of concentration for storage, the identity graph, compute, and the SQL dialect every pipeline is written against — the highest-switching-cost layer in the stack. If warehouse compute pricing moves, the economics of the entire activation layer move with it.

And the no-egress governance win has a quiet asterisk: the activation layer's reverse-ETL syncs still write copies to each destination by design. So while the *profile* stays in one governed place, the activation surface multiplies with vendor count — scaling data-processing agreements, audit scope, breach vectors, and deletion complexity right back up.

> Composable reduces application-layer lock-in while concentrating, and arguably deepening, the dependency on the one component hardest to leave: the warehouse.

None of this is a reason to reject the architecture. It is the cost of the architecture, stated plainly — which is the only way to choose it well.

## The activation layer becomes the agent's execution surface

There is a forward edge to all of this, and it is where the warehouse-native stack stops being a data-engineering story and becomes an [agentic](/writing/mcp-a2a-omg-the-new-abcs-of-advertising-ai/) one.

Once the unified profile lives in the warehouse and reverse ETL is the path to action, the activation layer becomes the obvious execution surface for advertising agents. Natural-language configuration already lets non-engineers define audiences and integrations; autonomous decisioning is moving from a feature into the product thesis. An agent that can read a governed profile in place, resolve identity inside the customer's own controls, and activate through a standard reverse-ETL path does not need a bespoke integration for every destination — it needs a protocol. That is precisely the gap that emerging agentic standards aim to fill, and it is why [containerizing the signal](/writing/signal-containerization-agentic-advertising/) — packaging intent, provenance, policy, and activation logic into one portable, governed object — is the natural unit of work for this layer.

The enterprise-data world is arriving at the same edge from the other direction. A 2026 Databricks executive publication makes the case to CIOs that a governed data layer is no longer only the foundation for analytics — it is the foundation for *agents*, and its sharpest framing is a governance one: an agent is like a data asset. It costs money continuously, it has a threat surface, and — the line that belongs on every activation-layer roadmap — *"you cannot turn off what you cannot see."* Whatever discipline a warehouse-native stack already applies to the profile — lineage, access, expiry, observability — is the discipline an agentic activation layer will have to apply to the agents acting through it. That is the quiet compounding advantage of stopping the data from moving: the governance you built for the profile becomes the governance you need for the agent, and the same catalog that resolves *which copy of the customer table is current* also resolves *[which slice of the warehouse an agent may reason from](/writing/the-context-economy/#permissions-are-a-relevance-signal)* — the yardstick shifting, as it does everywhere agents touch money, from how many you deployed to whether you can govern, audit, and retire them.

The throughline of three generations finally resolves here. The DMP moved anonymous audiences. The packaged CDP moved known profiles into a box. The composable generation stopped moving the data at all — and in doing so, turned the warehouse from a place you analyze the past into the surface where agents act on the present.

That is the real shift. Not a better segment, not a cheaper license. Customer data stopped moving, and the work came to it.

Where the work goes next is the sequels’ territory: [one governed memory absorbing the paid/owned wall](/writing/the-agentic-cdp-two-industries-one-table/), and — because the profile the warehouse governs carries the who and the what of a customer’s moment but not its where or when — [the context economy](/writing/the-context-economy/).