# AI Growth Operator The agentic-CDP category is three weeks old, and every answer in it assumes a warehouse and a data team. AI Growth Operator is the fourth architecture — federated over the merchant's SaaS stack, with governed working memory, native holdouts, a versioned constitution, and exportable state. MVP v0 alpha, spec in the repo, built in public. > Markdown twin of https://nofluffadvisory.com/building/ai-growth-operator/ — text extracted from the page. Project registry: https://nofluffadvisory.com/building/ ← Building Founder · Built in public · The category is three weeks old # AI Growth Operator. 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. GitHub → Launch the live demo → - **Status** — MVP v0 · alpha · demo mode - **Stage** — Founder · Built in public - **Product** — Agentic CDP — SMB · DTC - **Architecture** — Federated — over the merchant's stack - **Trust line** — Measured lift, not vendor math - **Stack** — Next.js · TypeScript · Prisma - stages in the loop - measurement labels - verticals, one core - smoke-suite checks Inside this page - What it does - The loop - Three weeks - The federated fork - The system map - Trust engine - Two verticals - Built in public What it does ## The system of decision, not another system of storage. 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. Trust line, PRD v1.1 The loop ## Find money. Prove it moved. - Find money. A ranked opportunity feed — abandoned checkouts, lapsed customers, upsell candidates — dollar-estimated where the estimate is defensible, labeled where it isn't. - Draft action. Deterministic recipes turn an opportunity into a concrete draft: a Klaviyo recovery flow, a win-back sequence, a Meta seed + suppression audience plan. - Approve. 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. - Activate. 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. - Measure. A holdout is assigned where exclusion is enforceable; everywhere else the readout carries an honest label instead of a lift claim. - Learn. Outcome, approval, and Operating Rules version land in the Context Ledger — the working memory the next recommendation reasons from. Three weeks ## Three weeks separate the name from this alpha. - **Jun 15, 2026** — Named — Hightouch calls the category "Agentic CDP". A label exists; a market starts forming around it. - **Jun 16, 2026** — Enterprise ships — Databricks launches CustomerLake at its biggest conference of the year — for enterprises with lakehouses. - **Jun 22, 2026** — Press verdict — The trade press calls it "ready or not." Seven days from the name to the verdict. - **Jul 5, 2026** — The spec — This project reads the category's birth, writes the BRD, and hardens it to PRD v1.1 — checked into the repo. - **Jul 7, 2026** — The alpha — One operator, three deterministic recipes, native holdouts, two verticals. Repo public. The fourth architecture exists. Architecture context ## Three architectures in a week. This is the fourth. 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. The system map ## The system, drawn honestly. 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. - **Sources & the freshness gate** — 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. - **Context layer** — 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. - **Opportunity engine** — 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. - **Governance runtime** — 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. - **Activation ladder** — 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. - **Measurement** — 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. - **The Context Ledger** — 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. Trust engine ## The product ships its own audit. - Measured lift, not vendor math. 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. - Three measurement labels. Every report carries exactly one: holdout-verified, before/after with no control group, or directional. There is no fourth state. - Holdouts only where exclusion is enforceable. 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. - POS coverage disclosure. In the local vertical, revenue estimates cover loyalty-matched (identified) customers only — and every card and readout states the identified-transaction share. - A constitution in a box. 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. Two verticals ## The second vertical shipped as content, not code. ### Shopify DTC Shopify → Klaviyo → Meta → measured lift - Mocked connectors: Shopify, Klaviyo, Meta, GA4 - Abandoned-checkout recovery recipe - Lapsed-customer win-back recipe - Meta seed + suppression audience plan - Holdout-verified lift on ≥500-audience Klaviyo flows ### Cardamom & Rye — local café / bakery POS → email → Google Business Profile → Meta - Square-like POS, Mailchimp-like email, GBP, Meta - Lapsed-regular win-back recipe - Catering upsell recipe - Shared Meta seed + suppression recipe - Audiences below 500 — before/after path, no holdouts - POS coverage disclosure on every card and readout - Catering and Meta never found-money eligible 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. Built in public ## Spec first. Repo open. 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. Launch the live demo → - **Frontend** — Next.js App Router · TypeScript · Tailwind - **Data** — Prisma · SQLite in alpha · Postgres-compatible schema - **Recipes** — Deterministic — no LLM calls in alpha - **Governance** — Operating Rules · Context Ledger · export state - **Tests** — 57-check end-to-end smoke suite - **Spec** — BRD → PRD v1.1 — checked into the repo Talk shop ## Building an agentic CDP? Wiring governance into agents? Curious about the fork? Get in touch →