# One Product, Two Front Doors: Why We Split the Octomind Panel

> Our panel had fourteen menu entries before your first answer. How we split it into Chat and Studio without splitting the product into two apps.

_Update, September 2026: the two boards have since merged into one panel shaped like Chat. The Studio-only machinery now sits behind a single **Advanced** row at the foot of the sidebar; there is no board switch any more. The panel itself is now a paid surface: free accounts have the hub, while chats, machines and routines need a subscription ([The free plan becomes the hub](/blog/free-plan-is-the-hub))._

Every product that gets good at something eventually gets hard to start using. Ours did it the classic way: each feature we shipped was genuinely useful, each one earned a place in the sidebar, and one morning the sidebar had fourteen entries, machines had six tabs each, and a new account met a four-step wizard before it ever saw an agent do anything.

That's the right panel if you signed up for a cloud machine. It's a wall if you signed up to get something done.

The tell was in our own data. When someone creates an account we ask what they're here for, and the options are build software, research and write, automate routine work, or just exploring. Three of those four are not developers. All four were being handed a machines dashboard.

So we split the panel in two. **Chat** is conversations and nothing else, and it's where new accounts land now. **Studio** is the full panel, unchanged. One account, one wallet, one click between them.

## The split is not a "beginner mode"

This distinction matters more than it sounds, and getting it wrong is how these projects fail.

A beginner mode is a setting that admits the product is too hard and offers to hide some of it. It ages badly: nobody self-identifies as a beginner, the docs fork, support has to ask which mode you're in before they can help, and every screenshot is wrong for half the userbase.

The model that works is the one exchanges have used for years. Coinbase has Coinbase and Coinbase Advanced. Binance has Convert, Spot and Futures. Those aren't difficulty levels — they're different front doors to the same exchange, with the same account and the same balance behind each. Nobody using Convert thinks they're in the kiddie pool; they think they're using the tool that matches the job.

That's the frame we took. Not simple-vs-hard. **Conversations-vs-machines** — two jobs, two doors, one product.

The naming follows the frame. We call them Chat and Studio, never Simple and Advanced, because a name should describe what you do there rather than rank the person doing it.

## The four rules

Anyone can draw two sidebars. Keeping them one product is the actual work, and it comes down to four invariants we refuse to break.

**A board changes navigation, landing screen, and vocabulary. Nothing else.** Same routes, same components, same data underneath. In our codebase this is one branch in the layout — not a fork, not a second app, not a parallel set of pages that drift apart over six months. If we ever need to build a screen twice, the split was wrong.

**No asymmetric state.** Everything created in Chat is fully visible and editable in Studio and the reverse. A conversation in Chat _is_ a session in Studio — the same row in the same table. The moment one door can create something the other can't see, you own two products and twice the support load.

**A board is not a plan and not a permission.** A free account can sit in Studio. A top-tier account can live in Chat. Every deep link resolves in both — open a machine URL from an email while you're in Chat and it renders. Chat leaves things out of the _menu_; it never blocks a _route_. In practice this means every board-conditional in our code governs presentation only, and one that ever gates a capability is a bug, not a feature.

**One switch, always visible, no confirmation.** Bottom of the sidebar, both directions, no dialog. A switch you can't undo in one click isn't a preference, it's a trap — and a trap is exactly what makes people avoid trying the other door at all.

## What Chat actually removes

The interesting design question wasn't what to put in Chat. It was what to take out and still have the product work.

**The machine.** Chat never says the word. Your first message creates a computer in the cloud, wakes it when it's asleep, and lets it sleep when you're done. There's no size to choose, no image to pick, no name to type. This is the biggest one, and it's only possible because the machine layer was already good enough to be automatic — we'd built the auto-create path months earlier for the chat connectors, where there is no UI to pick a machine from either.

**The model picker.** A dropdown of provider-prefixed model IDs is the single most jargon-dense control we own, and `auto` already routes each request to a sensible model by purpose. Studio keeps the full catalog for people who want to pin a specific one.

