Completions

For customer-data + growth engineering + AI-platform leadership

Customer cohorts every AI agent reads at runtime — not last Monday’s batch

Weekly batched cohorts do not help an AI agent making a real-time decision. Sub-100ms cohort lookup at every NBA, content, offer, and retention call across the full multi-location stack.

By Jay Christopher11 min read

What this gets you

  • Runtime-readable cohorts (not weekly batched) — sub-100ms lookup per AI agent call, typically 10-30ms at production scale.
  • 5-axis customer-graph pipeline — behavioral signal ingestion, deterministic + probabilistic identity resolution, versioned customer history, LTV math primitives, and the runtime cohort store sitting on top.
  • Cohort drift detection + versioning + lifecycle — definition drift and population drift surfaced as separate alerts before downstream AI-agent decisions corrupt.
  • Cross-banner + per-location + per-vertical cohort policies — one member ID at the spa, the gym, and the restaurant resolves to a unified cohort with per-banner override rules.
  • Audit trail + governance + AI-agent consumption observability — every cohort definition versioned, every agent lookup logged, every decision traceable for compliance review.

AI agents do not consume weekly batched cohorts

Customer cohort analysis is a mature category. Amplitude, Mixpanel, Heap, Pendo, PostHog, June, and FullStory all ship cohort exploration as a dashboard feature. The workflow is built for analysts — define a cohort, refresh the report on a schedule, explore the dashboard, hand-write a brief for the marketing team to act on. The cohort lives in the analytics tool; the decisions happen downstream after a human reads the report.

AI agents do not consume dashboards. A Next-Best-Action agent answering a request at 2:47:13 PM needs the customer’s cohort membership at 2:47:13 PM, not at last Monday’s 6 AM batch refresh. A content- personalization agent serving an in-app recommendation needs cohort state inside the request lifecycle, not pulled from a CSV. An offer-decisioning agent gating a discount needs the lapsed-engagement cohort membership current to within seconds.

The architectural shift is from cohort-as-dashboard to cohort-as-runtime-data-source. The cohort definitions live in a runtime store (vector database, Redis-backed key-value store, materialized view, or specialized feature store depending on scale). Every AI agent call queries the store with a customer identifier and receives the cohort memberships in 10-30ms. The cohort store sits inside the request lifecycle the way a feature flag library does — sub-perceptual latency, fail-open semantics, observable.

Building the cohort store on top of generic product analytics is the wrong shape. Product analytics is built for analyst-batch query patterns, not AI-agent runtime patterns. The 5-axis customer-graph pipeline — Ingest behavioral signals, Resolve identity, Version customer history, Compute LTV, Cohort — is the right shape because cohort is a derived property of the canonical customer record that each AI agent queries in flight.

What is in market — and what each category leaves to you

The cohort analytics layer is mature. The runtime cohort store, the AI-agent consumption protocol, and the drift detection plus governance plus audit-trail layer are operator-side wiring.

Product analytics — Amplitude, Mixpanel, Heap, Pendo, PostHog, June, FullStory

Excellent at cohort definition and dashboard exploration. They are not AI-agent runtime data sources. Query latency is built for analyst patterns; per-customer lookups at agent scale would break the analytical query plan.

CDPs with cohort export — Segment, mParticle, RudderStack, Twilio Engage, Salesforce CDP, Tealium

Strong on identity resolution and event ingestion. Cohort export typically lands as a batched audience segment in downstream activation tools, not as a runtime-queryable surface. The runtime store is operator-built on top.

Engagement-platform cohorts — Iterable, Customer.io, Klaviyo, Braze, Marigold-Liveclicker

Cohorts inside the engagement tool, scoped to that tool. The cohort definitions do not propagate to other AI agents in the stack; each tool maintains its own copy of similar definitions. Drift is the default state across tools.

Open-source / SMB — PostHog, Plausible cohorts, GoodData

Lighter footprint, faster to deploy, similar primitives. Same architectural constraint — cohort is a dashboard query, not a runtime data source.

Each AI agent maintaining its own cohort definitions

The status quo at most operators running AI agents in production. The NBA agent has its cohort definitions; the offer-decisioning agent has its own; the retention agent has its own. The definitions drift, the decisions disagree, and the customer experience contradicts itself across surfaces.

