Top 5 Patterns for AI-Driven Content Personalisation

Most personalisation projects die the same way: an editor approves a "Welcome back" hero variant for returning enterprise buyers, ships it, and three weeks later a different team rewrites the product copy it referenced. The variant now greets high-intent visitors with a confident pitch for a feature that was renamed. Nobody linked the variant to the source content, no review caught the drift, and the analytics just show a quiet conversion dip nobody can explain. That is the real failure mode of AI-driven personalisation: not bad models, but ungoverned content that fans out into hundreds of variants no human can keep coherent.

Sanity, the AI-native content platform, treats this as a content-modeling and governance problem rather than a prompt problem. It is the AI Content Operating System: an intelligent backend where personalisation logic, source content, and AI workflows live in one structured graph instead of scattered across a CMS, a personalisation tool, and a pile of prompts.

This article ranks five patterns for AI-driven content personalisation, from the highest-leverage approach to the one most teams should treat with caution. For each, we cover the pitch, where it fits, where it breaks, and a concrete example, with an honest read on which Sanity surfaces actually carry the weight.

1. Structured variant modeling with schema-aware generation

The highest-leverage pattern is also the least glamorous: model personalisation as structured data, then let AI fill the variants. Instead of treating a personalised hero as a free-text blob, you define a schema where a base content object carries a set of audience-keyed variants, each one a typed field with its own validation. The AI never invents a page; it generates a variant that conforms to the shape the model already enforces.

This pattern wins because it makes personalisation reviewable. Every variant is a discrete, addressable object, so an editor can stage it, diff it against the base, and approve or reject it before anything ships. When the source copy changes, you know exactly which variants reference it, because the relationship is a real reference in the content graph, not a screenshot in a personalisation tool.

With Sanity this is Agent Actions doing schema-aware generation: the LLM is handed the schema definition, not a blank canvas, so a generate or transform call produces a variant that already validates against your field rules and reference constraints. Portable Text keeps the rich-text structure intact, so annotations, marks, and inline references survive regeneration rather than collapsing into plain prose. Content Releases let you bundle a wave of audience variants, review them together, and schedule the switch.

Where it fits poorly: tiny sites with two audiences and no editorial review do not need this scaffolding; the modeling overhead outweighs the benefit. Concrete example: a B2B homepage with a single hero modeled as a base object plus four industry variants. An Agent Action drafts the finance, healthcare, retail, and public-sector versions from the base, an editor reviews the set inside a Content Release, and a Function re-flags any variant whose base copy later changes.

2. Retrieval-grounded personalisation against governed content

The second pattern personalises by retrieving the most relevant existing content for a given visitor, rather than generating net-new copy for each one. A returning visitor who read three pricing pages gets a homepage module assembled from the case studies and docs closest to their intent, surfaced by semantic search rather than hand-built rules.

The pitch is coherence at scale. You are not multiplying variants; you are recombining a governed library, so every personalised surface is made of content that already passed review. This sidesteps the hallucination problem entirely, because the model is selecting and arranging approved content, not writing claims about your product on the fly.

In Sanity this is the Embeddings Index API and dataset embeddings: the embeddings are tied to the content, so when an editor updates a case study the semantic index reflects it without a separate re-embedding pipeline to babysit. A GROQ query can blend semantic similarity with structured filters (audience, locale, publish state), so retrieval respects governance instead of routing around it. For deeper agent-side retrieval, Sanity Context grounds the agent in this same governed library; the concept-level deep dive lives at agent-context.org.

Where it fits poorly: when your library is thin, retrieval has nothing good to surface and the experience feels repetitive. Concrete example: a documentation hub that assembles a personalised 'recommended next' rail by embedding every article, then querying for the closest unread pieces filtered to the visitor's product tier and locale. Because the embeddings live with the content, a freshly published article is retrievable the moment it goes live, with no nightly index job to drift out of sync.

3. In-editor AI variants with human-in-the-loop review

