Correction nudges

The runner sometimes injects a short corrective instruction back into the conversation instead of failing the run outright when a sub-agent's routing intent doesn't make sense.

When nudges happen

• The entry-agent rule: If the graph's entry sub-agent ends its very first turn with a plain answer instead of routing anywhere, the runner nudges it to actually route (or ask one clarifying question) rather than accepting a fabricated direct answer. This only fires on that sub-agent's first-ever routing decision — a normal synthesis answer after a successful handoff is never nudged.
• Ambiguous routing: If a sub-agent's turn asks for more than one route at once (e.g., two transfers, or a transfer mixed with delegations), the runner nudges it to pick one, bounded by a small retry budget, then falls back to a deterministic choice.
• Oscillation (A→B→A): If a sub-agent immediately hands control back to whoever just handed off to it, the runner nudges against the immediate bounce-back — but allows it through after a couple of nudges, so a graph that genuinely needs back-and-forth still works.
• Repeat delegation: If a sub-agent tries to delegate to a target it already consulted earlier in the same conversation, the runner nudges it to avoid repeating the same ask.

All of these nudges are soft and bounded — they never hard-fail the run; once their retry budget is exhausted the runner falls back to a reasonable default and moves on.

What you see in traces

• A conversation turn containing a [SYSTEM] block you didn't write and the user didn't send — this is the runner's own corrective instruction, not user input.
• A route_error event immediately followed by the SAME sub-agent taking another turn — that's usually a nudge-and-retry, not a failure.

Authoring implications

Give every sub-agent in the handoff graph clear, non-overlapping instructions about who owns what. Most nudges only fire because the model's own routing intent was ambiguous or looping, not because of a runner defect.