How to Run Multi-Step AI Workflows on CMS Content

A multi-step AI workflow that looks flawless in a notebook tends to fall apart the moment it touches real content. The retrieval tool returns a wall of prose, the model re-narrates it, and a product price quietly drifts by fifteen dollars. A prompt tweak that a marketer wanted takes a two-week engineering ticket. A vector index goes stale because nobody wired re-embedding to publish events. None of these are model problems. They are content-plumbing problems, and they are exactly where most CMS-backed AI pipelines break.

Sanity is the AI Content Operating System, the intelligent backend for companies building AI content operations at scale. That framing matters here because a multi-step workflow, retrieve, then reason, then act, then return, is only as reliable as the content layer feeding it. If retrieval is fresh, tools return schema-shaped data, and the steering prompt is governed like content, the workflow holds.

This guide walks the anatomy of a production multi-step workflow on CMS content: how to structure tools, how to make retrieval both precise and fresh, where the system prompt should live, and how to gate changes with evals. The lens throughout is the CMS as protagonist, not the LLM.

Why multi-step AI workflows break on the content layer, not the model

Most teams debug the wrong thing. When an AI workflow returns a wrong answer, the instinct is to swap models, raise the temperature, or bolt on another retrieval trick. But in production, the recurring failure modes trace back to the content backend. Retrieval surfaces the wrong document because keyword search misses intent and semantic search misses the hard constraint. Freshness lags because the search index lives in a separate system that nobody kept in sync. Tools hand the model a paragraph of prose, so the model paraphrases, and, as the pattern goes, paraphrasing is where facts go to die.

A multi-step workflow amplifies each of these. If step one retrieves a slightly stale price and step two acts on it, the error compounds instead of getting caught. A single-turn chatbot might survive sloppy plumbing; a workflow that reads, reasons, then writes will not. The stakes rise with every step you chain, because there is no human reading each intermediate result.

This is the core reframe: reliability in AI workflows is a content-architecture property. Legacy CMSes stop at publishing, so anything past the publish event, retrieval, grounding, governance of the steering prompt, becomes glue code you own and maintain forever. An AI-native content platform treats those concerns as first-class. Sanity's distinguishing claim is that AI is wired into the data model, the editor, and the delivery layer rather than added on top with a plugin. The sections that follow map to the three things a workflow needs from its content layer: structured tools, hybrid retrieval that stays fresh, and a governed steering prompt.

The three tool categories every production workflow needs

A tool is just a function the model can call. The architectural question is not what a tool is but which functions you expose, with what authority, and returning what shape of data. Production workflows sort into three categories, and naming them keeps your design honest.

Read tools query content, fetch user state, or look up product info. The auth boundary is usually the user's session token, so the agent reads as the user and cannot see more than the user could. Write tools mutate state: move a seat on a flight, cancel a subscription, open a support ticket. The auth boundary is again almost always the user's token, so the agent acts as the user, not as an unbounded admin. Composite tools wrap a whole workflow, so one tool call maps to three or four API calls in your backend. Composite tools matter when you do not want the model orchestrating multi-step work itself. If a refund requires validating eligibility, issuing credit, and sending a confirmation, you do not want the model deciding the order and possibly skipping a step; you want one composite tool that runs the sequence deterministically and reports the outcome.

The discipline that ties this together: keep the tool count small. Tool schemas and descriptions ride along with every request in most harnesses, the Vercel AI SDK, Anthropic's tool use, OpenAI's function calling, so they consume context tokens on every turn. Ten focused tools beat fifty overlapping ones, because the model can hold the whole menu and route correctly. Give it forty and it gets confused, picks the wrong one, and calls it with the wrong arguments. Start with three to five read-only tools, prove the pattern, then add writes and composites deliberately.

Return structured, schema-shaped data, not a stream of text

The single highest-leverage rule for multi-step workflows is also the most ignored: tools should return structured data, not prose. A tool that returns a paragraph forces the model to paraphrase it, and every paraphrase is an opportunity to drop a fact, round a number, or invent a detail that was never there. When agents were built against the Context MCP endpoint, the ones that worked returned schema-shaped responses the model could pass straight through. The ones that struggled got a wall of text back and re-narrated it, badly.

The rule is concrete: if your workflow is supposed to return three products, the tool should return three product objects, not a paragraph describing them. Each object carries its fields, name, price, availability, url, in a shape the next step can read without guessing. This matters twice over in a multi-step pipeline. First, the model at the presentation step can render exact values instead of approximations. Second, and more subtly, intermediate steps can branch on structured fields, filter on price, sort on availability, without the model having to parse its own earlier prose back into data.

