CDP, Composable CDP, or Agentic CDP: The Decision Every CMO Can’t Afford to Delegate to IT.

We have to admit it: this isn't the first time we've had this conversation. Ten years ago, it was whether to run our own ad server or leave it to the agency. Five years ago, it was whether to build audiences inside media platforms or within our own systems. Today, the question is whether to adopt a composable CDP or an agentic CDP.

The question changes. The underlying problem does not.

Who tells you who your customer is? How much control do you have over that information? How much are you paying for it? Can you activate it whenever you want, or do you depend on IT opening a ticket?

And most importantly—the question that rarely reaches the executive committee: How long does it take your organization to go from identifying a business opportunity to launching a campaign in production?

That's the real question—not which platform has the best connectors.

What a composable CDP really is and why the metaphor matters

The formal definition talks about centralizing and unifying customer data from multiple sources. In practice, most teams describe it as "a cocktail shaker where you pour all your customer data, then serve each team exactly what it needs." And while that may sound simplistic, the metaphor is useful because it helps legal, business, technology, and marketing teams talk about the same project without each interpreting it differently.

A composable CDP is not a product—it is a design philosophy. Instead of buying a closed platform that copies your data into its own environment, it uses your existing data warehouse (Snowflake, BigQuery, Databricks) as the single source of truth, building modular capabilities on top of it: identity resolution, segmentation, and activation.

At the heart of this architecture is Reverse ETL. Traditional ETL moves operational data into the warehouse for analysis. Reverse ETL does the opposite: it takes precomputed segments and models (customer lifetime value, churn risk, purchase propensity) and synchronizes them with the systems where business actually happens: CRM platforms, advertising platforms, and marketing automation tools.

The promise is real: your data never leaves your governed environment, you can replace any component without rebuilding the entire stack, and you maximize the investment you've already made in data modeling.

For organizations with mature data engineering teams and use cases that can tolerate daily or weekly synchronization, this remains a strong architectural choice. The problem lies in what never appears in the original business case.

The cost nobody calculates before signing

Here's the nuance that rarely appears in a composable CDP sales pitch: every capability lives in a different vendor, connected through APIs. That gives engineering teams flexibility—but it also creates a structural consequence that few organizations account for.

When a campaign finishes and generates results (opens, clicks, conversions), that information must travel back through the entire chain: from the activation platform to Reverse ETL, from Reverse ETL to the warehouse, through dbt model rebuilding, and finally through predictive model retraining. Only then does the system actually know what just happened. That cycle is measured in hours—not seconds.

For a weekly email campaign, that latency is acceptable. For an agent that must act, observe the outcome, and improve its next decision during the same customer session, that latency isn't a technical detail—it is a structural limitation.

The second cost that rarely enters the initial conversation is privacy surface area. Every Reverse ETL synchronization to an external platform creates another copy of personal data outside your controlled environment. In a typical composable stack, an email address or phone number may simultaneously exist in three or more systems: the warehouse, the Reverse ETL cache, and every activation platform. Every copy requires its own processing agreement, deletion requests that take days to propagate, and audits that become more complex with every additional vendor.

Costs do not scale linearly. They grow as the product of data volume, number of connectors, synchronization frequency, and activated tools. At scale, maintenance costs (warehouse compute, synchronization fees, messaging platforms, identity resolution, and two to five engineers dedicated exclusively to the pipeline) can approach—or even exceed—the cost of an agentic platform with native activation.

This doesn't make composable expensive or agentic cheap. It simply means that total cost should be evaluated over three years—not based on the first invoice.

Six practices to reduce those costs before making any decision

Regardless of which architecture you ultimately choose, certain design decisions determine how expensive the platform will be to operate at scale. Making them now saves significant costs later.

1 A unified event layer from the source

If every channel reaches the warehouse with its own schema, costly downstream transformations accumulate and your data model becomes technical debt. Normalizing events across every channel (paid media, email, web, mobile apps, CRM) using a common schema from ingestion reduces future compute costs and makes models reusable.

2 Partition by date and channel from day one

