← 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.

Ago's core loop: find money, draft, approve, activate, measure, learn — one human gate at approve, a 10% holdout keeping measure honest. THE CORE LOOP Six stages run themselves. One waits for a person. 10% holdout Scan accounts, spend and signals for the next dollar worth moving. 1 Find money scan for opportunity The system drafts the plan, the audience and the creative — nothing ships yet. 2 Draft plan + creative The one human gate: money moves only after a person signs off. HUMAN SIGN-OFF 3 Approve the human gate Approved work goes live across channels — no hand-offs. 4 Activate ship across channels Results are read against a 10% holdout that never sees the campaign. 5 Measure vs. the 10% holdout Holdout deltas feed back in — the next loop starts smarter. 6 Learn feed the next pass AGO the system of decision every stage runs itself — stage 3 waits for you the loop never stops — it just pauses, once, at the gate
  • 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
  • 6 stages in the loop
  • 3 measurement labels
  • 2 verticals, one core
  • 57 smoke-suite checks
01 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

02 The loop

Find money.
Prove it moved.

  1. Find money. A ranked opportunity feed — abandoned checkouts, lapsed customers, upsell candidates — dollar-estimated where the estimate is defensible, labeled where it isn't.
  2. 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.
  3. 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.
  4. 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.
  5. Measure. A holdout is assigned where exclusion is enforceable; everywhere else the readout carries an honest label instead of a lift claim.
  6. Learn. Outcome, approval, and Operating Rules version land in the Context Ledger — the working memory the next recommendation reasons from.
03 Three weeks

Three weeks separate
the name from this alpha.

  1. Jun 15, 2026 Named

    Hightouch calls the category "Agentic CDP". A label exists; a market starts forming around it.

  2. Jun 16, 2026 Enterprise ships

    Databricks launches CustomerLake at its biggest conference of the year — for enterprises with lakehouses.

  3. Jun 22, 2026 Press verdict

    The trade press calls it "ready or not." Seven days from the name to the verdict.

  4. 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.

  5. Jul 7, 2026 The alpha

    One operator, three deterministic recipes, native holdouts, two verticals. Repo public. The fourth architecture exists.

04 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 agentic-CDP fork: embedded, layered and headless all assume a warehouse — the federated fourth cell sits over the merchant's own stack, keeps only governed working memory, and lets the state leave at any time. THE AGENTIC-CDP FORK Three assume a warehouse. The fourth doesn’t. Embedded — the agent lives inside the data platform: Databricks’ bet that the warehouse is the CDP. EMBEDDED Databricks agents live insidethe warehouse Layered — an activation and decisioning layer on top of the customer’s warehouse: Hightouch’s bet. LAYERED Hightouch decision layer on topof the warehouse Headless — the CDP becomes the backend and agents become the interface: Treasure Data’s bet. HEADLESS Treasure Data CDP as backend,agents as the UI Federated — this product: no warehouse assumed, the decision layer sits over the merchant’s existing SaaS stack. FEDERATED · THIS PRODUCT AI Growth Operator sits over the SaaS stackit doesn’t own The only state the product keeps: customer context, the versioned constitution (Operating Rules), the Context Ledger, and holdout state — not a second customer record. GOVERNED WORKING MEMORY context · constitution (Operating Rules) · ledger · holdout state Everything the product holds leaves with the merchant — context, audiences, Operating Rules, learned preferences. No hostage state. EXPORT at any time — no hostage state reads from · writes back Shopify, Klaviyo, Meta — the product reads from these systems and activates through them; it does not replace them. Shopify Klaviyo Meta THE MERCHANT’S SAAS STACK The system of decision sits over the stack. It doesn’t replace it.
05 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.

