Inbox, Steering, and Continuation

Conclusion: the Inbox Is a Replayable Scheduling Protocol, Not a Temporary Chat-Input Array

The important capability is not merely “send another message while work is running.” Pending input itself enters the Session Event Log, allowing stable MessageIds, insertion, editing, cancellation, claiming, recovery, and UI classification to share one fact. The cost is equally explicit: accepted means the Inbox admitted work, not that it ran, produced a reply, or was necessarily fsynced; running describes whole-driver activity rather than a completion handle for one message.

1. First Separate Six Mechanisms with Similar Names

2. Queue Class Is Not Message Role: Identity, Source, and Scheduling Placement Are Orthogonal

An Inbox item is still the shared immutable UserMessage: it has a stable id, role: user, exact content blocks, and a required source. Plugins may extend MessageSourceMap; freezeMessage structured-clones and deep-freezes, while creation assigns a fresh UUID. INBOX-MESSAGE-IDENTITY

A “steering message” is therefore not a third message structure. It is the historical fact that a user-source message was claimed from next-step; a non-user source with the same role is instead interpreted as context by the UI.

3. One Durable Splice Rebuilds Both Lists; Commit Precedes Live Mutation

agent/inbox/spliced {
  target: next-turn | next-step,
  start,
  removedCount?,
  inserted: full UserMessage[],
  outcome?: canceled
}

This is also why the Web projection needs no separate command queue: it reads the Agent's current lists and applies the event being emitted once to obtain authoritative post-state.

4. Claim Has a Strict Priority: Every next-step Item, Then at Most One next-turn Item

claim(target) for each proposed Step
  1. Remove and take every next-step item (FIFO)
  2. If target = next-turn, remove the head next-turn item
  3. Emit claimed(message, turn) in that order

First Step of a Turn: target = next-turn
Later Steps in that Turn: target = next-step

This creates an often-missed composition: a Turn's first request may include long-parked injected context, steering, and that Turn's ordinary prompt at once, ordered as the next-step batch followed by the next-turn head.

5. Follow-up Preserves the FIFO Turn Mapping, but Status Does Not Flicker Per Turn

followup(message) is send(message, next-turn, true). When idle, wake synchronously reserves the running phase and then starts the driver asynchronously. While running, enqueueing is enough: after the current Turn closes, the live driver checks hasPending, installs a fresh AbortController, and continues with another Turn. INBOX-SEND-MAP

6. Steer Means “Nearest Step Plus Wake,” Not an In-Stream Append to the In-Flight Request

steer(message) writes to next-step and requests a wake. If the Agent is normally running, wakeDriver() does not start another driver: the current one should claim it at its next Step boundary. If the Agent is idle, steer opens a Turn itself. The core API therefore does not require running; an idle steer becomes the first input of a new Turn while replay still classifies it as steering. INBOX-DRIVER-WAKE

The Web composer offers steer only while an ordinary session reports running, reducing the surprise that idle steer actually opens a Turn. Direct Host session.prompt(mode: steer) still exposes the underlying semantics.

7. Inject Means “Nearest Step Without Wake”; Its Turn Depends Entirely on Timing

8. Pre-step Consumes Before Admission: Reject Does Not Automatically Put the Original Message Back

turn/start
  → inbox.claim(target)                 // durable pure deletion
  → assemble system prompt
  → agent/pre-step waterfall
       ├─ enter(messages) → step/start → user/message* → model
       └─ reject          → turn/end(blocked), no Step

If assembly or a listener throws, the Turn closes with error. next-turn work not yet claimed and next-step work arriving later remain queued, but the driver stops. The design makes input claim the commit point rather than successful model dispatch.

9. Tool Continuation and turn-stopping Reuse next-step but Have Different Producers

After the model emits tool calls, results enter the log in model order. Each finalized result's additionalContexts is then spliced into next-step in order. Without concludesTurn, the loop opens another Step in the same Turn. A conclusion still cannot skip next-step input that already exists. INBOX-TOOL-CONTEXTINBOX-TOOL-CONTINUATION

10. running Belongs to the Whole Driver; Maintenance Still Appears Idle

11. Read Cancel Across Three Layers: Signal, Pending Input, and Already-Claimed Input

12. The Abort-to-Idle Wake Latch Repairs Cancellation Convergence but Leaves a Narrower Retirement Gap

Active Turn is aborted but not yet idle
  ├─ already queued + keepInbox → preserved but parked (no latch)
  ├─ new waking send afterward → force next-turn + wakeRequested=true
  ├─ default cancel            → clear Inbox + clear latch
  └─ disposed                  → never latch

Old driver finally: idle → if latched and pending remains → new driver

13. Turn Records Alone Cannot Answer “What Happened to This Work?”

A no-Step Turn may mean an empty claim, a listener rewrite to empty, pre-step rejection, cancellation, or error. Reading turn/end alone cannot distinguish “nothing ran” from “input was consumed before reaching the model.” foldConsumedWork therefore joins steps, pure-deletion claims, and canceled splices. INBOX-CONSUMED-WORK