Properly partitioned tables allow models to process only incremental data. It's a design decision that's inexpensive early on but saves substantial resources at scale.

3 Incremental synchronization based on Change Data Capture (CDC)

The largest variable cost driver in a composable CDP isn't licensing—it's the multiplication of rows, synchronization frequency, and destinations. Replacing periodic full exports with Change Data Capture can reduce transferred data volumes by 5x to 10x in organizations with relatively stable datasets.

4 Consolidate activation destinations

Synchronizing the same audience to four different platforms multiplies cost without multiplying impact. Whenever possible, centralize activation in a single destination and redistribute from there.

5 Define freshness SLAs by use case

Not every audience needs hourly updates. Separating use cases that genuinely require hourly refreshes from those that tolerate daily updates can reduce compute costs by 3x to 5x without affecting business outcomes.

6 Document business rules before activating any agent

An agent's operating cost is directly correlated with the quality of the context it receives. An agent working with poorly structured context requires more iterations, consumes more resources, and produces more discarded hypotheses. Investing time in documenting business objectives, brand constraints, restricted audiences, and business rules before deploying agents is one of the cheapest—and most overlooked—efficiency levers. Some organizations have institutionalized this responsibility through dedicated roles that act as the control point between strategy and autonomous agents.

What actually changes with an agentic CDP?

For ten years, CDPs have promised proactive intelligence. And for ten years, the reality has been the same: marketers enter the platform, build the audience they already had in mind, launch the campaign they had already planned, and leave. The CDP executes ideas but it has never generated one of its own.

The difference isn't a new version, it's what the platform does by default.

An agentic CDP continuously runs specialized agents that explore data, identify concrete business opportunities, and generate ready-to-use drafts of audiences, messaging, and campaign content. It doesn't wait for someone to arrive with a hypothesis—it creates one.

"The new data source we added has improved our churn model." "We have high-value segments without active campaigns. Shall we activate them?"

The difference from the AI chat assistants that nearly every platform now includes lies in the depth of investigation. AI chat is excellent for tactical questions like "Which products sold best last month?" but falls short when faced with open strategic questions, because it only sees its own platform's data, is optimized for fast responses rather than deep exploration, and loses context during long investigations.

An agentic CDP keeps specialized agents working in the background for hours. Some generate hypotheses, others investigate them, a prioritization mechanism ranks them by business impact, and a final validation layer discards anything unsupported by evidence. The outcome is not thirty random "opportunities" every day, but a prioritized, actionable list of what deserves attention right now.

How can the agent see the entire operation without duplicating data? The Composable Context Layer

At this point, a perfectly reasonable question arises: if the agent needs access to customer data, active campaigns, creative assets, and business rules, aren't we just creating another centralized repository with yet another copy of everything?

A well-designed implementation answers no. The architectural pattern that makes this possible is the Composable Context Layer, which applies the same philosophy as a composable CDP to AI itself: instead of moving all the data to where the AI lives, it moves the AI to where the data already lives.

Agents connect directly to the data warehouse without creating additional copies. They consume tools the organization already uses (Looker, Snowflake Cortex, Databricks Genie), access creative assets where they already exist (DAM platforms, Figma, content repositories), and receive business strategy through structured documents or open protocols such as MCP.

In production environments, this pattern can return customer context in approximately 60 milliseconds for small payloads—fast enough to personalize experiences in real time without waiting for the next batch process. It also allows organizations to define up to ten customized endpoints per role, ensuring each agent receives only the context required for its specific use case, including current consent status.

Vendors such as Tealium and Hightouch implement this pattern natively. In both cases, warehouse data is not replicated, it is exposed through a governed API.

It's an architecture that simultaneously solves governance and privacy challenges while enabling intelligence. The data stays where it is; the intelligence goes to the data.

How the system improves itself: cumulative campaign memory

The second structural difference is cumulative memory. Every customer interaction, campaign execution, experiment, and outcome becomes reusable evidence that informs future decisions. This memory operates at multiple levels.

