Why Studio didn't work
We built Studio so a small business owner could build their own AI agent without writing a line of code. Almost nobody did.
That took me longer to accept than it should have.
Studio was a no-code agent builder. The logic was clean: most SMEs can't code, agents are useful, so give them a builder and let them assemble their own. Templates, a visual flow, no terminal. Put agent-building in the hands of people who'd never open a code editor.
Here's what I missed. The people who can't code don't want to build an agent. They want the agent. Configuring triggers, steps, and knowledge is still building, even with no code on the screen. It's work, in a domain they don't understand and don't want to. A bakery owner doesn't want to learn what a tool call is. She wants her WhatsApp answered.
And the minority of SMEs technical enough to enjoy building don't need Studio either. They've already got Lovable, or Bolt, or whatever vibe-coding tool is having its moment. When I built a Telegram-to-Notion bot in an afternoon with Lovable, the lesson was how much ground one motivated person can cover now. We were never going to out-build Lovable for those people.
So Studio sat between two groups and served neither. Too much work for the people who can't code, not enough leverage for the people who can. There was no user in the middle who wanted exactly the thing we'd built.
I'd actually written the reason down before I lived it. A few weeks earlier I argued in adaptive software that blank-canvas AI builders have a cold start problem, and what wins is an 80% ready vertical template the business shapes by talking to it. Studio was the blank canvas. I described the trap and then walked into it anyway.
What SMEs actually want is boring. Something that already does most of the job the moment they get it, and a short conversation to tune the rest. Not a canvas. Not primitives. The thing, mostly built, on day one.
That's what pushed us to Vobase.
The flip is subtle and it's the whole point. Studio asked the customer to build. Vobase builds for them. AI coding agents generate most of a working agent on Vobase's framework and defaults, then we or an integrator finish the last 20% and hand over something that runs. The customer never meets a builder. They get a working agent, and they shape it the way our customers already do, by talking to it, without ever knowing what a system prompt is.
It's the same engine we built for Studio, pointed at a different question. Studio asked "how do we help them build?" Vobase asks "how do we build it for them, fast, without it turning into bespoke services on every deal?" The framework is the part that keeps the 80% from being hand-rolled each time.
That question has a much bigger market than I expected. Vobase isn't SME-only. The same build-it-then-tune model works for enterprises, except their own developers extend the framework instead of us. SME or enterprise, nobody wants to start from an empty builder.
I wrote a week or so ago about how I prioritise between Envoy and Studio. That post is already out of date, which is more or less the point of this one. When I wrote it I still believed Studio was the long-term bet. Watching how little it got used changed my mind faster than I expected.
The lesson isn't "no-code is bad." It's narrower. Work out who the user actually is before you decide what to hand them, and move the moment usage tells you something, even when you've sunk months into the thing. Especially then. The months we spent on Studio feel like a reason to keep going. They're exactly not. That's the sunk cost talking.
We're early with Vobase as the front door, and "AI generates 80%, a human finishes the rest" is easier to write than to make reliable across every vertical. But the shape feels right in a way Studio stopped feeling about a month ago. The test is simple now. Did the customer have to build anything? If yes, we've slipped back into the old mistake.