Inside CleverAI™: The Technology Stack Behind Live 1:1 Personalization

A component-level walkthrough of the CleverAI™ stack: the per-user decisioning engine that ranks an action inside a single request, and the agentic automation that supplies its candidates, executes its output, and operates the loop around it. Live 1:1 personalization requires both, and the hard problems span the model, policy enforcement, and the real-time data path.

Live 1:1 personalization is usually framed as a ranking problem: given a user and a set of candidates, pick the best one. The candidate action space includes campaigns, channels, cadence, and timing. 

CleverAI™ is built as two coupled systems: a decisioning engine that makes the per-user selection, and an agentic layer (AI Studio) whose agents generate the candidates, execute the decision through campaigns and journeys, and keep the system pointed at the business goal.

On the model side: a policy that selects per user has to encode long-horizon behavior (purchase cadence, lifecycle stage, multi-year campaign response) learned offline over event-level history, while an online learner corrects for drift – the session, the new category, the engagement drop the prior didn’t see – updating on each outcome and directing exploration where confidence is lowest, without discarding the prior or overfitting a single event.

On the system side, three constraints shape the design: (1) maintaining per-user context that changes with every event, across hundreds of millions of users, with sub-request read latency; (2) evaluating a large candidate space against hard constraints (frequency caps, eligibility, goal alignment) per request; and (3) closing the reward loop fast enough that the policy reflects the last interaction, not the last retrain. 

The agentic layer adds a fourth: every agent action must be governed (approvals, role-based access) and must draw its decision from the same policy rather than an isolated prompt, or intelligence fragments across agents. 

Key Components of the CleverAI™ Live Architecture

• AI Studio hosts the agents and agent harnesses. Agents operate every layer: they read and write TesseractDB™, direct Creators and Experts to produce candidates, call the Tesseract Decisioning Engine™ for the actual selection, and drive Experience Builder to execute. Agent actions are gated by human-in-the-loop (HITL) approvals and RBAC.
• TesseractDB™ is a single real-time feature store that holds both live event state and up to 10 years of history per user. The Offline Learner and the Online Learner read from the same store, so there’s no sync boundary between “recent” and “historical” context.
• The Tesseract Decisioning Engine™ is a hybrid policy: an offline-trained prediction model bootstraps an online learner with reinforcement that updates per interaction.
• Candidate actions come from two upstream sources – Creators (content variants, with embeddings) and Experts (specialized models for recommendations, predictions, timing, channel, and sequence).
• Guardrails are hard constraints applied inside the decision step, not a post-filter. The output is a best valid action, not a best action that later gets rejected.
• The Clean Room extends the feature space with embeddings computed inside a customer’s environment (or via split learning), so regulated attributes contribute to ranking without leaving that environment.

Inputs: Goal, Strategy, Guardrails

At the top of the architecture is the control plane. A marketer specifies a business goal (positive signals such as checkout or add-to-cart; negative signals such as uninstall or subscription cancellation), a strategy, an audience boundary, and guardrails. Frequency caps and touch-point caps are layered as separate constraints on top of the goal.

These inputs fan out to two consumers. TesseractDB™ receives the audience boundary and goal events so segments and derived features are computed against them. AI Studio receives the full goal, strategy, and guardrail set as the objective its agents plan against. Every candidate is scored against the marketer-defined objective and checked against constraints before ranking completes.

AI Studio

AI Studio is the agentic automation layer interacting with the other layers in the stack. It hosts the following

• Agents: Goal-driven processes that own an outcome. Lifecycle Agents continuously optimize content and sequence toward a milestone such as first purchase or KYC completion. One-time and drop-off campaign agents handle calendar sends and funnel abandonment. Custom Agents (Foundry) let a team encode its own use case, such as a campaign performance-based agent on the same infrastructure. 
• MCP Server & Skills: The tool surface agents call. Read tools (analytics, segments, campaign history), write tools (create or modify campaigns, journeys, segments), and evaluate tools (performance reads, estimates). The same is exposed externally, so a customer’s own assistant can drive the platform through the same contract 
• Controls: HITL approval gates on agent writes, and RBAC scoping what each agent may read or change.

Data Layer: TesseractDB™ as the Feature Store

TesseractDB™ is a purpose-built store (12+ patents) whose job is serving per-user context to the decisioning engine at request time. It holds, per user, in one store:

• Live behavior: The event stream as it arrives.
• Long-range history: Up to 10 years of events, not sampled or rolled up.
• Profile state: Attributes and their current values.
• Campaign responses: Every prior delivery and its outcome.
• Derived features: Computed features and pipeline outputs.

The defining choice here is a unified data store. Traditional architectures separate history (via a warehouse/CDP) from live state (via an operational store). This forces ranking models to either suffer network-join latency at request time or accept stale context. Because both the Offline Learner and the Online Learner read from TesseractDB™, the output of one decision (the campaign-response event) is written back and available as input to the next.

Clean Room: Extending the Feature Space Without Moving Data

