Take one real interaction and follow it all the way through, because the abstract pitch — "an assistant that acts, not just answers" — doesn't tell you anything until you watch it happen. Someone types "build me a habit tracker with streaks" into the Ask-AI button that floats on every page of this site. Here's what actually occurs between that sentence and a running build, and where we chose to put a human hand back on the wheel.
The sentence
Nine words, no punctuation, no menu navigation, no idea which page the builder even lives on. That's the input, and it's the same shape as most requests this thing gets: not a command, a want. Nobody phrases it as "open the builder, name the project Habit Tracker, populate the prompt field with a description of streak tracking, and set focus to the start button." They just say what they want to exist. The gap between those two phrasings — want versus instructions — is the entire feature.
The parse
Whatever language that sentence arrives in, it gets handled in that language — we support twenty across the product, matching the platform's wider multilingual posture, and the assistant isn't running a translation layer on top of a fixed English script, it's reasoning natively in whatever you typed. For "habit tracker with streaks" specifically, the parse has to do three things at once:
- Recognize this is a build request, not a question
- Extract a project name
- Extract enough of a spec that the prompt field isn't blank
Get any one of those wrong and the user lands on a builder that doesn't match what they asked for, which is worse than not acting at all — now they have to notice the mismatch, then fix it, then start over.
The staged screen
This is the part that's easy to undersell in a demo and easy to get wrong in practice: it doesn't start the build. It opens the builder with the project named, the prompt field already written, and the run staged one click away. That's a deliberate stopping point, not a shortcut we ran out of time to finish. Opening a page and pre-filling a form is cheap to be wrong about — worst case, you edit the text or close the tab. So the assistant just does it, no confirmation dialog, no "are you sure you want to navigate."
The click that was still yours
Starting the build is a different category, because starting the build spends credits — real ones, debited from your account the moment the run kicks off. That's where the proportional rule kicks in:
| Action type | What happens |
|---|---|
| Cheap to undo — navigation, staged text | Happens automatically, no confirmation |
| Spends money or real compute — starting the build | Waits for a deliberate click from you |
We landed there after going back and forth on it, and I'll admit neither extreme felt obviously right. Confirm on everything and you've rebuilt the old click-through-three-menus experience with a chat window bolted on top, which is worse than what it replaced. Confirm on nothing and eventually the parse guesses wrong on an ambiguous request and fires off a run nobody asked for, on someone else's dime. For this exact example, that means: the assistant gets you to the loaded builder in one shot, and the button that actually spends anything stays a real, deliberate, human click.
The rail underneath
One thing you can't see anywhere in this flow, which is exactly why it matters: every part of it — the navigation, the staged prompt, the eventual build — happens inside your workspace and nobody else's. The assistant can't be talked into reaching across tenants no matter how the request is worded, because it isn't a special-cased chat feature sitting outside the permission system — mechanically, it's just another agent on the platform, running under the same per-account boundary every other agent runs under. There's no separate "can the chatbot see this" question to answer, because the answer was already decided by the infrastructure before the chat feature existed.
What doesn't happen
Follow this same example one step further and you hit the edge of what the assistant will do unprompted, and it's worth being specific about where that edge sits. It'll open the builder for you. Beyond that:
- It won't spend beyond what you already approved
- It won't post the finished project anywhere under your name
- It won't take any action that leaves the sandbox of your own workspace and touches the outside world
That entire category doesn't get an assistant-driven path — not a stricter confirmation, not a path at all. If you want a project public, that's still a button you find and press yourself, same as it's always been.
Why the stop points are where they are, not somewhere safer
We could have made every one of these steps ask permission and called it cautious. I don't think that would have been caution — I think it would have been a slower version of the exact busywork the feature exists to remove. A chatbot that only ever describes where the build button is has a small blast radius when it's wrong: it wastes thirty seconds, you're mildly annoyed, nothing spent. An assistant that stages a real build gets that wrong in a costlier way if the guardrails aren't right, which is the actual reason the confirm-before-spend line exists — not as a hedge we added to look responsible, but because we watched where the failure mode would land and put the stop exactly there. Everything before that line — reading the sentence, staging the screen, getting you one click from done — needed no permission at all, because none of it can hurt you.
