How a Turn Works

1. You send a message.
2. The engine assembles this request: the system prompt, project instruction files, the list of available skills and sub-agents, the memory hits, the message history, the tool list, plus any reminders the current turn needs (final reply style, plan mode, memory recall, date changes, and so on).
3. The model returns text, along with zero or more tool calls.
4. Every tool call goes through a permission check first (see the next section). Once approved, it runs and its result is fed back to the model.
5. As long as the model keeps calling tools, the loop continues.
6. When the model stops calling tools, one more wrap-up check runs before the turn can count as finished — because "no more tool calls" is not the same as "done answering":
   • The output was cut off by the length limit: there is already visible body text, but the reply stops mid-sentence. The model is asked to continue, up to three times.
   • The whole budget went into thinking and no body text came back at all: asking it to "continue" makes no sense here, so it is first reminded to think less, up to twice. Once that ladder is exhausted, it stops and asks you whether to retry, instead of silently closing a turn that produced nothing.
   • Real work was already done, but the wrap-up came back empty: retry once first (a gateway hiccup or the model simply forgetting to close out can both be recovered this way). If that still fails, the turn is judged as failed rather than completed — silently marking an unfinished turn as complete looks exactly like the agent giving up on its own.
   • A truncated tool call argument is a different case: that call never ran, and the fix is a larger output budget so it can be sent again, not a continuation.

Body text, tool cards, complete proposals, progress checklists, compaction notices, and memory notices arrive as distinct engine events. Plan mode is independent of tool permissions and is captured at a request boundary. The complete proposal is separate from the execution checklist maintained by update_plan; structured answers return only to their originating conversation and call.

An active goal adds a continuation decision after the turn ends. The engine gives user input and other pending work priority and continues only at a safe idle boundary in execution mode. Each continuation has its own turn and accounting. Pausing, stopping, usage/budget limits, or clearing the goal prevent inappropriate continuation. Completing a goal requires actual verification and final accounting; an ordinary turn ending is not achievement. See Goals and side tasks.