This is where content structure pays off. Portable Text preserves marks, annotations, and blocks across chunking, retrieval, and generation, so rich text does not collapse into an undifferentiated string the moment an LLM touches it. Content Lake stores content as queryable structured documents, so a Read tool backed by GROQ returns objects, not a rendered page you would have to scrape. The workflow inherits structure for free instead of reconstructing it at every hop.

Hybrid retrieval that filters hard and ranks well, and stays fresh

Retrieval is where most workflows silently fail. Pure keyword search (BM25) nails exact terms but misses intent: a query for trail runners under $150 like a Hoka will not match a listing that never uses the word Hoka. Pure vector search captures intent but happily returns a great semantic match that violates a hard constraint, an out-of-stock item, or one that costs $300. Production retrieval has to do both, and the split is principled: predicates do the filtering that has to hold, and scoring ranks what remains.

In Sanity, that is one GROQ query, not two systems stitched together. GROQ predicates enforce the constraints, in stock, price under 150, so the workflow never even considers a document that breaks a rule. Then a score() pipeline blends a boosted keyword match, boost([title] match text::query($queryText), 2), weighted 2x because title hits matter more, with text::semanticSimilarity($queryText) across the document, and orders by _score descending. Keyword precision and semantic intent, blended, ranked, filtered, in a single expression.

The part that separates a demo from production is freshness. Any of the vector-DB alternatives requires a content pipeline that keeps the search index current: incremental indexing, re-embedding on change, deletion handling, and backfill. When it is a separate vector DB plus glue code, freshness becomes a permanent line item on your roadmap. Content Lake handles that pipeline for you, so dataset embeddings and the search index stay current as editors publish, without a re-embedding job you have to remember to run. In a multi-step workflow, stale retrieval at step one poisons every step after it, so freshness is not a nice-to-have; it is a correctness property.

Govern the steering prompt like content, because it is customer-facing behavior

The system prompt that steers a workflow is not code, even though it usually lives in a code repo. It is customer-facing behavior: the agent's voice, its escalation rules, the things it must never say. Treating it as a string constant means every tweak is a pull request and a deploy, so the people who actually own that behavior, brand, support, compliance, cannot touch it. That is backwards.

The better pattern is to store the application prompt as a document in the Studio, split into fields. Brand owns voice. Product owns how the agent uses user context. Support owns escalation. Compliance owns the never-say list. Splitting the prompt into fields is not cosmetic; it is access control. The fields stitch together into one final system prompt at runtime, the same way a page builder stitches sections and references and logic into a page, and none of those owners has to file a pull request or wait for a deploy. Because it is content in the Studio, you get real-time collaboration, version history, scheduled publishing, and rollback for free. As Nearform put it, storing the system prompt in a Sanity document is genuinely useful, and editors tuned the agent's voice without any code changes.

Governance without a safety gate is just faster mistakes, so the gate is evals. A prompt change runs an eval bench in CI before it can ship, scored against a suite of representative conversations. Content Releases let you stage, review, and schedule a prompt change the same way you would stage a marketing campaign, and Roles & Permissions decide who can edit which field. This is the shared-foundation advantage: legacy CMSes create silos, while a Content Operating System puts prompt, content, and governance on one substrate.

A staged rollout: what to build first, then how to scale it

Ambition kills AI workflows faster than any technical limitation. Teams try to ship an autonomous multi-tool agent with write access on day one, then spend months debugging emergent behavior they cannot reproduce. The proven sequence is smaller and duller, and it works.

Week one: pick the smallest pattern, a read-only site assistant on a public page. Wire up retrieval against your content backend with hybrid search. Define three to five read-only tools, no writes yet, so nothing the workflow does can be destructive while you are still learning its failure modes. Write the system prompt and put it somewhere a non-engineer can edit it. Stand up trace logging so you can see every tool call and every retrieval result, then ship to a dark URL where only your team can reach it. Week two: build an eval suite of twenty representative conversations you write by hand, score them, and only then start adding capability. Twenty hand-written evals catch more real regressions than a thousand synthetic ones, because you wrote them against the ways your users actually phrase things.

Scaling from there means adding Write and composite tools one at a time, each behind its own eval cases, and eventually owning the agent loop yourself: pulling initial context into your own system prompt, treating that prompt like a page builder with sections and references and logic, and reaching past the MCP when you need to. Sanity Context is the product that gives agents structured, governed access to content; Context MCP is one surface of it, a hosted read-only endpoint any agent loop can connect to, and Context also carries a knowledge base and an ingest path, so it is not only an MCP. Vipps hit the advanced case with localization, running the workflow across locales instead of one. The through-line: legacy CMSes force you to scale people, while an AI-native platform scales output.