How prompts queue and run

MobSession's one-turn-at-a-time model: prompts queue in submission order, there is exactly one source of truth, and how to interrupt the current turn.

MobSession runs one shared agent that many people drive at once, and it works one turn at a time. When several people submit prompts, those prompts queue and run in the order they arrived. At any moment the agent is either idle or working a single turn, never juggling two.

One turn at a time

The agent handles one prompt per turn: read, do the work, finish, then start the next. Nothing runs in parallel against the same session.

This matters because a coding or research session builds on itself. Each turn can depend on files, decisions, and context the previous turn produced. Running in sequence means every turn sees the settled result of everything before it, instead of racing a half-finished change.

The submission-order queue

When more than one person submits, prompts line up first in, first out. No prompt jumps ahead, and none gets dropped because two people submitted at once.

Each prompt is claimed atomically before it runs: the queue hands it to the agent in one indivisible step. Two workers can never grab the same prompt, and a prompt never runs twice.

Everyone watching sees the agent work through the queue live. As each turn finishes, it shows how long it took and what it cost in dollars.

Submitting from the terminal

The orchestrator submits prompts from their terminal into the same queue. Terminal prompts follow the same submission-order, claim-once rules as everyone else's. There's no fast lane: a terminal prompt waits its turn.

Approving from the terminal or the web

By default, prompts from the room wait for the orchestrator's approval before they run. The orchestrator approves or rejects them from the terminal, or, as the session owner, right from the web with the host controls. Turning on trust lets the room's prompts run automatically; locking posting reserves the agent for the orchestrator during a delicate step.

Interrupting the current turn

When the agent is heading the wrong way or new information arrives, the orchestrator interrupts the current turn by pressing ESC. Since only one turn is ever active, an interrupt is unambiguous: it always hits the turn the agent is working on right now. Once that turn stops, the agent moves to the next prompt in the queue.

Why this keeps a multi-person session coherent

Without it, prompts could collide: two edits to the same file, a turn building on state another turn just changed, or the same instruction running twice. The queue removes those collisions by design.

One source of truth. Exactly one turn is active, so there's never a question of which state is current.
Predictable order. Prompts run in submission order.
Run-once guarantee. Atomic claiming means each prompt runs exactly once.
Shared visibility. Everyone sees the same live progress, including each turn's duration and cost.
Clear control. The orchestrator adds prompts, approves or rejects what's queued (from the terminal or the web), and interrupts the active turn with ESC.

The result is a session many people can drive together that still behaves like a single, focused collaborator.