Bonnie: one turn, two lanes
Part II — The Node and the Join · Chapter 5 of 9
Bonnie is the macOS assistant that completes the stack — the program that lives where the person lives. She listens and speaks, reads the workspace, and operates real applications. And the moment a system both speaks with retrieval-grounded knowledge and acts on a real computer, a design question appears that I consider the most important one in this book: should the thing that speaks and the thing that acts be the same mind?
Bonnie's answer is no. Every turn splits in two.
The frozen turn
Before the split, the freeze. At turn entry, Bonnie freezes the world the turn will run in: the active ability-registry snapshot, the currently valid interaction and perception signals, the ambient route and focus evidence, the memory plan, adapter readiness, and the conversation seed both lanes share. Whatever changes mid-turn — a package edited, an app quit — the in-flight turn keeps its world; the change lands next turn.
One sentence from the prompt-assembly documentation deserves italics now and a callback later:
Published signals are revalidated when the next turn freezes and disappear when their schema or Value version is gone or their publishing adapter is unavailable.
Capability, in this system, is not a static list. It's re-derived from the live environment at every turn boundary — present when its provider is present, gone when it's gone. Remember that shape; chapter 8 gives it a name.
Two lanes
Then the utterance forks:
Lane A is Seer — the reasoning lane from chapter 1. It owns every spoken word. It retrieves memory server-side, grounds the reply, streams prose (and attribution spans) to the conversation page. It does not receive an executable package graph and does not own macOS dispatch. It talks; it cannot touch.
Lane B is the orchestrator — silent, local. It sees the same utterance and the same frozen snapshot, proposes Skills from the turn's validated roster, executes them through adapters, and emits receipts. It acts; it does not speak. (Its prose exists only as an offline fallback — kept, never spoken, when Seer is healthy.)
The lanes run concurrently and join when both settle. The governing order, stated as doctrine in the brain's own source: FETCH FIRST, THEN SPEAK — grounding precedes voice; the voice never narrates an action that hasn't been verified.
In flowchart form, from the same documentation:
And the fallback is not an afterthought: without a Seer provider, Bonnie runs a single-engine loop entirely locally. The documentation is emphatic about the framing — the local lane "is not a degraded path, it is the path when the network is not there." An ambient assistant that stops working when a server does was never ambient.
The guardrail
Why two lanes, really? Not performance. The honest reason is a security posture, and the documentation states it as a safety callout:
Retrieved context never enters the orchestrator's prompt. Lane B — the lane that can actually touch your Mac — never sees what Lane A retrieved. Not your past conversations, not another person's shared context, not the RAG payload. It sees the utterance, the frozen snapshot, and the ambient evidence.
The reasoning is direct: retrieved text is content you did not write this turn — the classic carrier for content-shaped instructions — and the lane that proposes effects is exactly where such instructions would be most dangerous. So the lane with hands is structurally blind to the lane with memory. A pinned test asserts the property by name, so it cannot regress quietly.
I want to be precise about what this buys, because "prompt injection defense" undersells it. It's an authority architecture. The voice has knowledge-authority: it may know everything and can affect nothing. The hands have effect-authority: they can change the world and know only what the user said and the machine shows. Any future feature that blends someone else's context into retrieval — the direction Totem points — inherits the guarantee by construction: borrowed context reaches the speaking lane and stops there.
What a turn leaves behind
A turn ends by writing down what actually happened. Receipts — privacy-safe records of each Skill invocation, its capability effect, its outcome — join the turn history; raw selected text, generated prose, source code, and secrets are excluded from traces by rule. A retrieval-trace ledger records what retrieval was asked and what came back — ids, scores, and counts only, with redaction enforced at compile time — and it is purely observational: nothing may read it on a decision path. The ledger exists because retrieval is the core of the paradigm, and "why didn't she remember that?" deserved a runtime answer.
Mutations worth keeping are deposited to Totem as explicit projections — the only door through which durable memory grows. And when a turn that plainly wanted something done has run its rounds and executed nothing, one last mechanism — the affordance probe, "the last rung before the honest failure" — checks what the screen itself is offering before Bonnie admits she couldn't. That mechanism belongs to the next chapter.
The two-lane turn is the join point of the whole first half of this book: Seer's reasoning (chapter 1) and Totem's memory (chapter 4) on one side of a wall; the machine's hands on the other; the person on top, whose words start every turn and whose physical input ends any run instantly.
The lane that touches the Mac never reads what memory returned.