The pipeline, end to end

  1. Behavioral-signal ingestion. Multi-channel behavioral events (clicks, sessions, purchases, support contacts, in-store visits, app opens, email engagement) ingest into the canonical customer-graph schema. Event-level provenance preserved.
  2. Identity resolution. Deterministic matches (email, phone, hashed identifier) plus probabilistic matches (device, geography, behavior fingerprint) resolve events to the canonical customer record with confidence intervals.
  3. Versioned customer history. Every customer-state change captured as a point-in-time snapshot. Cohort membership computes against history as of the lookup timestamp, not as of the latest batch.
  4. LTV math integration. Per-location, per-channel, per-brand LTV (from /ltv-math-primitives) feeds cohort definitions that depend on lifetime value bands.
  5. Cohort-definition DSL. Cohort definitions encoded as machine-checkable predicates over the canonical customer record. Definitions are versioned, reviewable, and replayable.
  6. Runtime cohort store. Cohort memberships materialize into a runtime-queryable store (feature store, materialized view, key-value cache depending on scale). Sub-100ms lookup per AI agent call; 10-30ms typical at production scale.
  7. AI-agent consumption protocol. Every agent call carries a customer identifier; the runtime store returns cohort memberships inside the request lifecycle. Fail-open semantics — if the store is unavailable, the agent receives a default cohort set rather than blocking the decision.
  8. Cohort versioning + lifecycle. Definitions evolve through a reviewable lifecycle (create + propose + approve + promote + retire). Versioned definitions allow point-in-time replay for audit and debugging.
  9. Cross-banner + per-location overrides. A customer active at multiple banners under the same operator carries a unified cohort identity with per-banner override policies. Per-location overrides allow individual franchisees to tune cohort eligibility inside corporate guardrails.
  10. Drift detection. Definition drift (the rule changes) and population drift (the population matching the rule shifts) surface as separate alerts. Drift signals route to operator review before downstream AI-agent decisions corrupt.
  11. Audit trail and governance. Every cohort definition versioned, every agent lookup logged with timestamp + agent ID + customer ID + cohort memberships returned. Compliance review and A/B-test replay both run off the same log.
  12. PII anonymization. Cohort IDs are PII-stripped by default. The agent receives the cohort membership without leaking the underlying identifier into downstream logs or model training data.
  13. Cohort-program ROI measurement.Cohort × NBA × decision × conversion uplift tracked per cohort per agent. The signal feeds cohort-definition tuning so the operator focuses on cohorts that actually move outcomes.

Frequently asked

What is customer cohort analysis?

Customer cohort analysis groups customers by shared behavior or attribute and tracks how each group performs over time. Classic cohorts include signup-month cohorts, first-purchase-channel cohorts, lifecycle-stage cohorts, and behavioral cohorts (users who completed a specific action). Generic product-analytics platforms (Amplitude, Mixpanel, Heap, Pendo) ship cohort analysis as a dashboard feature — users explore cohorts in a UI; reports refresh on a schedule.

Why are weekly batched cohorts not enough?

An AI agent making a real-time decision needs cohort membership at decision time, not at last Monday’s batch refresh. Next-Best-Action agents, content-personalization agents, offer-decisioning agents, and retention agents all query cohort state on every call. Weekly batches produce stale answers that drift through the week and amplify bias toward customers whose behavior is consistent with last week’s patterns. Runtime-readable cohorts close the gap.

How is this different from Amplitude, Mixpanel, Heap, Pendo, or Posthog?

Those platforms own product-analytics dashboards with cohort exploration as a feature. They are excellent for analyst workflow. They are not designed as AI-agent runtime data sources. The runtime cohort store (sub-100ms lookup per agent call), the cohort definition DSL, the drift detection + versioning + lifecycle management, the cross-banner + per-location override policies, and the audit trail for AI-agent consumption are operator-side wiring above the product-analytics layer.

What does runtime cohort lookup actually mean?

Every AI agent call carries a customer identifier. The runtime cohort store accepts the identifier and returns the cohort memberships for that customer in sub-100ms — typically 10-30ms at production scale. The agent uses the cohort memberships to gate the decision (this customer is in the lapsed-engagement cohort so use a win-back offer; this customer is in the high-LTV cohort so route to the human concierge). The lookup happens inside the request lifecycle, not against a precomputed export.

What is the data-fabric quintet underneath this?

Five agents form the load-bearing data-fabric underneath the broader 32-agent catalog: compliance-overlay-manager (regulatory rule library), master-record (location canonical records), catalog-canonicalization (SKU canonical records), rollup-reporting (per-location KPI aggregation), and customer-graph (this pillar — the customer canonical record with behavioral cohorts). Every other agent in the catalog reads from one or more of these five.

How does cohort drift detection work?

Two distinct drift signals. Definition drift — the cohort definition itself evolves (the team changes what counts as "lapsed engagement" from 30 days to 60 days). Population drift — the definition stays stable but the population matching it shifts (the lapsed cohort grows 40% in a week because a different upstream system changed engagement tracking). Both surface as alerts before they corrupt downstream AI-agent decisions. Versioned definitions plus population-size deltas catch each independently.

Hire the agent that runs the customer graph

The customer-data-graph agent owns the 5-axis pipeline (Ingest + Resolve + Version + Compute-LTV + Cohort) and the runtime cohort store every other AI agent in your operation reads from. Joins the data-fabric quintet underneath the broader 32-agent catalog.

Hire the customer-data-graph agent

We scope on the call and send a private checkout link after.

Related reading: Per-location CLV · Location master-record sync