Five pivots in seven months, and the week two competitors shipped my roadmap

The last time I wrote here, Avocado Studio was a chat editor with a Puck canvas bolted on. Since then it has changed what it is five times. Some of those changes I planned. Most of them happened because something real broke the plan.

Here’s the story, and where it leaves us now that the big players have arrived.

Pivot 1: from my demo site to your real one

The editor worked beautifully on the site I built for it. That turned out to be the problem.

Then I tried it on real sites. A holiday rental on Next.js. An activity park with three languages on Storyblok. A booking business on Sanity, also in three languages. Every one of them broke something the demo never touched. Their content didn’t live in my page format. It lived in their CMS, in their field names, in their languages. Their components weren’t my components.

So the question changed from “can AI edit a website?” to “can AI edit this website, without anyone rebuilding it first?” That meant a toolkit you install into an existing site, adapters that read and write the CMS you already have, and a publish step that writes back only the fields that changed instead of overwriting whole documents. The first version went to npm on 28 August. There have been 43 releases since.

Pivot 2: from a server you run to a library you install

Early on, Avocado was three apps: an editor, a site, and an orchestrator server in the middle that holds the drafts and talks to the model. That’s a lot to ask of someone who just wants to edit their marketing site.

Now the orchestrator can run inside your own Next.js app, as one route handler. No extra server, no extra deploy. I also seriously scoped the opposite: a hosted SaaS. I decided against it. Running it for you means holding your content and your CMS credentials, and that’s a different company from the one I want to build. The packages are Apache-2.0 on npm, and the plan is to be easy to adopt, not easy to lock into.

Pivot 3: the integrator became an agent

I wrote setup docs. Then I watched who actually followed them: Claude Code and Codex, not people.

So the setup instructions now ship inside the npm package as agent skills, versioned with the code they describe. You run one command in your repo, point your coding agent at it, and it wires Avocado into your site. Then npx avocado qa checks the result: does the preview render, are the editable fields marked, does the editor find every block. My docs site had once taught a function call that didn’t compile. A skill in the package can’t drift that way.

Pivot 4: from edit buttons to agents

In September I added agents that work while nobody’s watching: a watcher that flags edits that look like accidents, scheduled checks, an inbox where they leave findings.

It was technically fine and too narrow. When I showed it, the honest feedback was that it sounded too complicated for a site owner. A separate agent for each job, each with its own settings, is how an engineer thinks about it. Nobody who runs a business wants to manage a team of bots.

Pivot 5: one assistant, connected to your business

So I threw out the “many agents” picture and built what people already know from Claude and ChatGPT: one assistant per site, made of the same kinds of parts.

• Connections: Google Search Console, Google Analytics, Google Drive and PageSpeed. You click Connect Google, sign in, pick your property and your folder. No keys in config files.
• About this site: your business, your voice, your goals, and what never to touch. It reads this before every answer.
• Skills: know-how it loads when a task needs it. When your opening hours change, it finds every place the site states them, in every language, and proposes all the edits at once. It knows how to write the title Google shows so it matches what people actually search for.
• Permissions: for each kind of action, allow, ask first, or never.
• Routines: “check my search traffic every Monday”, which only ever proposes; it never publishes on its own.

And it lives in the same chat box. Ask “why did bookings drop on the pricing page?” and it reads Analytics and Search Console before answering. Ask it to put this summer’s photos in the gallery and it pulls them from your Drive folder, looks at each one, writes the alt text from what’s actually in the picture, and adds them through your own gallery component. Then it suggests what to do next, like the page whose search clicks fell last week.

It’s early. It’s switched off by default, it’s labelled pre-alpha in the editor, and I’m testing it on real sites before anyone else gets it. But this is the first version that feels like the product rather than a feature.

Then Webflow and Fimo shipped the same week

On 2 September, Webflow announced Source: agents working on your real codebase, an inbox where they leave work for review, aimed at marketers. Six days later Fimo, from the founders of Strapi, relaunched as an “autonomous website platform”: your code, your agents, each run in its own sandbox, every change a pull request. Around the same time, three of the big enterprise content platforms dropped the “digital experience” label and rebranded around agents.

My first reaction was the one you’d expect. My second was relief. Two well-funded teams independently decided that the future of a website is agents that propose and people who approve. That’s the bet I’d made in February. I’m not arguing that the category exists any more.

Where we stand

We agree on the destination. We disagree about what the agent should be allowed to touch.

Source and Fimo let agents write code. Source says it plainly: agents “without the constraints of an abstraction layer”. That’s powerful, and a bad change is a bad deploy, which is why Fimo gives every run its own sandbox and every result a pull request.

Avocado’s agents never write code. They write typed edits against your own components: change this field, add this section, move that one. Each edit is checked against your component’s schema before it’s applied, and each one can be undone on its own. The assistant can’t break your build, because it never touches the build. For content work, which is most of what happens to a website after launch, I think that’s the better trade.

Avocado edits your CMS, not just your repo. If your content lives in Sanity, Storyblok or Contentful, that’s where it gets written, field by field, in the right language. Neither Source nor Fimo claims that.

Avocado runs in your app. No console of ours, no hosting of ours, no delivery layer of ours. Install a package, keep your stack.

Where they’re ahead, honestly:

• Review across a team. A pull request or a shared inbox survives restarts and works for five people. My review flow is built for one person in the editor; the durable version is still pre-alpha.
• Greenfield and design. If you’re starting from nothing, or want an agent to redesign your hero, a code-writing agent will do more for you.
• Reach. Webflow has a conference stage. Fimo has a free tier that’s live today. I have a blog.

What’s next

The assistant gets to more real sites, carefully, one at a time. The things that make it trustworthy, like proposals that survive a restart and a record of what each routine actually changed, come before anything that makes it more autonomous.

Seven months in, the lesson is the same one from the first prototype, just at a bigger scale: what matters isn’t how much the AI can do. It’s whether you can trust what it did, and take it back if you can’t.