An agentic CDP for merchants with no warehouse and no data team. The category is three weeks old; this is its fourth architecture — federated over the stack the merchant already owns.
Every answer to the agentic-CDP question so far assumes two things the average merchant does not have: a warehouse and a data team. This product is built for everyone the category skipped. The merchant already owns systems of storage — Shopify, Klaviyo, Meta, a POS. What nobody sold them is the system of decision: the thing that reads those systems, finds the money, drafts the action, and proves whether it worked.
So it keeps governed working memory and nothing else. No duplicate customer record. It reads from source, holds only what it needs to reason, act, audit, and measure, and points back to source wherever it can. And nothing is agentic without a signature: every send, sync, spend, suppression change, or public-facing action passes a human gate first.
Measured lift, not vendor math —
and when we cannot prove it, we say so.
A ranked opportunity feed — abandoned checkouts, lapsed customers, upsell candidates — dollar-estimated where the estimate is defensible, labeled where it isn't.
Deterministic recipes turn an opportunity into a concrete draft: a Klaviyo recovery flow, a win-back sequence, a Meta seed + suppression audience plan.
A human signs off before anything sends, syncs, spends, or touches a customer. The draft shows the risk, the approval needed, and how success will be measured.
Execution happens through the merchant's own tools — the flow lands in Klaviyo, the audience lands in Meta. The operator orchestrates; it doesn't replace.
A holdout is assigned where exclusion is enforceable; everywhere else the readout carries an honest label instead of a lift claim.
Outcome, approval, and Operating Rules version land in the Context Ledger — the working memory the next recommendation reasons from.
Hightouch calls the category "Agentic CDP". A label exists; a market starts forming around it.
Databricks launches CustomerLake at its biggest conference of the year — for enterprises with lakehouses.
The trade press calls it "ready or not." Seven days from the name to the verdict.
This project reads the category's birth, writes the BRD, and hardens it to PRD v1.1 — checked into the repo.
One operator, three deterministic recipes, native holdouts, two verticals. Repo public. The fourth architecture exists.
Hightouch named the category on June 15, 2026. Databricks shipped CustomerLake into it on June 16, at its biggest conference of the year. By June 22 the trade press had already ruled: ready or not. Three architectures formed in a week — embedded in the warehouse (Databricks), layered on top of it (Hightouch), headless behind the agents (Treasure Data) — and all three assume a warehouse underneath and a data team beside it. This product takes the fourth cell: federated. The decision layer sits over the merchant's existing SaaS stack and keeps only governed working memory — context, a versioned constitution, a ledger, holdout state. All of it exportable at any time. In an industry built on hostage data, the state can leave.
Seven bands, one gate, one ledger. Sources feed governed working memory; deterministic recipes propose actions; every path converges on a single governance gate; activation happens through the merchant's own tools; measurement earns its labels — and the Context Ledger records all of it, append-only, down the right edge.
Shopify, Klaviyo, Meta, GA4, and Stripe feed the layer — with the local pack (POS, email, GBP) slotting in beside them. A sync-freshness gate sits ahead of everything else: stale sources don't get a vote.
Customer context, the versioned constitution (Operating Rules), and learned preferences. This is governed working memory — what the product needs to reason, act, audit, and measure — not a second customer record.
Deterministic recipes, no LLM calls in alpha: abandoned-checkout recovery, lapsed-customer win-back, Meta seed + suppression — with the local vertical's recipes registered beside them.
Every recipe path converges on one gate: consent, suppression, budget, discount, margin, approval, banned claims, freshness. There is no code path around the wall — imports run lib/server → lib/governance → connector.
Klaviyo flow draft → campaign draft → exportable brief → manual setup, plus a Meta audience-sync side channel. A draft is never an activation; approval comes first.
A 90/10 holdout where exclusion is enforceable — randomized, audience of 500 or more, Klaviyo flows only. Everywhere else, the readout carries an honest label instead of a lift claim.
An append-only spine running the full height of the system: every band writes to it, and every entry carries the Operating Rules version the decision ran under.
Every vendor in this category grades its own homework. This product ships the audit instead: native holdouts, and where it cannot prove impact, the readout says so — in the UI, not a footnote. The statistics hold to the same bar: randomized customer-level assignment, lift reported only as a 95% Newcombe–Wilson interval — a range, never a point estimate — a minimum detectable effect declared at plan time so an underpowered holdout announces itself before launch, and scheduled reads labeled against multiple-look inflation.
Every report carries exactly one: holdout-verified, before/after with no control group, or directional. There is no fourth state.
A holdout is assigned only to owned-channel flows with an audience of 500 or more, where the excluded group can actually be excluded. Meta audience sync is always directional.
In the local vertical, revenue estimates cover loyalty-matched (identified) customers only — and every card and readout states the identified-transaction share.
Governance an owner-operator can actually adopt — budget, discount, margin: three numbers, not a policy binder. Every decision, approval, and action is logged in the Context Ledger against the version of the Operating Rules it ran under. Governance is runtime configuration, not a PDF.
Shopify → Klaviyo → Meta → measured lift
POS → email → Google Business Profile → Meta
The second vertical is the architectural proof: it shipped as content, not re-architecture — a dataset, a constitution, two recipes, and a registry entry. Vertical selection routes everything — recipes, Operating Rules template, connector set, feed copy — through a single vertical registry. That is what one operator means.
The spec landed July 5, 2026 — a BRD read straight off the
category's birth, hardened to PRD v1.1. The alpha shipped July 7:
one operator, three deterministic recipes, native holdouts, two
verticals, a 57-check end-to-end smoke suite covering both, and
adversarial audits between milestones. The
repo is public;
the PRD and BRD live in docs/.
The origin is editorial. The Post-Agentic Marketing series ends with a ten-question procurement test for agentic marketing vendors — who owns the agent state, who enforces the constitution, what happens to memory on exit. This product was designed to pass the test its own essays wrote. The editorial standards became engineering constraints.
The loop also runs the other direction: the same operator-with-guardrails pattern now manages this site's own editorial analytics — Fire the Dashboard, Hire the Agent is the full build recipe for the agent that reads the traffic data monthly, recommends what to write next, and grades its own previous advice.
Ask about the essays, frameworks, playbooks, or how to work with Evgeny.
