Comparison

Busabase vs Sanity for AI Agents

Sanity is a content platform: its agents draft and transform the structured content you publish to websites and apps. Busabase is the workspace where agents and your team do the rest of the work — records, docs, files, Skills, and apps — and every change an agent makes arrives as a Change Request with a field-level diff you can read, review, and undo.

Both take agent writes seriously, and Sanity deserves credit for staging them as drafts by default. This page compares them by the jobs teams actually bring to them.

Last verified 13 November 2026 against Sanity's pricing page and its documentation for Agent Actions, the MCP server, Content Agent, Content Releases, drafts, and history.

Connect your agent All comparisons

The short verdict

Choose Busabase when

your agents do the team's operating work — research, customer records, content pipelines, policies, Skills — and you want every change visible and reversible at the field level, with views, a knowledge base, and apps on the same data.

Choose Sanity when

you run a headless CMS: structured content your developers model in code, edited in a customised Studio, and delivered to websites and apps through its APIs and CDN.

Use both when

agents research and keep the facts in Busabase, and the public-facing content built from them is drafted and published in Sanity.

The core difference: every change is a Change Request

Think of it as a pull request for your data. In Busabase, every edit — a record, a Doc, a Skill file, a schema change — is a Change Request: a branch with a chain of immutable commits, a message, and a field-level before and after. Merging moves the record forward; nothing is overwritten.

Sanity's answer is the draft, and it is a good one. By default, its Agent Actions “never mutate a published document”: given a published ID, “the action creates a draft first before applying any changes.” Its MCP server saves patches “to the draft or release version, never directly to published content.” What a person then reviews is a new version of a content document, before it is published.

So the question is not who has a review step. It is what gets reviewed, and how much of your work it covers.

One review queue for every edit. Whatever an agent touched — a CRM row, a policy Doc, a Skill file — the reviewer sees the changed values, from what to what, in the same Inbox, with the agent’s message explaining why.
It covers everything in the workspace. Records, Doc bodies, Skill files, and schema changes all go through the same Change Request — not only the documents of a content model.
Know which agent did it. The author and the key or tool the change came through — API, MCP, or CLI — stay on the commit, with the message explaining why.
History does not expire. Every record, Doc, and Skill keeps its full history and any change can be rolled back.
Review when you choose, enforced by permission. Writes with write access merge immediately. Give an agent a proposal-only key and it cannot apply anything: its changes wait in the Inbox for a person to approve or send back.

A Busabase Change Request under review: its message, a before-and-after diff of a record's body, and Approve or Request changes controls — A Change Request in the Inbox: what changed, who proposed it and through which tool, and the before and after of the field, with Approve or Request changes.

This is what makes it safe to let any agent write to the data your team actually runs on — not by keeping it out, but by making every change visible, attributable, and reversible.

What else Busabase gives your agents and your team

Sanity is built around content documents headed for an audience. Busabase covers the team's work around them — and all of it comes with the workspace.

Visual data tables

Every Base opens as a table, gallery, kanban board, calendar, or Gantt chart, with saved views and AND/OR filters. A teammate checks what an agent wrote without anyone configuring an editor first.

A team knowledge base

Records sit next to the Docs that hold your policies and the files agents produce — one tree, shared by people and agents, with one permission model.

Grep across everything

One regex search covers files, Doc bodies, Base records, and agent prompts, and returns the line and its context — so an agent finds the exact evidence before it reads further.

Skills you upload

Put your team's Skills into the workspace once. Every connected agent reads the same version, and editing a Skill is a Change Request like any other.

Apps with four engines

Ask your agent to build an AirApp on your data. Run it in the browser, on your own machine, in a cloud sandbox, or as a website that stays online.

Websites on your domain

The Website engine runs on Cloudflare Workers, can have its own backend endpoints, and takes your own domain. Your agent can preview and publish it for you.

Built for teams

Invite teammates with read, write, or manage roles, and let agents join with keys capped at the level their job needs. Permissions apply per node and per key.

Agents connect in minutes

MCP, a CLI, an OpenAPI REST API, webhooks, and plugins for Claude Code and Codex. The bundled skill teaches the agent how your workspace is organised.

