> ## Documentation Index > Fetch the complete documentation index at: https://docs.avocadostudio.dev/llms.txt > Use this file to discover all available pages before exploring further. # Compare > The category sorts by one question: what is the tool permitted to change? Avocado Studio next to code-writing agents, hosted platforms, headless CMSes, visual page builders, and general AI assistants. Most comparisons in this space sort tools by what they can *do*. That separates almost nothing — every tool here can change a headline. The useful axis is narrower and much harder to fake:

What is the tool permitted to change?

Ask that, and post-launch web operations sorts into three camps. Each one is the right answer for somebody. They are not interchangeable, and the differences are structural rather than featural. ## The three camps ```mermaid theme={null} flowchart TB Q["What may the tool change?"] A["1 · Your code
An agent opens pull requests
against your repository"] B["2 · Values behind a boundary
Typed content operations against
a contract you declared"] C["3 · The whole site
You migrate onto their platform;
the site is theirs now"] A1["Safety comes from process
review · roles · approval · audit log"] B1["Safety comes from structure
the vocabulary has no verb for
'change a file'"] C1["Safety comes from the sandbox
there is no code for you to break"] Q --> A --> A1 Q --> B --> B1 Q --> C --> C1 style B fill:#7ED957,stroke:#14532D,color:#0a0a0a style B1 fill:#e8f7e2,stroke:#14532D,color:#0a0a0a ``` **Camp 1 — tools that write your code.** An AI agent works inside your repository and proposes changes as pull requests. Source by Webflow and Fimo are the notable ones. The reach is unlimited by design, which is exactly the point: a request like "add a pricing comparison table with a new layout" can genuinely be built, because the agent can write a component. Safety is procedural — a reviewer, a role, an approval gate, an audit trail. Every one of those is a human step, and the blast radius when one is skipped is a production deploy. **Camp 2 — tools that write values behind a declared boundary.** Avocado Studio. You register your own components as blocks with a schema saying which props are content. Everything the system can do is one of a fixed set of [typed operations](/concepts) — `update_props`, `add_block`, `reorder_items`, `update_page_meta`, and the rest. That vocabulary has no verb for "change a file". A model at full confidence with every guardrail disabled still cannot touch a component, a route, a dependency or the build, because the edit is not expressible. The trade is real: anything that needs new code needs a developer, as it always did. **Camp 3 — tools that own the site.** Platforms where the site itself lives in their model, on their infrastructure — Framer and Wix are the ones you will actually be compared against. Their agents are good, and getting better quickly: they design on a canvas, build a CMS, write components, and several of them now let Claude Code or Cursor drive the project from your terminal. Nothing can go wrong in your codebase because there is no codebase of yours involved. The entry price is that the site has to be theirs first, and there is no supported way to take it back out. ### Who each camp is right for | Camp | Right for you if | | - | - | | **1 · Writes your code** | You want one surface for both content and code changes, you have a review culture that genuinely holds, and you accept that a marketing request can reach your build. | | **2 · Writes values behind a boundary** | Your site exists, a developer owns the code, a marketer owns the words, and you want that separation to be enforced by types rather than by trust. | | **3 · Owns the site** | You are starting from nothing, you have no stack opinions, and time-to-deployed matters more than owning what got deployed. | ## At a glance | | Code-writing agents
(Source by Webflow, Fimo) | Platforms that own the site
(Framer, Wix) | Headless CMS
(Contentful, Sanity, Storyblok, Strapi) | Visual page builders
(Builder.io, Plasmic) | General AI assistants
(ChatGPT, Claude) | **Avocado Studio** | | - | - | - | - | - | - | - | | Can reach your components, routes, build | yes | n/a — theirs | no | no | depends on the harness | **no — not expressible** | | Works on the site you already have | yes | no — rebuild on their platform | yes | partial — content sections | n/a | **yes** | | You keep the code and the content store | yes | no — no supported code export | yes | no | n/a | **yes** | | Typed, schema-validated edit vocabulary | no — free-form code | no | no — free-form fields | no | no | **yes — Zod-validated** | | Live preview of the real page, with undo | via a preview deploy | yes | via a preview build | yes | no | **yes** | | Runs on your own infrastructure | no | no | varies — Strapi yes | no | n/a | **yes — Apache 2.0** | | Your own LLM keys, no resold tokens | no | no — metered AI credits | n/a | no | you pay the provider | **yes** | | Driveable from any MCP host | no | yes — via their own agent bridge | no | no | n/a | **yes — 49 tools** | Self-hosting is the licence-and-deployment claim, not a pricing claim: Avocado is Apache 2.0, runs on infrastructure you control, and carries no per-seat licence. What you spend is your own hosting bill plus your own token spend, billed to you by Anthropic, OpenAI or Google directly. ## vs. tools that write your code (Source by Webflow, Fimo) This is the closest comparison and the one worth getting right, because both of us are selling "your marketing team can change the site without filing a ticket." The difference is where the guarantee lives. A code-writing agent is powerful precisely because it is unbounded. It can add a section that does not exist yet, restyle a component, wire a new route. No content-operation vocabulary can match that, and if what your team actually needs each week is new *structure* rather than new *values*, that reach is worth a great deal. What you pay for it is that the constraint is procedural. The reviewer, the approval, the protected branch, the audit log — all good practice, all human steps, all skippable on a Friday afternoon. The system's reach is not smaller when the process is skipped; only the odds change. Avocado's constraint is in the type system instead. The 19 operation literals are defined in `packages/shared/src/schemas.ts` and every plan is parsed against them before anything is applied. There is no flag, no admin toggle and no prompt that adds a twentieth operation meaning "edit this file." | | Code-writing agent | Avocado Studio | | - | - | - | | Can add a brand-new component | yes | no — a developer does that | | Can break your build | yes | no | | Failure mode of a bad model output | a bad pull request, or a bad deploy | a rejected plan | | What protects you | review, roles, approval, audit log | the edit vocabulary itself | | Where the change lands | your git history | your content store | | Marketing can ship without a developer | yes, within review | yes, within the declared fields | A process is weaker than a type. If you disagree with that sentence, camp 1 is a reasonable choice and you should take it seriously. ## vs. platforms that govern the agents **"Governed agents" is no longer a differentiator — it is the category's answer.** Content platforms that spent a decade selling themselves as experience suites now sell themselves as agent platforms, and the argument they make is one Avocado agrees with entirely: an agent cannot be trusted to act until the content is well modelled and the rules are explicit. The disagreement is not about whether governance is needed. It is about what the governance is made of, and where it lives. | | An agentic content platform | Avocado Studio | | - | - | - | | Where the rules live | in the vendor's console, as configuration | in your repository, as the schemas on your own components | | What enforces them | the platform, at request time | the type system, before a plan is accepted | | Who can relax them | anyone with the right admin permission | anyone who can get a pull request merged | | Where your content has to be | modelled in their system | exactly where it is now | | Failure mode of a bad rule | silently applied to live content | a rejected plan | Two consequences follow, and both are practical rather than philosophical. **A rule expressed as configuration is a policy; a rule expressed as a schema is a diff.** The first can be changed by someone with a console open on a Friday afternoon and leaves no trace anyone reviews. The second goes through your normal review, and your CI runs against it. That is the same argument as camp 1 above, one level up: the mechanism of the guarantee matters more than the strength of the promise. **A platform that governs your content has to hold your content.** That is a migration, and on a suite the migration is not a step in the project — it is most of the project's cost and most of its calendar. Avocado holds none of it: your pages stay in the CMS you already chose, and an edit made in chat lands exactly where a hand-edit in that CMS would. See [CMS adapters](/integration/cms-adapters). Where such a platform genuinely wins: if you have no content model worth keeping, someone else's is a faster way to acquire one than building your own. ## vs. platforms that own the site (Framer, Wix) **This comparison is not about the agent. It is about whose site it is.** Framer is the sharpest version of this camp, so take it at its strongest. Its agents work on the live project rather than on a mockup: they build pages, turn a screenshot into a design, set breakpoints, write components, create and fill CMS collections, and generate SEO metadata. Branches let a team review and merge a change before it goes live. A terminal agent — Claude Code, Cursor, Codex — can be connected to the project and make structured changes without the canvas even being open. Judged as an editing experience, that is excellent, and nothing here is an argument that it is not. The whole of it is available on one condition: the site has to be a Framer site. There is no supported code export — a published site depends on their React runtime and their backend services, so the scrapers that promise otherwise give you flattened HTML, not your components back. For a site that does not exist yet, that is a reasonable trade and often the right one. For a site that already exists, the entry price is a rebuild, and the exit price is that there is no exit.

