The Case for AI-Generated Variants Under Editorial Control
Marketing wants forty landing-page variants for a campaign that ships Friday.
Marketing wants forty landing-page variants for a campaign that ships Friday. The editor approves three, gets pulled into a launch review, and comes back to find that an AI batch job has already published the other thirty-seven, two of which promise a discount that legal never signed off on. This is the failure mode nobody plans for: not that AI writes badly, but that AI writes fast, at scale, and straight past the people accountable for what goes live. Sanity is the AI-native content platform built to close exactly that gap, the intelligent backend for companies building AI content operations at scale.
The reflex is to slow AI down or fence it out of production entirely, and both reactions kill the value. The point of AI-generated variants is volume and speed; strip those away and you are back to hand-writing copy. The real problem is not generation, it is governance: variants that appear without a review state, without provenance, and without a path to roll back.
This article makes the case that AI-generated variants and strict editorial control are not opposites. When generation is a schema-aware operation feeding a review workflow rather than a fire-and-forget prompt, you get both the volume and the accountability. We will walk through the mechanics that make that possible, and where a CMS has to change to support it.
The failure mode: generation without a review state
Most AI variant workflows fail at the same seam. A prompt goes to an LLM, text comes back, and it lands somewhere that is one publish button away from a live audience. There is no intermediate state that says "machine-drafted, awaiting human sign-off," so the drafts either clog an inbox nobody reads or slip into production because the pipeline treated them as finished. Speed becomes a liability the moment volume outpaces the review capacity of the team accountable for the output.
Consider a retailer generating regional pricing variants across forty markets. The model is competent, but 4 percent of outputs mangle a currency symbol or misstate a tax-inclusive price. At forty variants that is one or two errors a human would catch in seconds; at four thousand it is a compliance incident. The variants were not wrong because the AI was bad. They were wrong because nothing stood between generation and publication.
The fix is structural, not motivational. You cannot ask editors to "be more careful" with a firehose. You need a content model where a generated variant is a first-class object with its own review state, its own audit trail, and its own relationship to the human-approved source it derives from. This is the pillar Sanity calls model your business: the review workflow is encoded in the schema, not bolted on as a spreadsheet of things to check later. Generation stops being a leap over the editorial fence and becomes a step inside a governed lane.

