Data to Intelligence Architecture
From raw data to agent-driven decisions — ingested through adapters, zero-copy federation and collectors; stored raw on SQL and MPP; abstracted into events, profiles, metrics and relationships; then connected through an ontology for the AI Agent.
Why the four layers matter for an AI Agent
An Agent is only as good as the context it reasons over. Separating ingestion, raw storage, abstraction and the ontology gives the model a clean, governed and connected interface at every level — so its decisions are grounded, explainable and cheap to evolve.
The Agent reads context, not raw rows
Each layer hands the Agent a stable interface — events, profiles, governed metrics and a connected ontology. It reasons over grounded context instead of parsing and joining raw records at inference time, which is what makes its answers repeatable.
Source-independent ingestion
Because collection is its own layer, the model never depends on how a system happens to be connected. Add an adapter, federate a warehouse in place, or push through the open API — everything above sees the same shape of data, so new sources don't touch your prompts or logic.
One consistent substrate
The SQL and MPP stores stay aligned through change data capture, so the Agent's context is backed by a single raw truth rather than drifting copies that disagree. Operational reads and large analytical scans see the same records.
Governed business truth
Metrics carry one authoritative definition in a semantic layer, so the numbers an Agent acts on are the same numbers your dashboards show. Decisions stay explainable and auditable instead of resting on ad-hoc aggregations.
Explicit, traceable relationships
The ontology links intent, profile and business value, so a recommendation can be traced back to the exact context it was built from — the relationships are in the model, not re-derived by the Agent on every call.
Safe to evolve
Swap models, add data sources or change storage behind stable layer contracts. The Agent keeps consuming the same abstractions, so the intelligence on top evolves without a rewrite underneath.
From raw data to a connected ontology
Each layer hands the one above it a cleaner, more governed interface — ingestion, raw storage, abstraction, then the ontology the AI acts on — so intelligence on top evolves without a rewrite underneath.
Data Ingestion Layer
Collect data from enterprise systems with high performance and openness.
Explore this layer →Enterprise-Grade Adapters
Pre-built adapters for mainstream enterprise systems — CDP, CRM, ERP, OMS and commerce.
Zero-Copy Technology
Query large warehouse data in place — no data copy (Snowflake, Databricks, Data Cloud, Delta Sharing).
Data Tracking Collector
Comprehensive web + app event tracking and behavior collection via SDK.
Open Data API / SDK
Standardized APIs and SDKs for any custom source.
Raw Data Layer
Ingest raw data and store it in SQL and MPP databases with real-time CDC sync.
Explore this layer →SQL Database
Structured store for transactions and operations.
MPP Database
Massively parallel processing for large-scale analytics.
Data Abstraction & Understanding Layer
Abstract raw data into meaningful models and insights.
Explore this layer →User Profile & Tagging
Abstract raw data into member tags and build user profiles.
Event Model & Intent Recognition
Abstract raw behavior into event models and infer user intent.
Metrics Extraction & Business Truth
Extract governed metrics from raw data and reveal the business truth.
Relationship & Affinity
Abstract referrals and orders into a member relationship graph — real converted ties, hubs and likely households.
Affinity & Similarity
Model statistical similarity from real data — product co-purchase, category affinity and member lookalikes.
Ontology-Action Layer
Link intent, profile and business through the user entity model and enable agent-driven decisions.
Explore this layer →How a single action becomes a decision
The layers are easier to see in motion. Here is one retail signal moving through all four — from a raw click to an Agent’s next best action.
A shopper's actions arrive
A member views the same jacket three times and adds it to cart, then leaves without buying. Those browse and cart events arrive through the tracking collector, next to her order history from the connected commerce and CRM systems.
Everything lands as raw truth
The events and records are written as raw data into the SQL and MPP stores at once, kept aligned by change data capture — so the same facts are ready for both an operational lookup and a large analytical scan.
Raw data becomes meaning
The event model reads “repeated view + cart, no purchase” as a high-intent signal; tags mark her a lapsing high-value member; the metrics layer already knows her lifetime value and redemption rate — one governed definition each.
The Agent decides
The ontology links her intent, profile and value into one connected picture. The Agent reads that context and decides on a personalized win-back with a bounded incentive — and the decision can be traced back to the exact signals behind it.
Where to plug in
You build against the layers, not the plumbing. Each surface below maps to a stable interface with its own docs — pick where your work starts.
Connect your systems
Bring data in through product adapters, zero-copy federation, or the open data interface — no bespoke pipes.
Integration guide→Track web & app behavior
Capture page views, product views, search and cart events with the collector SDK at the point of interaction.
Web tracking→Read governed metrics & profiles
Query the semantic metrics layer and member profiles through the API and MCP tools — the same definitions everywhere.
MCP & metrics→Extend the model
Push custom sources through the open API, subscribe to outbound webhooks, and model custom objects.
API reference→The questions that decide the architecture
If we standardize on your semantic layer and ontology, how do we avoid lock-in?
The layers are contracts, not a black box. Your raw data stays in standard SQL and MPP stores — or in your own warehouse via zero-copy, which we never require you to copy out — and your metric, tag and identity definitions are declarative, versioned and exportable in a form you govern. You keep the data and the definitions; the abstraction sits on open stores rather than trapping either inside a proprietary format.
Where does our data physically live, and what actually crosses the boundary with zero-copy federation?
For federated sources the query is pushed down to your warehouse — Snowflake, Databricks, Salesforce Data Cloud or Delta Sharing — and read in place under credentials you scope; the raw tables are never duplicated into our store, so your warehouse stays the system of record and its residency and access controls still apply. What leaves your perimeter is a scoped query result, not the underlying tables. Ingested sources land in a tenant-isolated store, and consent and privacy state are versioned so regulated data is handled by policy rather than ad hoc.
Who controls what a metric means, and how is that governed across thousands of users?
Metric definitions live in one governed semantic layer, not scattered across dashboards and notebooks. Each definition has an owner; certified metrics require owner sign-off; a change is reviewed and versioned with an audit trail, and it invalidates its own cache so stale numbers don't linger. That is what prevents the “same KPI, three different answers” problem at organizational scale.
How is our data isolated from other tenants, and what is the blast radius of a single bug?
Tenant scope is enforced in the data path, not left to application code to remember a filter. Metric and profile access runs read-only against tenant-scoped contract views — a security-barrier layer that filters by tenant before any query sees a row — so even a custom query cannot reach another tenant's data or the raw tables. Because isolation is a property of the query path rather than of each developer's discipline, one application bug does not become a cross-tenant exposure.
When the Agent takes an action, how do we audit and constrain it?
Every agent action is grounded in the governed abstractions and the ontology, so a decision traces back to the exact intent, profile and metric context it used — not an opaque prompt. The writes an agent can make are bounded by server-side guardrails and rate limits that fail closed, sensitive actions such as incentives or spend can require human approval, and every action is logged for audit. The agent reasons over your governed truth and stays reviewable, rather than acting on context no one can reconstruct.
Over five years, why is a layered architecture cheaper to own than our warehouse plus point solutions?
The recurring cost of a warehouse-plus-point-tools stack is integration and reconciliation: every new source is a bespoke pipe, every tool redefines metrics and identity, and your team maintains the drift between them. Separating ingestion, storage, abstraction and ontology means a source is connected once, a metric is defined once and identity is resolved once — everything above reuses it. You trade a growing sprawl of brittle integrations and conflicting definitions for one substrate and one set of governed definitions.
Build against connected context, not raw pipes.
Ingest through adapters, zero-copy federation, tracking collectors and an open API/SDK; land raw data in a CDC-synced SQL and MPP store; abstract it into event models, timelines, profiles and metrics; then link it through the user entity model so the Agent decides from connected context.
Related: the platform loop and web tracking SDK.