How to Integrate GPT or Claude Into Content Workflows

You wire GPT or Claude into your content workflow, ship a demo that dazzles in the meeting, and two weeks later it confidently tells a customer a discontinued product is in stock. The model was not lying so much as guessing, because nobody gave it a fresh, governed view of your actual content. This is the failure mode that kills most CMS-plus-LLM projects: the integration works until the content moves, and content always moves.

Sanity is the Content Operating System for the AI era, the intelligent backend for companies building AI content operations at scale, and it treats GPT and Claude as first-class consumers of your content rather than bolted-on extras. The distinction matters because a good integration is not a plugin that streams text into a sidebar. It is retrieval that stays fresh, tools that return structured data, and a system prompt that Brand, Product, Support, and Compliance can all govern.

This guide walks the enterprise problem end to end: grounding the model in current content, wiring schema-aware actions, governing the prompt like the customer-facing behavior it is, and proving the whole thing works before it reaches real users.

Why bolting an LLM onto your CMS fails in production

The pattern is familiar. A team stands up a RAG pipeline, points GPT or Claude at an export of the content, and demos a chatbot that answers beautifully. Then a price changes, an article publishes, a SKU is discontinued, and the model keeps answering from a snapshot that no longer reflects reality. The demo was never the hard part. The hard part is that content is a living system and most integrations treat it as a static corpus.

This is where the architecture choice you make on day one decides whether you spend the next year firefighting. If retrieval lives in a separate vector database glued to your CMS, then freshness becomes your problem forever. Incremental indexing, re-embedding on change, deletion handling, eventual-consistency reasoning, and backfill for schema changes are, as the Sanity team puts it, a real project and a class of bug all its own. Every one of those is a permanent line item on your roadmap, not a one-time build.

Sanity inverts this by mapping to the pillar Model your business: content lives in Content Lake with a schema you define, and the retrieval index is fresh by construction. When a product description updates, when a price changes, when an article publishes, when a record is deleted, the index knows. The freshness problem stops being something you maintain. That is the difference between an AI CMS where the model is a first-class participant in your content model and a legacy CMS that stops at publishing and leaves the AI wiring to you. The competitors listed later all ship real AI capability, but most of them ship it as an orchestration layer or a plugin that sits beside the content and inherits the staleness problem you were trying to escape.

Grounding the model: hybrid retrieval that stays fresh

An LLM is only as trustworthy as the context you hand it, and context has two failure modes. Pure keyword search (BM25) misses intent: a shopper asking for "trail runners under $150 like a Hoka" gets nothing if the exact words are absent. Pure vector search catches intent but drifts on hard constraints, happily returning a $240 shoe because it is semantically close. Production retrieval needs both, plus structured predicates that must hold no matter what the embeddings think.

In Sanity this runs as a single GROQ query rather than a multi-service pipeline. Structured predicates filter what has to be true, then a score() pipeline blends a keyword match with semantic similarity, ordered by relevance:

*[ _type == "product" && category == $category && price < $maxPrice && stockLocation == $warehouse ] | score( boost([title] match text::query($queryText), 2), text::semanticSimilarity($queryText) ) | order(_score desc) [0...10]

The predicates do the filtering that has to hold. The score pipeline weights a BM25 keyword match on the title (2x) alongside text::semanticSimilarity() across the whole document, and _score orders the blend. There is no separate embeddings service to keep in sync, because dataset embeddings are tied to the content in Content Lake. When the content changes, the retrieval changes with it.

This is the AI-native distinction in one query. A legacy CMS makes you assemble retrieval from parts it does not own, so you inherit the re-embedding and deletion handling. Sanity, an AI-native content platform, treats retrieval as a property of the content itself, which is why hybrid search here is one query rather than a distributed system you operate. Ground GPT or Claude on that, and the model stops guessing about a world that has already changed.

Wiring GPT or Claude in: Agent Actions and structured tools

Once the model can find things, it needs to do things, and this is where most integrations quietly degrade. The instinct is to give the model tools that return prose: a lookup that responds with a friendly paragraph describing three products. It reads well in isolation and it poisons everything downstream, because a tool that returns prose forces the model to paraphrase, and paraphrasing is where facts go to die. The model re-narrates the wall of text, badly, and the price it invents is close enough to the real one that nobody catches it until a customer does.

The agents that work return schema-shaped responses the model passes straight through. If your agent is supposed to return three products, the tool returns three product objects, not a paragraph describing them. This maps to the Automate everything pillar: the pipeline primitive is structured content, not a text blob. Agent Actions are Sanity's schema-aware APIs for generating, transforming, and translating content with LLMs, exposed over HTTP anywhere you can run code, which is the native way to wire GPT or Claude into a content workflow without bolting AI on with a plugin. Because the actions know your schema, what comes back is shaped, typed content the model can act on rather than restate.