Framer's agent is excellent — on sites built in Framer. Avocado is that agent for the site you already shipped.

| Where a platform that owns the site wins | Where Avocado wins | | - | - | | Zero to deployed with no engineering | Works against the codebase you already have | | Design generation, breakpoints, canvas editing | Your components, your design system, your hosting | | Hosting, CDN, analytics and experiments included | Nothing of yours moves — the CMS you chose stays the store | | Nothing to operate, one account, one bill | Self-hosted, Apache 2.0, no per-seat licence | | Their agent can write a component you do not have | Your own LLM keys — no metered credits on top of them | The two products also fail in different places, which is usually the more useful thing to know. Ask a hosted platform's agent for something its canvas cannot express and you are stuck inside a system you cannot drop to code in. Ask Avocado for a component that does not exist and it will tell you so, because the [operation vocabulary](/concepts) has no verb for it — that request is a developer's, as it always was. If you would answer "I do not have a site yet," stop reading this page and go use one of those. Avocado has nothing to offer you until the site exists. ## vs. headless CMSes (Contentful, Sanity, Storyblok, Strapi) **Not a replacement — a complement.** Avocado does not store your content. Your CMS does. Avocado reads and writes through an adapter to whatever you already chose, so an edit made in chat lands in the same place a hand-edit in the CMS would. See [CMS adapters](/integration/cms-adapters). | Where a headless CMS wins | Where Avocado wins | | - | - | | Content modelling, references, taxonomies | Editing in plain language, with no field hunting | | Editorial workflow, scheduling, roles | A live preview of the real page while the plan streams in | | Webhooks, delivery APIs, CDN | Multi-step changes from one sentence, applied atomically | | Asset management and transformations | Edits flow through the *same* adapter your site already uses | **Run both.** A typical deployment has Contentful, Sanity, Storyblok or Strapi behind it. The content team keeps modelling content in the CMS; everyone else makes routine changes in Avocado and rarely opens it. Rich text crosses the boundary through a shared pivot format with converters for [four CMSes](/integration/cms-adapters), and Storyblok, Sanity and Contentful additionally have [field-table lens packs](/integration/field-table) that derive the block schema, the property panel, the projection and the merge from one declaration. Working examples in the repo cover JSON files, Contentful, Sanity and Strapi. Field-level localisation — one document holding a German, English and French value per field — is where CMS integrations usually go wrong, and where they corrupt data silently when they do. [Multilingual](/integration/multilingual) documents the two rules and the two traps. ## vs. visual page builders (Builder.io, Plasmic, Storyblok Visual Editor) **Different editing model, and you do not have to choose.** Visual builders are direct manipulation: drag a section, click a field, set a prop. Avocado's default surface is an AI chat editor with a live preview — you describe the change, the planner emits typed operations, and they stream into the real page for approval. | Where visual builders win | Where Avocado wins | | - | - | | Pixel-level positioning and layout work | Semantic edits — "make the pricing copy less formal" | | Direct manipulation is familiar to designers | Several changes across several pages from one prompt | | Mature ecosystems and template libraries | Schema-validated operations, so there is no broken intermediate state | | Built for a designer's daily loop | Your own components are the blocks, not theirs | Avocado also ships a visual editor of its own, built on [Puck](https://puckeditor.com/), and it is enabled per site. Chat edits and drag-and-drop edits produce the same typed operations against the same content, so the two surfaces cannot drift apart. See [Puck mode](/integration/puck-mode). ## vs. using a general AI assistant directly (ChatGPT, Claude) **Same models, different layer.** Avocado runs on the same providers you would use directly — it is your Anthropic, OpenAI or Google key either way. The difference is everything wrapped around the model call. * **Typed operations.** The model emits structured operations validated against your Zod schemas. Malformed output is rejected before it reaches your content, instead of arriving as plausible-looking markup that fails at build time. * **Block schema awareness.** The planner is given the exact props each of your registered blocks accepts. A general assistant is guessing at your content model, because it has never seen it. * **Atomic apply.** A multi-operation plan applies as a unit or not at all. There is no half-edited page. * **Live preview.** Changes appear in your actual rendered page as the plan is generated, not as a snippet to paste somewhere. * **Undo and a version log.** Every plan is reversible and recorded. Destructive operations are held for explicit approval before they run. * **It writes to the right place.** The result lands in your CMS or content store through your adapter, not in a chat transcript that someone still has to transcribe. If the job is "help me word this paragraph," a general assistant is the right tool and always was. If the job is "apply that paragraph to the live pricing page, in the right field, reversibly," that is the gap Avocado fills. And if you want both, the [MCP server](/integration/mcp-server) exposes 49 tools over stdio or Streamable HTTP to any MCP host — Claude Code, Claude Desktop, Cursor and others — so your assistant can drive Avocado as a tool while the edits stay typed. ## What the integration actually costs Bringing in a real site — one with a CMS behind it, or shipping in several languages — takes a developer and a coding agent a few days inside the repository, not an afternoon. The work is bounded, mostly mechanical and largely one-time: declare which components are blocks, say which of their props are content, mark up the renderers so the preview can find the fields, and wire the editor routes. But it is real work, and no honest comparison should hide it. So the recommended path is not "follow a tutorial". It is [hand it to your own coding agent](/sites/coding-agent) — Claude Code, Codex or Cursor already knows your codebase, and the change lands through your normal review flow. The [onboarding agent](/sites/site-agent) built into the editor is a second path, and it is early enough that you should treat its first pass as a draft. Either way, [the contract](/sites/manual) is the same document, and [coverage checks](/integration/coverage) are what tell you it is finished. Against camp 1 and camp 3, that integration cost is Avocado's honest disadvantage. What it buys is a boundary that holds afterwards, without anyone having to remember to hold it. ## When Avocado is the wrong answer Being explicit about this is more useful than another win column. * **You are building a brand-new site and have no opinions about the stack.** A platform that owns the site — Framer, Wix — will get you deployed sooner, and Avocado's integration cost buys you nothing you care about yet. * **You work visually first and never want to type.** A visual page builder fits that loop better. Avocado's [Puck mode](/integration/puck-mode) narrows the gap, but the chat surface is the centre of gravity. * **Your site has no structured block model.** Operations run against typed blocks with validated props. If your homepage is one long `page.tsx` of bespoke JSX, that has to become blocks first — real refactoring work, whoever or whatever does it. * **You are not on Next.js or Astro.** Next.js 15 and 16 on the App Router is the tested path, and Astro 5+ has a shipped integration — [`@avocadostudio-ai/astro`](/integration/astro-integration), one block in `astro.config.ts`, your own `.astro` components, no React islands. The framework-agnostic [`/core` primitives](/integration/non-nextjs) are shipped and real, and the route contract is web-standard `Request`/`Response`, but on Remix, SvelteKit, Nuxt or Hono you would be a first mover. * **What your team needs weekly is new structure, not new values.** If most requests genuinely require a component that does not exist, an agent that writes code is doing the job you have, and Avocado will feel like a locked drawer. If you are unsure which of these describes you, get in touch — the answer is usually obvious after a few questions about what your team actually changed last month. ## See also * [Core concepts](/concepts) — pages, blocks, operations, draft mode * [How it works](/how-it-works) — from a sentence to an applied, reviewable change * [Architecture](/architecture) — the services, the packages, and the data flow * [Custom blocks](/integration/custom-blocks) — register your own components as the editable surface * [Hand it to your coding agent](/sites/coding-agent) — the recommended integration path This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.