Sanity AI Workflows: Governance Guide for Business
Sanity announced Workflows on 14 September 2026 as a new way for people, agents and applications to move content through one defined process. The launch is timely because many businesses are ready to use AI for drafting, translation and content checks, but are less comfortable giving an agent an unrestricted path to publication.
Workflows addresses the operating layer around automation: stages, responsibilities, approvals, exceptions, effects and a history of what happened. That makes it commercially relevant to Australian organisations that want faster content operations without replacing accountability with a prompt.
There is an important maturity caveat. Sanity's launch post calls Workflows a beta and says it is free for now, while the product documentation describes it as early access and built in public. Treat it as a controlled pilot technology, confirm current commercial terms with Sanity and avoid making a business-critical publishing process depend on it before you have tested the failure paths.
Three reasons the release matters now
The product announcement connects AI adoption with the controls content teams already need.
14 September launch
Sanity announced Workflows alongside a broader set of agent-oriented content capabilities.
One shared process
People, agents and applications can work through the same definition and process record.
Governance in the workflow
Approval, attribution, testing and exceptions can be designed as part of delivery rather than added later.
What Sanity Workflows actually is
A workflow definition is a TypeScript description of a process. It names the stages content moves through, the activities that must be completed, the actions people or systems can take and the conditions that move the process forward. Starting that definition creates an instance: a Sanity document representing one live run.
This matters because workflow state becomes queryable business data. A team can ask which items are awaiting legal review, which automated checks failed or which releases are blocked, rather than reconstructing status from messages and spreadsheets. The same definition can surface in Sanity Studio for editors, through APIs for applications and through an MCP server for agents.
Definitions are versioned. Sanity documents that an instance remains pinned to the definition version it started under, so a new deployment does not silently change an in-flight run. That is helpful for auditability, but it also means a rollout plan needs to account for old and new workflow versions operating at the same time.
Use a seven-stage control loop
Start with the business decision, not the AI tool
Choose one repeatable content job and document its decision points before implementing a workflow. A good pilot might be a product-description refresh, a routine translation or a low-risk knowledge article. Avoid regulated claims, crisis communications and irreversible bulk publishing as a first use case.
| Decision | Question to answer | Workflow control |
|---|---|---|
| Scope | Which content types, fields, markets and channels are included? | Start requirements and subject rules |
| Generation | What may AI create or change? | Bound effect inputs and restricted targets |
| Acceptance | What evidence makes an output ready? | Automated checks and recorded results |
| Escalation | Which failures require a person? | Conditional verification stage |
| Authority | Who may approve or publish? | Roles plus Content Lake access control |
| Recovery | What happens when an API, check or publish step fails? | Failure state, retry policy and support owner |
Write acceptance criteria in observable terms: required fields present, approved terminology used, links valid, factual claims supported, locale correct and no prohibited content. The Australian Government's AI adoption guidance recommends defined acceptance criteria, documented testing, monitoring, response processes and deployment authorisation. Those practices are useful for private businesses even when the guidance is not a new legal obligation.
Put people where judgment matters
Automation should reduce routine handling while preserving clear decision rights.
Always review
Use for legal, safety, pricing, regulated, reputational or high-impact public content.
Review exceptions
Let passing routine work continue, but route failed or uncertain checks to a named person.
Automate within limits
Reserve for low-risk, well-tested changes with narrow scope, monitoring and a recovery path.
Design the runtime, not only the stages
Sanity's workflow engine is a library, not a hosted service that continuously watches and advances every process. External work such as calling an AI provider, sending a notification or publishing through another system is represented as an effect. Your runtime must claim the effect, execute it and report the result.
That distinction changes the production architecture. Consequential or unattended handlers belong on a server runtime with managed credentials, idempotency, retry limits, structured logs and alerting. A browser-only handler stops when the interface closes and is not appropriate for a critical background process.
Map every dependency before launch: AI model, translation provider, link checker, media service, CMS dataset, deployment pipeline, notification channel and downstream commerce or search index. Decide which failures can retry, which must stop and which should create a human task. If a step can be invoked more than once, make it safe to repeat.
Do not mistake workflow rules for security boundaries
This is the most important implementation detail in the current release. Sanity states that engine verdicts and current workflow guards are advisory. A client with a write-capable token can bypass the engine and write directly to the Content Lake. The server-side enforcement boundary is dataset access control and custom roles.
Use workflow roles to guide cooperative users and interfaces, but enforce non-negotiable restrictions in the Content Lake. Give agent and runtime tokens the smallest dataset and action scope they need. Keep publishing authority separate where possible, rotate secrets through an approved process and never expose an editor token to browser code or prompt content.
Actor attribution and workflow history are valuable operational evidence, but they do not replace platform access logs, content history or a broader audit trail. Define which record is authoritative for content changes, approvals, model outputs and incidents.
Test every path before connecting production content
Sanity provides an in-memory test bench that runs the real workflow engine with a deterministic clock, actors you choose and simulated guard enforcement. Use it to verify the process logic in CI before a definition touches a live dataset.
- Prove each valid route reaches the intended terminal stage.
- Test which roles can and cannot complete every action.
- Force AI generation, validation, external API and publishing failures.
- Exercise retry, duplicate-delivery and timeout behaviour.
- Control the clock for deadlines, scheduled work and stale approvals.
- Confirm an in-flight instance behaves correctly after a new definition version is deployed.
- Verify denied direct writes against real dataset access control in a safe Sanity environment.
The worked AI pipeline in Sanity's documentation provides a useful starting shape: AI drafting, automated brand/SEO/link/fact checks, conditional human verification, publishing and a terminal published state. Treat it as an example to adapt, not proof that your content, prompts and risk thresholds are ready.
A practical 30-day pilot for an Australian team
Week 1: Choose and bound the use case
Name the process owner, technical owner and approver. Inventory the current steps, inputs, content types, systems, risks and manual evidence. Choose a low-risk workflow with enough volume to measure.
Week 2: Build the workflow and controls
Define stages, activities, actions, conditions and failure states in TypeScript. Configure least-privilege dataset access, server-side effects, secrets, idempotency and logs. Keep automatic publication disabled.
Week 3: Test with representative content
Run happy paths and failure paths in the test bench, then test in a non-production dataset with representative roles and content. Record expected results, actual results and the person who accepts each risk.
Week 4: Run a supervised production pilot
Process a limited batch with human approval on every item. Track exception rate, correction effort, time to approval, failed effects, retries and support incidents. Continue only if quality and control targets are met.
This approach aligns with the risk-based spirit of Australian AI guidance: accountable ownership, human oversight, testing, monitoring and documented authorisation. The DTA's agentic-AI material is written for government agencies, but its emphasis on oversight and control is a sensible benchmark for any business increasing an agent's autonomy.
Measure whether the workflow improves the business
Do not judge the pilot by how much copy the model produces. Measure the whole operating process.
| Measure | What it reveals | Example evidence |
|---|---|---|
| Cycle time | Whether work reaches approval and publication faster | Median time by stage |
| First-pass acceptance | How often output meets agreed criteria without revision | Approved items divided by completed items |
| Exception rate | How often automation needs human intervention | Flagged checks and failed effects |
| Correction effort | Whether reviewers save time or simply repair AI output | Minutes and change volume per item |
| Control failures | Whether roles, approvals or publication boundaries were bypassed | Denied tests, incidents and audit review |
| Operational reliability | Whether integrations complete consistently | Retries, duplicate effects, timeouts and stuck instances |
Set a stop condition before launch. For example: pause if a prohibited claim reaches approval, a direct-write path bypasses the intended boundary, an effect cannot be reconciled or reviewers spend more time correcting content than the previous manual process.
Questions to ask before adopting Sanity Workflows
- Is Workflows described as beta or early access for our plan, and what support and change commitments apply?
- Which workflow packages and versions must stay aligned across Studio, servers, MCP and CI?
- Where will the runtime execute effects, and who owns alerts, retries and stuck instances?
- Which rules are advisory workflow guidance and which are enforced by Content Lake access control?
- Which roles and tokens can write, approve and publish?
- How are prompts, model versions, generated outputs, approvals and corrections retained?
- What happens to in-flight instances during a definition upgrade?
- How will we export or reconstruct the process if the early-access interface changes?
- Which metrics determine whether the pilot expands, changes or stops?
If your current content process is undocumented, start with CMS governance for marketing teams and an AI agent readiness check. A workflow platform can encode a sound process, but it cannot decide your risk appetite or ownership model for you.
Sources Checked
- Sanity: For agents, knowing is half the battle
- Sanity documentation: Workflows
- Sanity documentation: Actors, tokens, and what is actually enforced
- Sanity documentation: Test your workflows
- Sanity documentation: AI content pipeline cookbook
- Australian Government: Guidance for AI Adoption implementation practices
- Digital Transformation Agency: Trustworthy AI agents technical guidance