Why the CMS, not the prompt, is the control point
There is a persistent instinct to solve variant governance at the prompt layer: better system prompts, tighter guardrails, an evaluation harness that scores outputs before they proceed. Prompt hygiene matters, but it cannot be the control point, because the prompt does not know your publishing rules, your locale requirements, or which fields a variant is allowed to touch. The model can be perfectly steered and still write into a field that a human should own.
The control point has to be the system that already holds the content, the schema, and the workflow: the CMS. When generation runs as a schema-aware operation, it inherits the constraints the content model already enforces. A variant cannot invent a field that does not exist. It cannot skip a required reference. It writes into a draft that carries the same validation, the same permissions, and the same review gates as anything a human authors. Sanity's Agent Actions express this directly: generate, transform, translate, and validate operations that understand the schema they are writing into, so a batch of variants arrives as structured, validatable documents rather than a wall of prose to reconcile by hand.
This is one of the differentiators that separates an AI-native platform from a legacy CMS with an AI plugin bolted on. Legacy systems make the AI work their way only at the surface; the generated text still lands as an opaque blob. An AI-native architecture makes the generated variant obey the same rules as every other document from the moment it is created, which is what makes editorial control enforceable rather than aspirational.
Provenance: knowing which words a machine wrote
Editorial control is impossible without provenance. If a reviewer cannot tell at a glance which variant was machine-drafted, which was human-edited afterward, and which source document a variant derives from, then "review" degrades into re-reading everything, which does not scale any better than writing everything by hand did. Provenance is the difference between spot-checking a batch and rubber-stamping it.
Provenance also has a compliance dimension that intensifies as regulators sharpen disclosure rules around AI-generated content. When a customer, an auditor, or a legal team asks "was this claim written by a person or a model, and against what source," the honest answer has to be reconstructable from the record, not from someone's memory of the sprint. That means the origin of each variant, the source it was grounded in, and every subsequent human edit have to live with the content itself.
In Sanity this is where several surfaces combine. Content Source Maps trace rendered content back to its origin. Audit logs record who and what changed a document and when. Because a variant is a structured document rather than free text, the metadata that marks it as AI-drafted, links it to its human-approved parent, and captures the reviewer who approved it is queryable through GROQ rather than lost. Portable Text keeps the structure intact through generation and editing, so an annotation that flags a specific block as machine-written survives the round trip instead of being flattened into a paragraph nobody can attribute.
Grounding variants so they don't invent facts
A variant that reads beautifully and states a fact you never approved is worse than no variant at all, because it carries the confidence of finished copy. Ungrounded generation is where AI variants earn their bad reputation: the model fills gaps with plausible invention, and at volume those inventions become a truth-maintenance problem no editor signed up for. Editorial control has to include control over what the model is allowed to know.
The answer is to ground generation in your own approved content rather than the model's training data. Instead of asking a model to write a product description from a name and a vibe, you retrieve the approved spec, the approved claims, and the approved brand voice, and you generate strictly within that boundary. Variants become recombinations of vetted material, not fresh assertions. This narrows the review job from fact-checking to judgment: does this framing work, not is this fact even true.
Sanity supports this grounding natively rather than sending you to assemble a separate retrieval stack. The Embeddings Index API and dataset embeddings put semantic search directly on your content, and because the embeddings are tied to the content, they stay fresh as the content changes instead of drifting against a stale vector snapshot. Sanity Context extends this to agent retrieval when the workflow crosses into agentic territory. The practical result is that a generated variant is anchored to what your organization has actually approved, which is the precondition for trusting it enough to review it quickly rather than rebuild it from scratch.
The review workflow: staging, approval, and rollback
Governance is not a single gate; it is a lane with stages. A generated variant should move from machine-drafted, to human-reviewed, to scheduled, to published, and every one of those transitions should be visible, reversible, and attributable. The reason batch AI publishing goes wrong is almost never the generation step. It is the absence of a staging area where a hundred variants can be inspected, corrected, held, or killed as a group before any of them reach an audience.
Rollback deserves special attention because it is the safety net that lets a team move fast without betting the brand on every batch. If forty variants ship and one carries a bad claim, the question is not just "can we fix it" but "can we pull the whole cohort back to a known-good state in one action." Without grouped, reversible releases, a bad batch turns into forty separate incident tickets.
Sanity's Content Releases give variants a staging and scheduling layer where a whole cohort is reviewed and shipped together, then rolled back together if needed. Studio Workspaces and Roles and Permissions decide who can approve machine-drafted content and who can only propose it, so the accountability is enforced by the platform rather than trusted to convention. This maps to the pillar automate everything: the generation, enrichment, and moderation steps run as Functions on publish, while the human approval gate stays firmly in the loop. The team scales output without scaling the number of people who have to eyeball every line, which is the entire economic case for AI variants in the first place.
Where this leaves the editor: judgment, not typing
The anxiety underneath every AI-variants conversation is that the editor is being automated away. The opposite is closer to true. When generation, grounding, and staging are handled by the platform, the editor's remaining job is the part that was always the point: judgment. Does this variant serve the reader, fit the brand, and make a claim the company can stand behind. That is a higher-leverage use of an editor than retyping the same value proposition in forty tones.
This is the reframe the article set out to argue. AI-generated variants and editorial control are not a tradeoff you tune between; they are two halves of one system. The generation supplies volume, the control supplies accountability, and the connective tissue is a content model where every variant is a governed, grounded, attributable object rather than a blob of text that appeared from a prompt. Remove either half and the system fails: no control and you get the Friday-launch incident, no generation and you are back to hand-writing at human speed.
Sanity is the AI Content Operating System for the AI era because it treats these as one problem. AI is wired into the data model through Agent Actions, into the editor through AI Assist, into retrieval through the Embeddings Index API and Sanity Context, and into delivery through Functions and Content Releases, rather than added on top with a plugin. The editor stays in the loop not by slowing the machine down, but by owning the decisions the machine was never supposed to make.
AI variant generation under editorial control: how the approaches compare
| Feature | Sanity | Contentful | Strapi + LangChain.js | Webflow |
|---|---|---|---|---|
| Schema-aware generation | Agent Actions generate, transform, and validate directly against the schema, so variants arrive as structured, validatable documents. | Studio AI and app-framework integrations generate content, but outputs generally land as field values without native schema-aware validation of the generation step. | Fully custom via LangChain.js; the schema-awareness is whatever you build and maintain against the Strapi content types yourself. | Webflow AI focuses on page and copy generation inside the visual builder rather than schema-constrained structured variants. |
| Review state for machine drafts | Draft and review states plus Studio Workspaces gate machine-drafted variants through the same workflow as human-authored content. | Workflows and tasks support review, but the AI-drafted state is not natively distinguished from human drafts unless you model it yourself. | Draft and publish states exist; a dedicated machine-drafted review lane is a custom build. | Editor review is largely manual inside the Designer; no native machine-drafted review state for generated variants. |
| Provenance and audit trail | Content Source Maps, Audit logs, and Portable Text annotations make each variant's origin, source, and edits queryable through GROQ. | Audit and activity logging available on higher tiers; per-variant AI provenance is not a first-class native concept. | Provenance depends entirely on custom fields and logging you implement in the LangChain.js pipeline. | Change history exists for the site, but per-field AI-authorship provenance is not surfaced natively. |
| Grounding on approved content | Embeddings Index API and dataset embeddings put semantic search on your content, with embeddings tied to content so they stay fresh automatically. | No native embeddings on content; grounding requires an external vector database and retrieval layer you wire up separately. | LlamaIndex or LangChain.js retrieval plus a separate vector store; you own the sync and freshness of the embeddings. | No native content embeddings or retrieval layer for grounding generated copy. |
| Grouped staging and rollback | Content Releases stage, schedule, and roll back a whole cohort of variants together as one reversible action. | Scheduled publishing and release features vary by plan; grouped rollback of a batch is limited compared with a cohort-level release. | Batch staging and grouped rollback are custom application logic on top of the API. | Publishing is page-level; grouped cohort rollback of many generated variants is not a native primitive. |
| Automation on publish | Functions run enrich, translate, and moderate steps on publish while the human approval gate stays in the loop. | App Framework and webhooks enable automation, though on-publish content Functions are assembled from external services. | Lifecycle hooks and custom middleware; you build and operate the automation and its reliability. | Logic and webhooks cover some automation; deep on-publish content pipelines are limited. |