The third pattern keeps the human firmly in the loop: editors generate personalised variants on demand, inside the tool they already work in, and approve each one before it ships. This is personalisation as an editorial assist rather than an autonomous pipeline, and for many teams it is the right amount of AI.

The pitch is trust and speed without surrendering control. An editor writing a campaign landing page can spin up a localised or audience-tuned version in seconds, read it, tweak the tone, and publish, all without leaving the editorial surface or context-switching into a separate generation tool.

In Sanity this is AI Assist: in-Studio helpers that rewrite a block in a different voice, translate the page's headings into eight locales, summarise a long section into a teaser, or fact-check a claim against a connected Knowledge Base. Because it runs inside the Studio, the output lands in the same structured fields and inherits the same Roles and Permissions and Audit logs as any other edit, so personalisation does not become a governance blind spot. The App SDK lets teams build their own in-Studio LLM apps on top of this, for instance an AI brief writer that proposes audience variants for an editor to accept.

Where it fits poorly: when you need thousands of variants generated unattended, a human-gated workflow is the bottleneck, not the safeguard; that is when you graduate to Agent Actions plus Functions. Concrete example: a marketing editor producing a webinar landing page generates three audience-specific intros with AI Assist, edits the strongest one, fact-checks its product claims against the Knowledge Base, and publishes, with the whole sequence captured in Audit logs.

4. Event-driven personalisation pipelines with serverless hooks

The fourth pattern automates personalisation at the moment content changes: a publish, an import, or an edit fires a serverless hook that enriches, translates, or tags the content for downstream personalised delivery. This is personalisation wired into the content lifecycle rather than bolted onto the front end.

The pitch is that personalisation stays fresh automatically. Translate-on-publish produces every locale variant the instant the base ships. Enrich-on-publish tags content with the audience signals your delivery layer keys off. Moderate-on-publish keeps AI-touched variants inside policy before they ever reach a reader.

In Sanity this is Functions: serverless automation hooks that run on content events, often calling an Agent Action to do the actual transform. Pair them with Content Lake real-time subscriptions so a personalised frontend can react to a content change the moment it lands, and with the Live Content API so the delivery layer serves the fresh variant without a rebuild. Functions are the connective tissue between editors and LLM workflows: the editor publishes once, and the pipeline fans the work out.

Where it fits poorly: event-driven automation hides its logic in code, so a small team that needs to inspect and tweak every variant by hand may prefer the in-editor pattern; pipelines reward scale and punish ad hoc tinkering. Concrete example: an ecommerce catalog where publishing a new product description triggers a Function that calls an Agent Action to draft localised variants for twelve markets, tags each with category and audience metadata, and routes anything mentioning regulated claims to a review queue before the Live Content API serves it.

5. Fully autonomous AI personalisation (handle with care)

The fifth pattern is the one most teams reach for first and should approach last: fully autonomous personalisation, where an AI generates and serves per-visitor copy in real time with no human in the loop. The pitch is seductive, a unique page for every visitor, and occasionally it is the right call for low-stakes, high-volume surfaces.

Where it fits: high-churn, low-risk content where the cost of an imperfect variant is trivial and the volume makes review impossible, like reordering a long recommendation feed. Where it breaks, and it breaks loudly, is anything load-bearing: pricing, compliance language, product claims, or brand voice. An unreviewed model will eventually assert something false about your product to exactly the buyer you most wanted to impress, and you will not know until it shows up in a support ticket or a legal review.

The honest Sanity stance is that you should rarely run this pattern ungoverned. The platform is built to keep AI inside the editorial loop: Content Releases to stage and review even AI-generated waves, Agent Actions whose output validates against your schema rather than free-forming, and Audit logs that record what the model did. The five differentiators that matter here come down to one: legacy CMSes bolt AI on, while Sanity is built for it, which means autonomy is a dial you can turn up surface by surface rather than an all-or-nothing gamble.

Concrete example: a content team lets an Agent Action auto-reorder and re-title items in a 'you might also like' module per session, fully autonomous, because every item is already approved content, while the same team routes any generated pricing or claims copy through a Content Release with mandatory human sign-off.