**The dashboard.** Studio's Overview reports running machines, three cap windows, and an activity feed. That's a good screen for an operator. Chat's landing screen is a line to type on, because a person who wants a task done is not an operator.

**The wizard.** In Chat there isn't one. You land, you type, the agent works. The four screens it replaced — pick a persona, pick a plan, make a machine, choose a task — all happened before you'd seen the product do anything, which is the worst possible moment to ask someone for a decision.

Removing a step is easy; replacing it is the actual work, so the guidance moved rather than vanished. Nothing appears before your first conversation. After it, a short "Next" block offers three things worth doing — connect a channel, pick a plan, invite someone — one line and one click each, each derived from your account so it completes itself as you use the product and disappears for good when you're done. The plan question in particular now arrives at the moment you've seen the thing work, which is both kinder and the better place to ask.

The persona question didn't come back at all. We infer it instead: every example task is tagged with who it suits, so the first one you pick tells us what you came for. Watching what someone chooses beats asking, and costs them nothing.

That produced our favourite small detail. The examples were prefilling the prompt and waiting for you to press Start — but half of them are complete sentences with nothing to edit, so that second click confirmed text you hadn't written. Now an example with a blank in it loads with the blank _selected_, ready to type over; an example without one just runs.

What stayed is the part people actually keep paying for, and we promoted it: connect Telegram, Slack or WhatsApp and message your agent like a person. That's the difference between this and a chat window. The agent doesn't live in the tab.

## Two things we got wrong on the way

Worth writing down, because both were the kind of bug that only shows up in the seam between old and new.

**The default flipped under the user's feet.** New accounts should start in Chat, existing ones should stay in Studio, and rather than ask anyone we derived it: if you already own a machine, you've been living in the full panel, so stay there. Reasonable — except the derivation was live, and a new Chat user's _first message creates a machine_. One sentence in, they satisfied "owns a machine" and got moved to Studio mid-flow. The fix is that the derivation is computed once, the first time we see the account, and then stored. A default that keeps re-deciding isn't a default.

**The preference didn't survive a refresh.** We stored the choice on the account, which is correct for carrying it to your other devices, and wrong as the only copy: during the deploy window the API didn't know the field yet, rejected the write, and every reload dumped people back into the panel they'd just left. A view preference that needs a server round-trip to survive F5 is broken by construction. It's stored locally first now, with the account copy as the cross-device sync.

Both bugs have the same shape: we treated a UI preference like domain state. It isn't. It should be cheap, instant, and impossible to lose.

There was a third, and it's the one worth stealing. A list you haven't fetched yet is not an empty list, but the code kept treating it as one. The board derivation read your machines before they'd loaded, so a single failed request could file a long-time user into Chat permanently. The dashboard rendered its setup checklist off a sessions array that starts empty, so it appeared and then retracted itself on every single reload — a flicker one of us finally got annoyed enough to chase. The files screen invited people with files to go start their first chat. Same mistake, three costumes: **unfetched means unknown, and "unknown" should render nothing rather than a confident guess you take back a moment later.**

## Where this goes

Chat is deliberately unfinished in a few places. There's no simple editor yet for how the agent should behave — that lives in Studio's config screen and deserves plain-language controls of its own. Scheduling exists as workflows in Studio, but "run this every morning" belongs right inside a conversation, and that's the next obvious thing. Named speed presets are waiting on a model catalog that describes its own tiers; hardcoding model IDs against a roster that shifts monthly would rot inside a quarter. And a few screens Chat borrows from Studio — connections, billing, docs — still talk in Studio's vocabulary; they're simple in name before they're simple in fact.

And Studio isn't finished either. Developers building _on_ Octomind — the API, keys, request logs — get a proper section there rather than a third door, because everyone using our API is already a Studio user and a third navigation shape would just make them hop.

If the full panel was always more than you needed, [open Chat](https://octomind.run/app) and type a sentence. If you want the machines, terminals and config, Studio is one click away — and it isn't going anywhere.