14. “Logged,” “Pushed to Web,” and “Fsynced” Are Three Different Commit Points

Host prompt accepted
  → Inbox splice synchronously appended to live Session
  → API may return accepted
  → JSONL write-behind batch (fixed window by default)

First pre-step checkpoint
  → flush enqueue + turn/start + claim
Before model-adapter dispatch
  → flush step/start + user/message + request prefix

The JSONL backend batches live events behind a fixed window; flush and teardown drain immediately. Every batch append is fsynced, and failure rolls the file back to its prior byte length. A synchronous prompt accepted is therefore Session-level admission, not an independent fsync receipt. A product promising power-loss safety before acknowledgement would need to await an explicit checkpoint. INBOX-JSONL-DURABILITY

15. Resume Rebuilds Pending Work but Does Not Run Merely Because It Rebuilt; Fork Seeds Do Not Copy Ancestor To-Dos

The resume path prepares a Session from persistence and then rejoins the same prepare/setup/publish path as creation. A new ReactLoopAgent constructor restores the last Turn number and Inbox from the log. INBOX-AGENT-RESUME

Construction and publication do not call wake. An ordinary Host cold resume is normally followed immediately by a waking prompt; a continuable-child cold resume likewise calls followup next, so older pending work proceeds with the new wake under the two-list claim rule. Resuming an Agent alone does not promise to consume parked input.

16. The Ordinary Host API Returns Admission, Not a Turn or Reply

session.prompt accepts mode: queue | steer. After time-zone handling, durable attachment conversion, and message-source construction, it calls agent.followup or agent.steer and returns {accepted:true} once synchronous enqueueing succeeds. It does not await pre-step, model output, or idle. INBOX-HOST-PROMPT

The Host resolves or resumes a cold ordinary Session first. Direct mode: steer adds no running check, so it retains the core behavior where idle steer opens a Turn. That is a different layer from the UI's conservative submission policy.

17. Queue Edit, Remove, and Strict Steer Address MessageId; Claim Wins the Race

18. Web Uses Whole Snapshots for the Live Mirror and Durable Splices to Recover Historical Identity

Session splice (observer sees pre-state)
  → Host applies this splice to current lists
  → session/queue { complete items[] }
       next-turn              → queued
       next-step + user       → steering
       next-step + non-user   → context

The Queue mirror is a whole-snapshot last-wins value. Pending steering retires when a durable user/message with the same MessageId appears. Historical replay instead reads a non-canceled removal from next-step and then checks user source to reconstruct the same user/message as steering. INBOX-CLIENT-MIRRORINBOX-HISTORY-CLASSIFICATION

19. The UI Places Queued and Steering Input Separately, and Treats “Accelerated Send” as Policy, Not Truth

QueueDock shows only placement=queued and provides edit, remove, and per-row steer. The steer button is enabled only while running. Pending steering instead renders as a user-style bubble at the conversation tail and hands off after the durable message enters history. INBOX-QUEUE-DOCKINBOX-PENDING-STEERING-UI

20. A Continuable Child's Activation Is a Residency Epoch, Not a Request or Result

startContinuable establishes a durable child. Later followup hides the resident-versus-cold-resume distinction and routes every item through the child's single Inbox. The success boundary is acceptance of a message id by that Inbox; it does not await Turn start or return a child reply. INBOX-CONTINUATION-SEAM

One Activation may execute many FIFO Turns and may remain resident after its own Agent becomes idle because descendants still run. The manager owns only residency and ownership; the Agent loop and Inbox remain the sole owners of Turn ordering. INBOX-ACTIVATION-MODELINBOX-ACTIVATION-STATE

21. Parent-to-Child Delivery Is Always Follow-up; a Lock Linearizes Delivery Against Disposal

For a resident child, the manager submits under a child-id lock. If disposal has begun, delivery waits for release and then cold-resumes. For an absent child, it inspects persistence, authorizes against durable parent lineage before folding, reads only the post-seed continuable descriptor, and reconstructs an Activation. INBOX-CONTINUATION-DELIVERYINBOX-COLD-RESUME

22. Child-to-Parent Has Two Independent Messages: Explicit Report and Automatic Settlement Account

23. Child Web and Model Control Surfaces Are Intentionally Narrower Than Ordinary Sessions

The wire contract defines prompt receipt as an Inbox MessageId and interrupt receipt as signal acceptance rather than target quiescence. Host child prompt requires a live parent, while interrupt deliberately performs no parent, catalog, or persistence lookup. INBOX-SUBAGENT-WIREINBOX-SUBAGENT-HOST

The client makes one-shot children read-only. A running continuable child keeps Send and exposes Stop separately, so new input becomes a later Turn. With the parent offline, input is disabled but a live child can still be stopped. The model tool likewise states that send_message returns no reply and cannot redirect current work. INBOX-CHILD-CLIENTINBOX-CHILD-COMPOSERINBOX-CHILD-OFFLINE-UIINBOX-CONTROL-TOOLS

24. Two Reproducible Documentation Drifts Exist at the Pinned Baseline

25. Guarantee Matrix and Design Assessment