The operator is the agent at the centre of Kaer. You describe an outcome, and it plans the work, splits into parallel hands, runs real code, and stitches everything back into one reviewable result. The whole point is that you can read what it is doing at any moment without scrolling a log, and step in whenever you want.
How to read the blob
The operator shows up as a single soft mark while it thinks and works. That mark is the planner visual, and its colour tells you the state at a glance, the way a status light does. You learn to read it in a day, and after that you rarely need to open anything else to know what is happening.
Idle means it is resting and waiting for you. Thinking means it is reading your goal and forming a plan, before it has touched anything. Working means it is actively building, and usually doing several things at once. Confirm means it has paused and is waiting for your approval. Done means the turn has finished and is ready to review. Error means something needs your attention before it can continue.
The thing to internalise is that the blob is not decoration. It is the fastest signal you have. When it sits on confirm, work has genuinely stopped and is waiting on you. When it pulses on working, the parallel hands are mid-task and there is nothing for you to do but watch or interrupt.
Anatomy of a turn
A turn is one request from start to finish, one message in and one outcome out. Every turn moves through the same shape, and knowing that shape is most of what it takes to work with the operator confidently.
It starts with a goal, which is you describing what you want in plain language. The operator answers with a plan, a short and readable list of the steps it intends to take. Once you approve, it splits the plan into branches, which are the parallel work streams the cursors run at the same time. Each branch posts a checkpoint the moment its piece is stable, so you see progress as it lands rather than at the very end. The operator then stitches the branches into one coherent change you can review. Finally the whole turn collapses into a trail, a single card with a one-line summary you can re-open later.
Here is what a single turn looks like as a transcript, with three branches running under one goal:
You Build a pricing page: hero, a three-tier table, and an FAQ.
Blob Plan (build mode):
1. Hero section with headline + CTA
2. Three-tier pricing table (monthly/annual toggle)
3. FAQ accordion, 6 questions
Approve to branch?
You Approve.
Blob Branching into 3 cursors...
branch A · hero ............... checkpoint → preview ready
branch B · pricing table ...... checkpoint → preview ready
branch C · faq accordion ...... checkpoint → preview ready
Stitching branches into one change...
Blob Done. Pricing page assembled. 1 file changed, preview live.
Trail: "Built pricing page — hero, 3-tier table, FAQ."You can interrupt at any point in that sequence, to sharpen the brief while it works or to stop a branch that is heading the wrong way. The turn is a structure you steer, not a black box you wait on.
The three modes
Every turn runs in one of three modes, and the mode decides how much rope the operator has before it stops to check with you. You pick the mode per turn, so a scoping question and a ship-it instruction can use different settings in the same thread.
Plan mode means the operator only thinks. It returns a plan and changes nothing at all. Reach for it when you want to scope a piece of work, sanity-check an approach, or get an estimate before you commit to anything. Nothing happens to your files or any live system in plan mode.
Build mode is the default and the one most work runs in. The operator plans, then builds, pausing for your approval on the steps that matter. It is the balance most people want: real progress, with a hand on the wheel at the decisions worth a second look.
Auto mode lets the operator run end to end on its own. It still stops for anything destructive or irreversible, but otherwise it carries the turn all the way through without waiting on you. Use it for work you trust it to finish unattended, such as a well-scoped build you have run a version of before.
A good rule of thumb: scope in plan, do the real work in build, and graduate a turn to auto only once you have seen the operator handle that kind of task cleanly.
Approvals
The operator asks before it does anything it cannot quietly undo. Deleting data, deploying to production, spending money, or touching a live system all trigger a pause. When the blob lands on confirm, the work is genuinely stopped, and you have three choices: approve the step as proposed, edit the step before it runs, or send the operator in a different direction entirely.
Approvals are a feature, not friction. They are the contract that makes it safe to hand the operator real work, because the irreversible moments are exactly the ones where a human glance is worth the most. In build mode you will see them on the steps that matter; in auto mode you will only see them for the genuinely destructive ones. Either way, nothing dangerous happens without your sign-off.
Trails
When a turn finishes it becomes a trail, a single card carrying a one-line summary the operator wrote itself. Re-open a trail to see exactly what it touched and why, down to the branches it ran and the files it changed. Trails are how a long project stays legible: instead of scrolling through endless history, you read a stack of summaries and open only the turns you care about.
You can fork from any point in a trail to try a different approach without losing the original. That makes trails a quiet form of version control over your intent, not just your files. Want to see how the same goal plays out with a different plan? Fork the trail, change the brief, and let the operator run it again alongside the first.
From here, the natural next read is Surfaces, which covers the places the operator does this work, from Chat to the Computer VM. If you have not run a turn yet, start with Getting Started, and see Agent Workspace for how a single thread of work holds together over time.