Sanity to code you own.

[ Why teams move ]

The content is in good shape. Getting it onto the page is what’s slow.

Choosing Sanity was a good decision and it isn’t the one being questioned here. Structured content, a real content model, an API rather than a page builder: teams who made that call were ahead of the ones who didn’t.

What tends to wear is everything around it. There’s a front end to build and host, usually in a framework only developers touch. Editing an article is quick, but a new section, a new page type or a new field is a schema change and a front-end deploy, so it becomes a ticket. Two systems, one site, and a boundary every real change has to cross. And now a newer one: your team works with AI every day, and its agent can reach the content but not the site around it.

[ Is it time? ]

Three signs your site has outgrown Sanity.

Your team uses AI every day, for everything except the website.
Changes queue behind the one person who knows how the site is wired.
A new page type means a schema change, a front-end change and a deploy.

And it’s fine to keep Sanity if an editorial team publishes most days and loves the Studio, or you publish across languages or markets. Then the CMS is earning its place, and only the front end moves. We’ll tell you which on the Discovery call, with the evidence from your own site.

[ The path ]

From Sanity to an agentic website, in six steps.

Step 1

Map your Sanity site.

Discovery reads both halves: the content model, its document types, references and Portable Text, and the front end that renders them, its templates, its queries and how it’s deployed. You leave with a roadmap that says what moves, what it becomes, and in what order, including whether Sanity stays.
Step 2

Rebuild the front end as a system.

The front end is rebuilt as a component library on Astro, each component matched to the content it renders, with your brand rules written into a brand.md. If the current front end is already component-based, much of the thinking carries over. What changes is that your agent can now work on it.
Step 3

Decide where the content lives.

There are two honest options. Keep Sanity as the editor: your content stays exactly where it is and the new site reads from it, which suits a team that publishes daily. Or fold the content into the repository: documents are exported and become structured content files, with references, Portable Text and images mapped across. Discovery makes the call with you.
Step 4

Add the rails and the machine layer.

The guardrails and skills your agent will run on go in: what it may touch, how a page gets built, what gets checked before anything ships. Because your content is already structured, the machine layer can be done completely and quickly: structured data, schemas, llms.txt and a clean sitemap, generated from the same model.
Step 5

Switch over, with a net.

The redirects go live with the switch. A headless site’s URLs were usually designed rather than generated, so the plan tends to be short. If the content is moving too, the Studio can keep running for as long as you like afterwards. Nothing forces you to turn it off on cutover day.
Step 6

Take the keys.

Your team connects the agent it already uses and ships its first supervised changes in the first week of handover: a real page, a real edit, with us in the room. A new section or page type is a brief and a preview, rather than a schema change, a front-end ticket and a deploy.

[ Piece by piece ]

What each part of your Sanity site becomes.

	On Sanity	On an agentic website
[ 01/ Front end ]	A separate app that developers deploy	A component library in your repository, with a brand.md your agent builds against
[ 02/ Content ]	Documents in a Sanity dataset	Kept in Sanity as the editor, or content files in your repository. Your choice
[ 03/ Content model ]	Schemas in the Studio’s code	The same shapes, kept with the site, where your agent can extend them
[ 04/ Queries ]	GROQ between the content and the page	Still there if Sanity stays. Gone if the content moves into the repository
[ 05/ Hosting ]	A front-end host, plus the Studio	One site, in an account under your name
[ 06/ URLs and rankings ]	URLs someone designed on purpose	Every URL redirected, metadata carried over, rankings watched through cutover
[ 07/ Making a change ]	A schema change, a front-end ticket and a deploy	Brief the agent, check the preview, approve it
[ 08/ When something goes wrong ]	Find out whether it was the content, the query or the front end	A broken layout fails before it ships, and any change can be undone

[ The agent layer ]

On Sanity, your agent runs the content. It can’t reach the site around it.

Sanity is further ahead here than most. It has an official MCP server, agent actions, and a Content Agent that can audit, draft and stage content changes at scale. That’s the content half, and it’s good. The front end is a separate codebase the agent isn’t connected to, so a new section, a layout change or a new page type still goes to a developer.