Retrieval feeds this too. Sanity Context is the product for giving agents structured, governed access to content: it has a knowledge base, an ingest path, and Context MCP, a hosted read-only endpoint any agent loop can connect to. The simple path is bolting Context MCP onto your agent. The advanced path is owning the agent loop and pulling initial context into your own system prompt. Either way, Portable Text keeps rich content structured across chunking and generation, so annotations and blocks survive the round trip instead of collapsing into flat text the moment the LLM touches them.

Governing the system prompt like the content it is

The system prompt is the single most important string in your integration, and in most teams it is exactly that: a string buried in the codebase. The marketing team cannot read it. Compliance cannot review it. When the agent says something embarrassing in production, the fix is a pull request filed by an engineer who does not own brand voice, escalation policy, or the never-say list. That is a governance gap wearing an engineering costume.

The application prompt is customer-facing behavior, so it should be governed like content. Author it in Studio as a document with fields split by owner: Brand owns voice, Product owns how the agent uses user context, Support owns escalation, and Compliance owns the mustNotSay list. Splitting the prompt into fields is not cosmetic. It is access control. None of those teams files a pull request, and because the prompt is content in the Studio you get real-time collaboration, version history, scheduled publishing, and rollback for free. Stage changes with Content Releases, review them, and ship them like any other editorial change.

This is not a hypothetical. It is what customers ask for once they have shipped an agent. Vipps came to Sanity wanting the whole organization to contribute to prompt writing, with product managers owning it, not just engineers. That is the tell: once an agent is real, the prompt stops being code and starts being a thing many teams have a stake in. The half that keeps "anyone can edit" safe rather than scary is the gate. A prompt change runs the eval bench in CI before it can ship. Author it like content, gate it like code, and the org can move on the prompt without any single edit reaching a customer unreviewed.

Proving it works: evals and a two-week rollout

The question that separates a demo from a product is simple and rarely asked: how do you know it is actually working? Vibes do not survive contact with a thousand real conversations, and "it seemed fine when I tried it" is not a release criterion. You need a bench you can run on every change, the same way you run tests on code, because otherwise every prompt tweak is a bet you cannot price.

The recommended rollout is two weeks and it is deliberately small. Week 1: pick the smallest useful pattern, a read-only site assistant on a public page. Wire up hybrid retrieval against your content backend. Define three to five read-only tools, no writes yet. Put the system prompt somewhere a non-engineer can edit it. Stand up trace logging so you can see what the agent actually did. Week 2: build an eval suite of roughly twenty representative conversations you wrote by hand, score them, and ship to a small user cohort. The first three things that break tell you which layer is weakest. Fix the prompt, fix the tools, fix the retrieval, and hold the model constant so you are debugging your system and not chasing model drift.

Holding the model constant is the discipline most teams skip. If you change GPT to Claude and the prompt and the retrieval all at once, a regression tells you nothing. Change one layer at a time against a green eval bench and every failure points at a cause. This maps to Power anything: the same governed content, retrieval, and evals back a site assistant today and a different consumer tomorrow, because the foundation is shared rather than rebuilt per surface. A legacy CMS forces you to scale people to keep AI features honest. An AI CMS scales output by making correctness a property you measure, not a hope you ship.

Choosing a CMS that treats the LLM as a first-class citizen

There is a real depth gradient among CMSes that claim AI, and the query to ask a vendor is not "do you have AI" but "where does the AI live." A ChatGPT integration in a sidebar is not the same thing as an integration where AI is wired into the data model, the editor, and the delivery layer. The former is a feature. The latter is an architecture, and only the architecture survives the content moving underneath it.

Most incumbents land on the feature side of that line, honestly and by design. Contentful hosts AI-powered sidebar apps built with its App Framework and React, so AI runs in predefined slots rather than as a schema-aware content primitive. Strapi teaches GPT integration through LangChain.js and Next.js tutorials, which means the CMS supplies REST and GraphQL while you assemble and maintain the RAG pipeline yourself. Payload adds AI through the community payload-ai plugin (OpenAI plus LangChain), an install-a-plugin approach. Directus wires a first-party OpenAI integration into Flows and offers a third-party AI Researcher extension that embeds a chat UI in the editor. These are legitimate capabilities, and for some teams they are enough.

What none of them own is the thing that breaks first in production: index freshness and structured, governed retrieval as a property of the content itself. Orchestration layers like LangChain.js, LlamaIndex, and the Vercel AI SDK are powerful, but they do not own the content model or the index, so re-embedding on change and deletion handling fall to you. Sanity, the intelligent backend for companies building AI content operations at scale, closes that gap: Agent Actions for schema-aware LLM workflows, hybrid retrieval in one GROQ query, dataset embeddings tied to content, Sanity Context for governed agent access, and Studio governance over the prompt. AI is not a bolt-on here. It is wired through the model, the editor, and delivery, which is exactly what an LLM needs to stay a first-class citizen once the content starts moving.