How a Prompt Becomes a Turn
For Grok Build, the important runtime question is not simply how a model answers a prompt. It is how one request becomes a coordinated turn with a clear owner, an ordered place in the conversation, visible intermediate events, and a defined response to cancellation or failure. Understanding that path lets a reader tell the difference between a client display problem, a session-queue decision, a tool failure, and a model error.
The central unit is the session. A client may be a full-screen TUI, a headless command, or an ACP integration, but the request is handled by an agent process and routed into a session with its own conversation and tool context. The session is where a prompt becomes work that can be queued, started, interrupted, observed, and carried into the next turn.
The session is the unit of work
A useful way to picture Grok Build is as two nested responsibilities. The outer agent owns the connection to the client and the collection of resident sessions. The inner session actor owns one conversation's active state. The outer layer understands requests such as initialization, session creation, loading, prompting, and cancellation. The inner layer understands the current model, chat history, tool context, pending inputs, running task, notifications, and the resources associated with the workspace.
That division prevents the user interface from becoming the real source of truth. A TUI can display a session, but it does not need to own the model conversation. A headless invocation can wait for a result, but it does not need to implement the turn lifecycle. An ACP client can reconnect and load a session without reconstructing every tool call itself. The agent and session boundaries keep those clients thin enough to have different presentation styles while still using the same kind of stateful runtime.
The session actor communicates through channels rather than through a long chain of direct calls. Commands travel from the agent toward the session: a prompt, a cancellation, a shutdown request, a model change, or a request to inspect current state. Notifications travel back toward the client through a gateway. This arrangement gives the session a single place to serialize changes that would otherwise race. A prompt can be admitted while another operation is finishing, but its position in the session's delivery path is still decided by the session rather than by whichever UI callback happens to run first.
The actor model also makes ownership visible. The session owns its chat state, but it does not own every resource in the application. The tool bridge supplies the tool set and its shared execution resources. Workspace operations mediate access to files, terminals, version-control state, and turn hooks. Optional MCP servers, skills, memory, and background tasks are attached to the session when configuration and trust allow them. The session coordinates these pieces; it does not erase their boundaries.
This is more than an implementation preference. If all state lived in the TUI, an editor integration would need to imitate the TUI's internal logic. If every tool reached directly into the host, the session would have no consistent place to apply ordering, cancellation, or notification rules. By making the session the unit of work and the tool/workspace layers separate participants, Grok Build can expose one agent through several clients without pretending that presentation and execution are the same thing.
The boundary is not absolute. A session may use optional remote settings, MCP connections, or different workspace modes, and the effective model and tool set can change with configuration. The stable claim is narrower: the local runtime has an agent-level coordinator and a per-session actor, and that actor is the control point through which a conversation becomes a turn.
How a prompt enters the turn
When a prompt arrives, Grok Build first resolves the session handle. An unknown session is an input error rather than an invitation to create arbitrary state. Once the handle is found, the agent checks the session's current conditions and obtains a dispatch lock for that session. The lock matters because prompt submission, cancellation, rewind, and other turn-sensitive operations must not all decide what is running at the same time.
The prompt then has two broad paths. A caller that explicitly needs immediate delivery can send a prompt command directly. Otherwise, the request is wrapped in a delivery envelope and placed into the session's normal queue. The distinction is not cosmetic. A queued prompt participates in ordering and can wait behind existing work; an immediate prompt is a request to alter that normal waiting relationship. In either case, the session receives structured prompt blocks and metadata, not just an opaque string.
The session's run loop is the next gate. It listens for commands, completion messages, replay events, chat-state notifications, model changes, filesystem watches, and startup work. It can be idle, preparing a prefix or MCP tool set, waiting for a model response, running a tool, or finalizing a turn. These activities share one actor loop, so the session can decide how a new input interacts with a running task instead of allowing unrelated asynchronous callbacks to mutate the same state independently.
That shared loop is especially important when prompts arrive faster than turns finish. A queued prompt is not just a second string waiting in memory; it is an input with an identity, delivery policy, response channel, and place in the session's ordering. The actor can keep an earlier turn in flight while holding later inputs, or it can admit an immediate request through a different path when the client explicitly asks for it. The model-facing result must still settle the right caller. If a queued request is removed, cancelled, or prevented from starting, its waiting client cannot be left with an unresolved promise. Queue management is therefore part of the session's correctness contract, not merely a user-interface optimization.
The same principle applies to startup work. A session may need to prepare its prompt prefix, initialize MCP tools, discover skills, or establish watchers before it can safely begin a turn. The run loop owns those tasks closely enough to stop them when the session ends. This prevents a detached startup future from keeping a dead session alive or from delivering a late update into a new client attachment. It also explains why a client can see a short delay before the first model request even when the user has already submitted a prompt: the runtime is establishing the context and tool boundary that the turn will rely on.
A simplified turn looks like this:
The model can produce ordinary response text, internal thought chunks, a tool call, or a plan-related update. The important point is that the session does not have to infer the meaning from a paragraph of prose. A tool call carries an identity and a lifecycle. Its later update can say that the call is complete or failed and can carry the result. The client can render those states differently, while the session can feed the prompt-ready result back into the model context.
The turn therefore has at least two audiences. The client needs an event stream that supports a live view: a response is being written, a tool is running, or a permission interaction is waiting. The next model step needs structured context: what tool was called, with which result, and whether the result indicates success or failure. The same event boundary serves both, but the projections are different. A human may see a concise status line and an expandable tool card; the model may receive a formatted result with reminders or recovery information.
This dual projection is why the session does not simply forward raw model text to the terminal. A tool call has a client-visible title, a kind and status, an identifier, optional input, and later updates. A thought stream can be displayed separately from an answer. A plan update can be rendered as a plan rather than mistaken for a completed change. A failed tool call can remain attached to the turn that requested it. These distinctions give a client enough structure to make a live interface useful, while giving the session enough structure to decide whether the model should continue, retry, wait for input, or stop.
The structured result also protects the next turn from a common failure of conversational systems: losing the difference between an action and a description of an action. If the model asks to run a command, the next context needs to say what actually ran and what it returned, not merely repeat that the model intended to run it. If the request was rejected or cancelled, that fact is also part of the interaction. The session can then continue from an honest state instead of allowing a later response to assume that an unperformed edit or command succeeded.
The session can also attach metadata around the turn: the prompt identifier, model, working directory, mode, and other request context. That metadata supports ordering and later diagnosis. It lets the runtime distinguish a fresh user prompt from a synthetic wake-up or a background completion, and it gives a client a stable way to associate an update with the right session and tool call. The purpose is not bureaucratic record-keeping. Without identity, an event from a long-running command could be mistaken for the result of the current prompt.
The metadata is also a boundary against stale work. A session may have a resident background task whose completion arrives after the user has cancelled the current turn. The runtime needs to know which session owns that task and which prompt, if any, should receive the notification. That is why task and session identity matter even when the visible message is only a short completion notice. Observability is not an after-the-fact log pasted onto the system; it is the information used to route state changes safely.
What happens when the turn changes state
A turn does not end only when the model emits a final paragraph. It may complete normally, reach a configured limit, fail in sampling, be rejected by a tool or policy, or be cancelled by the user. The session actor has to settle the current task and decide what happens to queued input, pending notifications, and associated work. That is why the run loop contains explicit completion and shutdown paths rather than treating every failure as a thrown exception that disappears at the client boundary.
Cancellation illustrates the difference between stopping a request and deleting its history. A cancel command reaches the session handle, where it can cancel the running task and, depending on the request, associated child work. The session can preserve the conversation, or take a specific rewind path when the client asks for a history disposition. The actor also has to flush or settle relevant notifications so that the client does not display a turn as idle while a stale tool update is still waiting to be delivered.
Failure has a similar two-sided meaning. A tool error is a result that the model may be able to correct; a session or sampling error may terminate the turn itself. The runtime keeps those categories distinct enough to report them, while still collecting the state needed for a later resume or diagnosis. A client therefore receives more than “the agent failed”: it can receive the tool lifecycle, the final stop reason, and the session's completed or cancelled state.
A cancellation is consequently a coordinated state transition, not just a signal sent to a process. The session may need to stop model sampling, cancel or detach a tool task, settle a response channel, flush buffered updates, and decide whether queued prompts can proceed. If a background operation is allowed to continue, its later completion must be routed as background work rather than mistaken for an answer to the cancelled turn. If it is torn down, the session must prevent a late callback from reviving it. The details vary by task type, but the ownership question stays the same: which actor is allowed to close this piece of work, and what evidence tells the client that closure happened?
The session's run loop also handles work that is not the main model turn. It can initialize MCP tools, watch project discovery for skills and workflows, react to a model switch, flush optional memory, drain replay buffers, and perform shutdown work. These activities are coupled to the session because they can change what the next turn sees. A newly discovered project rule or skill, for example, is not merely a background file-system fact; it may alter the model-facing context and available commands.
This is where observability becomes a correctness property. If the session only returned a final answer, a client could not know whether the model was waiting, a tool was still running, or a prompt had been queued. If it only displayed live events without persisting the relevant state, a resumed session could lose the relationship between the conversation and its tool history. Grok Build's design treats streamed updates, chat state, and persistence as connected projections of one turn, even though each has a different job.
The boundary also explains why the next layer deserves separate attention. The session can decide that a tool call should run and can route it through the bridge, but it is not the tool's implementation. The bridge exposes a finalized registry, shared resources, and model-facing definitions. Workspace operations then mediate the host effect. The next chapter follows that handoff: how Grok Build turns a typed model request into terminal execution, file editing, search, and other concrete work without collapsing every capability into a privileged shell escape.