On an agentic website the site is plain, structured files in your repository, so the agent your team already uses, Claude, Claude Code, ChatGPT, Gemini, Cursor, Codex, reads all of it and changes any of it. It builds inside your encoded brand and our rails, and the change arrives on a preview. The AI proposes, you approve what ships. A new campaign page becomes a brief, not a ticket, and adding ten marketers doesn’t add to the cost of shipping.

[ Where you land ]

An agentic website: yours, and run by your team.

The keys.

Code and content in your GitHub repository, under your name, from the first commit.
Your agent ships it.

Your team briefs the change in plain language and it lands on a preview. The AI proposes, you approve what ships.
Your brand, encoded.

A brand.md in the codebase, so every change, from anyone, is made against your rules.
Our standards, baked into the rails.

More than a decade of design and development standards, checked before anything ships.
The machine layer.

Structured data, schemas, llms.txt and a clean sitemap, so the AI systems answering your buyers can read and cite your site.
The handover.

Playbooks and paired working, until your team runs the site themselves.

[ Recent work ]

Built for SaaS teams like yours.

Autohive: a website that keeps pace with their marketing teamAn AI-agent company's first website, built on a component framework their designers, marketers and agents could all work in, so their marketing team builds its own landing pages and updates without waiting on anyone.Read more
Future of Marketing Work: a brand and website for a three-way eventAn Auckland event on how marketers adapt to digital transformation and AI, brought together by a university, the AI community and an events group. We made the brand, the website and the print.Read more
Landlord Studio: one system for two markets, run by their marketing teamProperty management software for landlords in the US and UK. A five-year-old Webflow build redesigned, migrated onto a component-driven framework, and handed to a marketing team that now builds its own pages with AI.Read more

Will we lose our rankings moving off Sanity?

A migration is built to keep them. Every live URL is mapped to its destination before anything moves, metadata travels with it, and rankings are watched through cutover so anything that shifts is caught and fixed. A headless site’s URLs were usually designed rather than generated, so the map tends to be short and every rule deliberate.

How long does a Sanity migration take?

The roadmap sets the timeline. It depends on the number of templates more than the number of pages. What stays fixed is the cadence: something visible ships every fortnight, from the first fortnight, on a live preview.

What happens to our datasets and content model?

If Sanity stays, nothing: the new site reads from the same dataset. If the content moves, documents are exported and land as versioned files next to the code, with references, Portable Text and image assets mapped rather than flattened. The model you built survives either way, as the shape of the content.

Sanity has an MCP server and a Content Agent now. Isn’t that enough?

For content operations it’s very good, and if you keep Sanity we connect it. The gap is the site. Sanity’s agent tools work on documents; the front end that turns them into pages is a separate codebase they don’t touch. On an agentic website your agent works on both: the content and the site, in one place, with a preview before anything ships.

Can our team still make changes ourselves?

More than before. Anyone on your team describes the change in plain language, the same way they’d brief a designer. The agent builds it inside your encoded design rules and it arrives as a preview for someone to approve. Nobody writes code or opens a terminal, and nothing ships without a person saying yes.

What’s the alternative to Sanity for a marketing team?

The usual answers are another headless CMS such as Contentful or Strapi, or a site builder like Webflow. The first swaps one content platform for another and leaves the front-end queue in place; the second gives up the structure you built. The third option is to own it: the site as code in your own repository, with your team’s agent making the changes inside rules we set, and a person approving each one. That’s an agentic website , and a migration is how most teams get there.

Can we keep Sanity and still do this?

Yes, and for some teams it’s the right answer. The front end is rebuilt as an agentic website and reads from the same Sanity dataset, so your editors change nothing and your marketers brief the agent for everything else. It’s one site with two ways to edit it. See Headless CMS websites .

Do the front end and the content have to move together?

No. The front end can move first while Sanity keeps serving the content, and the content can follow later, or never. Two steps, each reversible, which suits a team that publishes daily.