• At the audience level, the system learns which segments consistently fail to convert, which audiences respond better to SMS than email, and at which point in a customer journey an offer truly changes behavior.
• At the campaign level, it remembers which subject line characteristics increase open rates among high-value customers and which creative formats perform best for product launches versus evergreen campaigns.
• At the strategic initiative level, every objective you define (increase purchase frequency, reduce first-time buyer churn) accumulates knowledge from previous executions. The next recommendation therefore starts with historical context instead of a blank slate.

The critical difference from a composable architecture is that this memory updates continuously within the same environment, without sending data back and forth between multiple vendors. Yesterday's outcome becomes today's input—within the same context and without manual retraining.

You define the business objectives and target metrics. Agents optimize against those goals within the same activation environment. Silos and alignment meetings become hypotheses and governance.

The question your executive committee should answer

This is not a technical question, it is an operating model question.

How long does it take your organization to move from identifying an opportunity to launching a campaign? Who generates new hypotheses? Who is explicitly responsible for challenging the status quo? How much does the complete process cost—from hypothesis design and legal validation to data ingestion, modeling, and activation?

If the answer is measured in weeks (a brief, a design team, developers or operations assembling audiences and customer journeys) then the problem isn't talent or media budget.

It's architectural.

And no additional Reverse ETL connectors will solve a limitation rooted in how the learning cycle itself is fragmented across vendors.

Ask yourself three questions to understand where you stand

Activation cadence

Can your business tolerate daily or weekly synchronization, or do you need the system to act and learn during the customer's current session?

AI maturity

Are your use cases limited to batch-trained models updated hourly or daily, or do you require continuous real-time decision-making?

Team capacity

Can your data team sustainably maintain a multi-vendor architecture, or does that operational burden compete with more strategic engineering priorities?

Organizations confidently answering "batch processing is enough" and "we have the team to maintain it" have a perfectly legitimate case for remaining with a composable architecture—as long as they implement the efficiency practices described earlier.

Organizations answering "we need a real-time closed learning loop" or "we already spend more maintaining connectors than developing strategy" are, perhaps unknowingly, describing the business case for an agentic CDP.

What every CMO should demand before signing

Regardless of which vendor sits at the table, there are five verifications every CMO should insist on before committing to any architecture.

• True zero-copy architecture. Require proof that data is not silently replicated. For agentic platforms, verify that the Composable Context Layer operates without copying data outside your governed environment.
• End-to-end compliance. Ensure certifications (SOC 2 Type II, ISO 27001, GDPR, CCPA) cover the entire platform—not only storage.
• Verifiable governance. Confirm role-based access control, protected data filtering, approval workflows, and auditable logs. For agentic platforms, also verify configurable guardrails defining which audiences agents cannot modify and which brand constraints they must respect.
• Native compatibility. Certified integration with your existing warehouse—without custom engineering.
• Real time-to-value. Production use cases measured in weeks, not quarters. For agentic platforms, ask for evidence that cumulative memory genuinely improves recommendations over time rather than only during the initial deployment.

The decision isn't binary but it is urgent

A hybrid deployment—using an existing warehouse while adding agentic capabilities only where they create value—may well be the right balance during the transition.

What isn't reasonable is continuing to treat this decision as merely a technical discussion to be settled in a data architecture meeting while competitors are already running campaigns that optimize themselves without waiting for the next sprint.

It's also worth remembering that the success of these initiatives depends less on the chosen technology than on having clear executive sponsorship, a well-defined business case, and change management capable of keeping technology, business, and customer teams aligned throughout the entire transformation. A perfectly selected agentic architecture can fail just as easily as a poorly chosen composable one if nobody has first established who makes decisions, what success looks like, and how long-term commitment across teams will be maintained.

These are never short-term projects. Even in the world of Reverse ETL, there is always an ongoing business-as-usual (BAU) operational burden.

The CDP market is consolidating because organizations that have already closed the learning loop inside a single platform are making better decisions, faster, than those still rebuilding models every time a campaign ends.

If you're evaluating this transition, the right question isn't which platform has the longest feature list.

It's which partner can help you evaluate the decision honestly, including the scenarios where the correct answer isn't necessarily the easiest one to sell.