Runs where your data has to

MIT-licensed — the whole product, not just the editor. Run it on your laptop, inside your own network including fully offline, or on Busabase Cloud. A space exports to plain files: Markdown, Base definitions, and JSON records.

A Busabase Base showing agent-written blog posts as a table with title, cover image, and body columns, plus saved views for Ready to publish and Drafts — A Base in Busabase: posts an agent wrote, with cover images and bodies, readable by anyone on the team. Saved views such as “Ready to publish” filter the same records.

Comparison by the job you are trying to do

Rows are the jobs teams bring to these two products, not feature checkboxes. Where Sanity is the right tool, the table says so.

What you are trying to do	Busabase	Sanity
Review exactly what an agent changed	Yes — a Change Request with a field-level before and after	Yes, per document — agent edits land in a draft; a comparison view highlights changed fields between versions before you publish
Put the same review on every kind of edit	Yes — records, Doc bodies, Skill files, and schema changes	Drafts and releases cover content documents
Let one agent propose but never apply	Yes — a proposal-only key; its changes wait in the Inbox	Drafts by default; whether an agent can also publish depends on its token's role — the MCP server includes a publish tool
See which agent made a change, through which tool, and why	Yes — author, key or tool, and message on every commit	Revision events such as Edited and Published in document history
Keep history and roll back any change	Yes — full history on every record, Doc, and Skill, no expiry	History retention by plan: 3 days Free, 90 days Growth, 365 days or custom on Enterprise
Let teammates read and edit what agents wrote	Yes — table, gallery, kanban, calendar, and Gantt views with no setup	Studio editing forms built from a schema your developers define in code
Run a team knowledge base	Yes — Docs, files, and Bases in one tree with shared permissions	Structured content documents and assets, modelled for publishing
Find exact text across everything	Yes — one regex grep across files, Doc bodies, records, and agent prompts	GROQ queries over your content documents
Give every agent the same team Skills	Yes — upload once; every connected agent reads the same version	Not a product concept; Agent Actions take instructions per request
Turn the data into an app or a website on your domain	Yes — AirApps in four engines; Website engine on Cloudflare Workers with custom domains (Plus and above on Cloud)	Headless by design: you build and host the front end
Connect Claude Code, Codex, Cursor, and other agents	Yes — MCP, CLI, OpenAPI, webhooks, and agent plugins	Yes — a hosted MCP server at mcp.sanity.io, plus Agent Actions through the client
Self-host, including offline	Yes — the whole product is MIT, from a laptop to an air-gapped network	Studio is MIT open source; content is stored in Sanity's hosted Content Lake
Predictable pricing as the team grows	Flat per seat — no metered overage	Per seat on Growth, plus pay-as-you-go overage for API requests, bandwidth, and assets
Deliver structured content to websites and apps across channels	Not its job — use Sanity	Yes — this is Sanity's home ground: Studio, GROQ, the API CDN, scheduling, and releases

Coming next

Three features are being built now. They are not available yet; we list them so you can plan, and this page will be updated when they ship.

App users In development

People who use the apps you publish — a shop's customers, say — sign in with an email code and see only their own records. The platform enforces it, and they never become workspace members or take a seat.

Ontology In development

Define the business objects your team talks about — Company, Contact, Deal — and the links between them on top of your existing Bases, so people and agents share one vocabulary. Changes to it go through Change Requests too.

Fine-grained permissions In development

Row- and field-level access inside a Base, scoped agent grants with an expiry, and access requests a person approves — so each agent gets exactly the access its job needs.

What Sanity gets right about agent writes

Sanity was early to the right default, and its review story has real depth. Agent Actions — Generate, Transform, Translate, Prompt, and Patch — are schema-aware and write to drafts unless you pass forcePublishedWrite: true or the type uses liveEdit. Content Agent goes further for bulk work: “All edits are staged as proposed changes. Review in one place, adjust what to include, then release together.” And Content Releases group many document changes into one unit you can preview and publish together or on a schedule.

Two caveats worth knowing. The Agent Actions docs describe them as an experimental feature whose APIs “are subject to change,” and each request uses AI credits. Content Releases are “available on certain Enterprise plans”; Growth gets Scheduled Drafts for single documents.

