Skip to main content

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

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

1

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

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

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

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.

​
Why Pre-Compile Beats Runtime

No Runtime Latency

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.

Full Cacheability

Every variant is a distinct, cacheable artifact at the CDN edge. No cache-busting personalization headers. No edge-side includes.

Predictable

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.

Auditable

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.

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

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