> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gradial.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Personalization

> How ACI enables native personalization through pre-compiled variants and edge routing.

Most personalization engines work client-side, intercepting requests, calling a decision service, and assembling pages on the fly. This adds latency, complexity, and a client-side dependency that is difficult to cache or debug.

Agentic Content Infrastructure (ACI) takes a different approach, building on the same pre-compile architecture that powers the rest of the platform.

## The Pre-Compile Model

ACI's content compiler already produces validated, self-contained payloads for every page. Personalization extends this by compiling **multiple variants** of each page, one per audience segment, locale, or campaign.

```mermaid theme={null}
flowchart TD
    A["Page: /products/shoes"] --> B["Content Compiler"]
    B --> C["Variant: Default"]
    B --> D["Variant: Returning Customer"]
    B --> E["Variant: New Visitor"]
    B --> F["Variant: Enterprise Buyer"]

    C --> G["CDN Edge"]
    D --> G
    E --> G
    F --> G

    G -->|"route by user data"| H["User sees\nright variant"]

    style B fill:#6366f1,color:#fff
    style G fill:#22c55e,color:#fff
```

Every variant is a complete, pre-rendered artifact, just like any other page in ACI. It goes through the same validation, the same compilation, the same staging pipeline. There's no runtime content assembly.

## How It Works

<Steps>
  <Step title="Authors create variants">
    Content authors (or AI agents) create variant content for a page. A product page might have different hero copy for new visitors vs. returning customers. Each variant is a content overlay: a small set of field overrides, not a full page copy.
  </Step>

  <Step title="Compiler produces variant payloads">
    The content compiler resolves each variant into a complete, self-contained payload. Every variant is validated against the same component schema. Every variant goes through reference resolution and dependency tracking.
  </Step>

  <Step title="All variants are staged">
    At publish time, all variants are rendered and staged to the CDN. This is a static operation. No runtime computation is needed to serve any variant.
  </Step>

  <Step title="Edge routes to the right variant">
    When a user requests a page, an edge function determines which variant to serve based on user data (cookies, location, device, behavioral signals). The edge function is a simple router. It picks a pre-computed variant, not a runtime-assembled page.
  </Step>
</Steps>

## Why Pre-Compile Beats Runtime

<CardGroup cols={2}>
  <Card title="No Runtime Latency" icon="bolt">
    Every variant is pre-rendered static content. Serving a personalized page is as fast as serving a static page, because it is a static page.
  </Card>

  <Card title="Full Cacheability" icon="database">
    Every variant is a distinct, cacheable artifact at the CDN edge. No cache-busting personalization headers. No edge-side includes.
  </Card>

  <Card title="Predictable" icon="check-double">
    What authors create is what users see. No runtime assembly that might combine fragments in unexpected ways. Every variant is previewed, validated, and approved before it goes live.
  </Card>

  <Card title="Auditable" icon="scroll">
    Every variant has a version history and an audit trail. You can see who created it, when, and why, whether it was a human editor or an AI agent generating A/B test variants.
  </Card>
</CardGroup>

## Agents and Personalization

The pre-compile model pairs naturally with AI agents. An agent can:

1. Analyze audience segments and identify variant opportunities
2. Generate tailored copy for each segment in a draft workspace
3. Preview every variant to verify quality
4. Submit all variants for review and merge them to main, ready for a single publish

Where a human editor might manage 2-3 variants per page, an agent can generate and manage dozens, covering long-tail segments that would be impractical to handle manually.

<Info>
  Storage and delivery cost for variants is marginal. Cloud storage and CDN costs are inexpensive. The constraint is content quality, not infrastructure, which is why agent-generated variants go through the same validation pipeline as any other content.
</Info>

## Audience Resolution

At the edge, ACI determines which variant to serve using configurable audience resolution. User signals (first-party cookies, geolocation, device type, behavioral data) map to audience segments. Each segment maps to a content variant.

The resolution logic runs at the CDN edge in milliseconds. It's a lookup, not a computation. The hard work of generating and validating variants happened at compile time.

***

*Next: [Agent-Native Design →](/aci/architecture/agent-native-design)*