The AGO system map: five sources in, one governance gate down, one context ledger remembering everything. AGO SYSTEM MAP Every path runs through one gate. Every decision lands in one ledger. Sources: Shopify, Klaviyo, Meta, GA4, Stripe — plus the local pack (Square-like POS, Mailchimp-like email, Google Business Profile) ghosted in. Each connector is mocked in Alpha; each sync is a SyncRun row. SOURCES + local pack Shopify Klaviyo Meta GA4 Stripe Square Mailchimp GBP Sync and freshness gate: every source carries a SyncRun and a DataFreshness reading; stale data blocks estimates before anything downstream ever sees it. SYNC + FRESHNESS GATE · stale sources don’t get a vote Context layer — governed working memory: customer context (events, profiles, audiences), the constitution (versioned operating rules the merchant approved), and preferences learned from feedback via the ledger. CONTEXT LAYER · GOVERNED WORKING MEMORY Customer context events · profiles · audiences Constitution vX versioned operating rules Preferences learned from feedback Opportunity engine: three deterministic DTC recipes — abandoned checkout recovery, lapsed win-back, Meta seed suppression — RecipeInput in, RecipeResult out, no side effects. The local pack’s two recipes ghosted beside them; the Meta recipe is shared. OPPORTUNITY ENGINE · DETERMINISTIC RECIPES abandoned checkout recovery recover the almost-lost lapsed win-back wake the gone-quiet meta seed suppression stop paying to re-reach buyers LOCAL PACK local lapsed regular catering upsell Governance runtime — the single gate: consent, suppression, budget, discount, margin, approval, banned claims, freshness. lib/server routes every activation through lib/governance before touching a connector. There is no code path around this wall. GOVERNANCE RUNTIME consent · suppression · budget · discount margin · approval · banned claims · freshness there is no code path around this wall lib/server → lib/governance → connector ONE GATE Activation fallback ladder: Klaviyo flow draft → Klaviyo campaign draft → exportable brief → manual setup instructions — plus the Meta audience sync side-channel. Draft is not activation; approval comes first (26A.4). ACTIVATION · FALLBACK LADDER draft ≠ activation · approval first Klaviyo flow draft Klaviyo campaign draft exportable brief manual setup Meta audience sync side-channel Measurement / Prove-It: randomized customer-level 10% holdout — eligible audience ≥500, Klaviyo flows only — and exactly three labels: holdout-backed, before/after with no control, directional. Meta is always directional; it never claims lift. MEASUREMENT · PROVE-IT 90% treated 10% holdout randomized · ≥500 · Klaviyo flows only holdout-backed before/after · no control directional (Meta) exactly three labels — Meta never claims lift Context ledger: an append-only spine — every band writes its decisions, activations, approvals and readouts here. One ledger; nothing is forgotten. CONTEXT LEDGER append-only · every band writes one gate, one ledger — no path around either. ui calls server, server calls modules, modules speak only contracts — and lib/server routes every activation through lib/governance and every decision through lib/ledger
  • 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.

06 Trust engine

The product
ships its own audit.

The trust gate: three measurement tracks — directional, before/after, and holdout-verified — and only one earns the word lift. THE TRUST GATE Every claim rides a track — only one track earns the word “lift.” THE MEASUREMENT YARD · EVERY ACTION ENTERS ON THE LEFT an action enters 1 owned channel + enforceable exclusion? no yes 2 eligible audience ≥ 500? no yes 90/10 split 90% exposed 10% holdout Δ DIRECTIONAL Meta-styled · signal, not proof no lift claim allowed BEFORE / AFTER no control group trend read only HOLDOUT-VERIFIED lift = [ low — high ] always a range, never a point the yard does not judge the campaign — the switches decide which claim is allowed to leave it Measured lift, not vendor math — and when we cannot prove it, we say so. switch 1: can anyone be excluded? · switch 2: are there enough people to randomize?
  1. 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.
  2. Three measurement labels. Every report carries exactly one: holdout-verified, before/after with no control group, or directional. There is no fourth state.
  3. 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.
  4. 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.
  5. 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.
07 Two verticals

The second vertical shipped
as content, not code.

Verticals are content packs: one Operator core, and every vertical docks as a cartridge — a dataset, a constitution, a few recipes. VERTICALS ARE CONTENT PACKS One Operator core. Every vertical docks as a cartridge. Shopify DTC VERTICAL PACK · DOCKED dataset catalog · orders constitution brand rules recipe abandoned cart recipe winback recipe product drop docked Operator one core context opportunity lifecycle paid creative offer measurement shared skill ring — never forked per vertical Cardamom & Rye VERTICAL PACK · DOCKING dataset menu · covers constitution house voice recipe weekly special recipe event push coverage disclosure docking next vertical next vertical second vertical: a dataset, a constitution, two recipes, a registry entry — zero re-architecture.
  • 01

    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
  • 02

    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.

08 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 →