The deeper difference is scope. Sanity's review machinery is built for content documents on their way to readers. Busabase puts one Change Request on every kind of edit in the workspace — the CRM row an agent enriched, the policy Doc it corrected, the Skill another agent will follow tomorrow — and lets the agent's key decide whether it may apply the change or only propose it.

Using them together

A common split for a team that publishes content and runs agents:

A research agent gathers sources, product facts, and customer quotes into Bases in Busabase. Every value it adds or corrects is a Change Request the team can trace.
The team keeps briefs, brand rules, and the Skills that tell agents how to write in the same workspace, so every agent reads the same version.
When something becomes public-facing content, a writing agent drafts it in Sanity, where editors review the draft and publish it through releases.
Sanity delivers that content to your sites and apps; Busabase keeps the facts, the rules, and the history behind it.

Neither product replaces the other. Sanity ships your content to an audience; Busabase keeps your agents' working material visible, reviewable, and reusable.

Pricing at a glance

Busabase

Free: 1 space, 3 seats, 5,000 records, 1 GB of files, every node type including Skills, workflows, and AirApps.
Plus: from $10 per seat per month (billed yearly). Pro: from $20.
Flat per seat, no metered overage. Self-hosting is free under MIT with no seat limit.

Sanity

Free: $0, up to 20 seats, 2 roles, 10,000 documents.
Growth: $15 per seat per month, up to 50 seats, 25,000 documents; Viewer seats are free. Usage above the included API requests, bandwidth, and assets is billed pay-as-you-go.
Enterprise: custom, including SSO and longer history retention.

Prices as published on 13 November 2026. See Busabase pricing and Sanity pricing for current details.

Where Sanity is the better choice

Your output is content shipped to an audience. Websites, apps, and localized marketing fed from one content model through GROQ and the API CDN — that is Sanity's whole pipeline, and Busabase does not try to be a headless CMS.
You want a deeply customised editing experience. Studio is configured in code around your content model, with document comparison, scheduling, and releases for editorial teams.
You run a mature editorial operation. Roles, releases, and Content Agent's staged bulk edits fit a content team's way of working.

Busabase's limits, plainly: no localization workflow, no release scheduling, no content delivery CDN, no realtime subscriptions, and no vector index. Sign-in for the end users of the apps you publish is in development (App users) but not available today. If your job is publishing content to an audience, use Sanity for that part.

Frequently asked questions

Does Sanity let agents write directly to published content?

Not by default. Agent Actions create a draft first, and the MCP server saves patches to drafts or release versions. Writing straight to published requires forcePublishedWrite: true or a type using liveEdit. See Sanity's Agent Actions operations docs.

Then what does Busabase add?

A wider scope and a permission-enforced gate. The same Change Request covers records, Docs, Skills, and schema, not only content documents; a proposal-only key means an agent cannot apply anything itself; the agent and the key it used stay on every commit; and history does not expire.

Does every agent write in Busabase need a human review?

No. Writes from anyone with write access merge immediately and keep their full history. Review is opt-in: give an agent a proposal-only key, or ask it to submit a change for review.

How is a Change Request different from a draft?

A draft is a working copy of a whole document that replaces the published version when you publish. A Change Request is the change itself — a message, a field-level diff, an author — applied to the current record without overwriting its history, and it can be rolled back later.

Is Busabase a headless CMS?

No. It can back a website through an AirApp, but localization workflows, release scheduling, and multi-channel content delivery are what Sanity is built for.

Can I self-host Busabase?

Yes. The whole product is MIT-licensed and runs on a single machine, on your own server, or in an air-gapped network. See the self-hosting guide.

Next step

Connect an agent you already use, give it a proposal-only key, and ask it to correct one real record. You will see the change arrive as a Change Request — the field, the before and after, and who sent it.

Connect your agent Browse templates

Sources: Agent Actions operations, Agent Actions introduction, Sanity MCP server, Content Agent, Content Releases, Drafts and perspectives, History experience, Compare document versions, API CDN, Sanity pricing, Sanity Studio on GitHub, Busabase pricing