Why there's no AI chat box for building your site
There's no prompt box for building sites in our Studio. You point your own agent at our tools instead — better context, and no markup on tokens.
Almost every CMS has shipped a prompt box in the last eighteen months. We haven't, for the build path, and this is why.
First, a precise statement of what we do and don't have, because the distinction matters.
The Studio does have an assistant, and it's for the client. It answers questions about their content, finds things, and drafts copy. It can only touch content, it only does what the signed-in person's own permissions allow, and it cannot publish — it writes drafts and a human clicks Publish. That's a deliberately small tool for a non-technical person.
What we don't have is a prompt box for building sites. There's no "describe your website and we'll make it" field anywhere in the product. That's the decision this post defends.
A box only knows what's in the box
An in-product prompt box runs inside our application. It can see your content model and your content. That's the whole of its context.
The agent you already use — Claude in your terminal, Cursor in your editor — is sitting inside the work. It can see your repository, your existing themes, the last three client sites you built, the brand guide in the project folder, your naming conventions, the half-finished branch. When you say "build this like the Hartley job but with their colours", it knows what the Hartley job was.
We can't compete with that from inside a text field, and the honest thing is not to pretend otherwise. So instead of building a worse agent, we expose the platform as tools your agent can call.
How that works
Contentive runs a tool server your agent connects to. Point Claude Desktop, Claude Code or Cursor at a workspace with a scoped token and it gets tools for the real platform: read the content model, create content types and fields, create and update documents, link references, compose pages from blocks, create forms, upload media, declare routes, deploy a theme, check a deployment.
Two properties keep it safe rather than merely exciting.
The token decides the surface. A token is scoped to a workspace and to a set of capabilities, and the tools an agent sees are the tools its token permits — not a full list with some of them failing. You can narrow it further on the connection itself: read-only, or limited to one category of work. Those filters only ever remove tools. Nothing widens a token's grant.
Publishing doesn't reach production. Publishing puts content in staging. Production is a separate promotion step, and on a content-scoped connection there's no publish or deploy tool at all — the agent drafts, a person in the Studio reviews and ships. Every deployment can be rolled back, and every document keeps its version history with restore.
Everything it builds is ordinary
There's no agent-shaped corner of the product. A content type the agent created is the same row as one you created in the Studio. A page it composed opens in the normal editor. A theme it deployed is the same theme you can pull to your machine with the CLI, edit and push back.
This is the property we care most about, and it's why every write goes through the same core the Studio uses rather than a parallel path. If the agent could do things you then couldn't undo by hand, the whole arrangement would be a trap.
You're not paying a markup on tokens
An in-product AI feature has to price inference. That means either a credit system, or a per-seat uplift, or a quiet margin on tokens you were going to pay a model provider for anyway.
You bring your own agent and your own subscription. You're already paying for Claude or Cursor; we're not going to charge you a second time to route the same tokens through our servers at a markup. Our pricing is live sites, and the tool server isn't a paid tier.
Where this is worse
For a non-technical agency, this is harder. "Install a tool server and connect your agent" is more friction than typing into a box, and there's a real population of people for whom the box is the right product. We've accepted that.
It also means the quality of the build depends on the agent you bring and how well you brief it. We supply the tools, the model introspection and the guidance; we don't supply the judgement.
The short version
A prompt box in our product would know less than the agent you already have open. So we built the thing it can call instead, scoped it properly, kept production behind a human, and made everything it produces an ordinary object you can edit by hand.