The agent's desk
Why the agent plans before it writes, what it can see of your story, and why its work lands on a review branch.
The agent is behind a flag and is not switched on in the studio yet. Read this to know what is coming; do not go looking for the button.
The co-writer answers one question at a time. The agent takes a piece of work: "split chapter two into three chapters and give the courier a subplot". That is too big to review as one blob of output, and too big to trust unseen. So the agent's desk is built around three moves in order: it plans, it writes, and then you review.
The ◆ Agent pill on the co-writer bar aims the prompt field at the agent. The Sessions dropdown beside it lists the project's agent sessions with their state. If the pill is not there, the agent is not enabled in your studio.
First it decides whether you asked for writing at all
Your prompt goes through one model call before anything else happens. That call decides between two modes.
Chat. A greeting, a question, an idea request, thinking out loud. The agent answers in the thread. No branch is created, no run starts, no review is waiting for you afterward. Asking for suggestions counts as chat even when phrased as an order ("give me three ways this scene could end"), because proposing is not writing.
Task. You explicitly told it to change the story: write, add, restructure, delete. Now it produces a plan.
The bias is toward chat. Writing into your story uninvited spends your credits and your trust, so an ambiguous prompt gets an answer and an offer to write it in if you want.
Then it plans
A task plan is a short ordered list of phases, usually between two and six, each one a goal sentence: "Create the three new chapters", "Move the courier's scenes into chapter three", "Rewire the edges and check the compile".
The plan is not decoration. A phase is three things at once:
- the unit of work the agent executes in one model call,
- the batch label on every command that phase runs, which is how the review ledger groups them,
- the name of the checkpoint taken at the end of that phase, which is what a rewind rewinds to.
That is the reason for planning first. Not safety, since the review branch already makes mistakes cheap, but legibility: a plan that names its batches gives you a ledger you can read as "batch two, the cut" instead of an undifferentiated stream of a hundred commands.
Between phases the agent stops and re-plans. It looks at what it has actually written, at anything you have said in the meantime (see steering), at the credit budget, and at the Stop flag. It either keeps the remaining phases or replaces them.
What it can see
The agent reads your story through a fixed set of tools, on the branch it is working on. Nothing else is in its context except the story bible and your prompt.
| Tool | What it returns |
|---|---|
listChapters | Every chapter: its doc id, its chapter id, title, order |
readGraph | One chapter's scenes, edges with their conditions, and entry points |
readScene | One scene in full: title, staging, ending, and its beats |
listCast | The cast |
listVariables | Variable declarations, project-wide and per chapter, with types and choices |
readBible | The story bible text |
listAssets | Asset id, kind, and name |
checkCompile | The compiler's verdict: errors, unreachable scenes, dead ends |
What that list does not contain is as important. The agent does not see your uploaded files themselves, only their ids, kinds and names. It does not see the rendered stage, your published bundles, your collaborators' cursors, or anything outside this project. It has no memory beyond the current thread: a new session starts from the story and the bible, not from what you told it last week.
Chat questions are answered against main, because no branch exists yet. A running task reads the review branch it is writing on, so each phase sees the previous phase's work.
Then it writes, somewhere that is not your story
Every change the agent makes is a command: create a scene, insert beats, wire an edge, set a variable, splice the bible. Commands are the same language the editor itself speaks, which is why the agent cannot produce anything the compiler would refuse to understand.
Those commands execute on a review branch, forked from main when the run
starts and named agent/run- plus a short id. Your main branch is untouched
while the agent works, and there is exactly one door back: you press Merge.
This is why the desk is worth the extra step. An agent that edited main directly would leave you diffing your own story against your memory of it. Instead you get a branch you can open, read, play, hand-edit, rewind by a phase, merge, or throw away. Discarding is genuinely free.
What you do while it writes
Nothing, if you like. The run continues on the server, so you can close the tab. Reopen the project and the feed rebuilds itself from the run's ledger.
You can also keep editing. The review branch is never locked, not while the agent is writing and not while it awaits review. Hand-editing a draft and then merging it is an intended workflow. The ledger records the agent's commands only, and the merge dialog notes that your own edits ride along.
Other editors see a chip in the header saying the agent is writing, and on which branch. Clicking it opens the thread.
The parts that wait for merge
Chapters are not stored in a collaborative document, they are rows in the studio's database, so creating, renaming, or deleting a chapter cannot be undone by throwing a branch away. Those three commands are therefore held: recorded in the ledger, badged AT MERGE, and executed only when you merge.
There is one twist worth knowing, because it looks like a bug otherwise. A chapter the agent creates during a run is usable immediately: its scenes and beats are written straight away, and only the chapter row itself waits. If you discard the draft, the held command is voided and the chapter never existed.
Next: a run end to end.