Some of the highest-value features – internal risk scores, transaction-level attributes, records under residency constraints – cannot be exported to a third-party customer engagement platform due to data privacy and security concerns. The Clean Room handles these by running goal-oriented computation inside the customer’s environment and returning non-reversible embeddings: dense vectors that are useful as model inputs but cannot be inverted to recover the underlying attributes.

The deeper variant is split learning: model layers train jointly with a customer-side model on data that stays in place, exchanging embeddings and activations across the boundary rather than records. The ranking model gets the benefit of the customer’s proprietary signal; the raw data never crosses.

Candidate Generation: Creators and Experts

Two upstream layers produce the candidate set via AI Studio

Creators generate content variants – copy, images, templates, offers, experience variants – within brand rules. From the engine’s perspective, each variant is a candidate action with a campaign-side feature vector. Rather than hand-tagging campaigns with a fixed schema, CleverAI™ embeds campaign content into a high-dimensional space that captures tone, topic, offer type, urgency, visual characteristics, and similar properties as learned dimensions, then concatenates that with structured campaign metadata (audience definition, goal type, channel, time window).

Experts are specialized models that contribute domain-specific scores and constraints: recommendations (product/catalog), predictions (propensity to convert, churn, and so on), best send time, best channel, and sequence intelligence (path optimization). These aren’t separate decision engines; they’re feature and score providers the engine consumes for the relevant decision type.

Decision Layer: Tesseract Decisioning Engine™

The engine takes five inputs per request – context (from TesseractDB™ and the Clean Room), choices (from Creators), expert scores (from Experts), the goal, and the guardrails – and emits one output: a best valid action. The action space includes message, offer, channel, timing, sequence, product experience, or no action.

The Offline Learner

An extension of CleverTap’s production prediction system. It operates on profile attributes, behavioral actions, propensity scores etc pushing user-side dimensionality into the thousands. This model is trained offline on long-range history and provides the prior that bootstraps the online policy, so day-one decisions start from learned patterns rather than uniform exploration.

The Online Learner

A reinforcement-learning policy that learns the association between the user-side vector (attributes, behavioral history, prior campaign interactions, real-time events, time-series sequences) and the campaign-side vector, producing a score for whether a specific user will respond to a specific candidate.

Two properties define it:

1. It is online. The output of each decision is an input to the next. There is no frozen training cycle; the policy updates its beliefs on each observed outcome and is designed to continuously beat the prior average rather than converge to a fixed winner.
2. It is per-user, not per-cohort. A standard multi-armed bandit reallocates traffic across variants at the population level – dynamically, but still a group-level mechanism. A contextual bandit conditions on the individual’s context before selecting, which is what makes 1:1 selection possible rather than segment-level optimization.

AI Experimentation as a First-Class Use Case

Each decision carries a confidence distribution over the candidate set for that context. Exploration budget is allocated where confidence is low rather than uniformly, and outcomes update the policy immediately. 

Conventional A/B testing is sequential and memoryless – one hypothesis, one population-level winner, months per matrix, nothing carried into next quarter’s version of the same campaign. The engine runs the matrix continuously and in parallel, and because candidates are represented as embeddings (tone, offer type, urgency, channel, timing) a new campaign that shares a theme with a past one inherits the prior. Recurring themes – payday offers, cart reminders, festive discounts – are exploited from the first request; exploration is spent only where the engine is genuinely uncertain: a new theme, an untested channel-context pair, a segment that has never seen this offer type.

Constraint Handling

Guardrails enter the decision as constraints on the feasible action set: per-channel frequency caps, global caps, caps by team or label, and audience boundaries. The engine ranks over the feasible set, which is why the output is a valid action by construction rather than a top-ranked action that a downstream filter may discard.

Execution Layer: Experience Builder

The engine’s output is committed through Experience Builder – campaigns, journeys, channels, product experiences, rewards, and workflows. Delivery and performance data are written back directly.

The architectural point is that there is no product boundary between the decision and its execution. Any such boundary reintroduces a sync and a delay, and the outcome signal that should update the online learner arrives late or not at all. Experience Builder’s outputs are the primary source of fresh reward signal for the policy.

The Feedback Loop

This is the layer with Customer outcome > learning > next decision in the architecture. Every delivered action produces an outcome event; that event lands in TesseractDB™ as a campaign response, updates the online learner, and is available as context on the next request for that user. 

The definition of “live” that this architecture targets is specific: the decision, the context it was made on, and the outcome it produced are never separated by more than one request cycle.

Trust, Security, Explainability, Governance

CleverAI^TM has been designed in a way that trust, security, and governance do not sit at the end of the architecture as an approval box. They operate across it.

Per-decision explainability, marketer-defined guardrails, frequency controls, RBAC, human-in-the-loop (HITL) approvals, full audit trails, and user-level inspection apply at every layer. This is what lets the system’s autonomy increase without the decision function becoming opaque.

Technical Summary