Chapter 41: Steering a Running Agent
Steerability is a concurrency and addressing contract, not merely another prompt message.
Public-source snapshot: implementation details are examples from public Kocoro
origin/mainat commit4ec6772, reviewed 2026-07-27. Treat the invariant as the lesson and re-check constants against current source.
41.1 The problem
Users change priorities while a long task is running. Treating every follow-up as a new turn creates races; silently appending it may send the final answer to the wrong inbound message. Delivery systems can also replay an already accepted message.
41.2 The design rule
Give the active run a mailbox. Drain follow-ups only at safe boundaries, attach each item to its inbound reply address, and make the model see the new instruction before selecting more tools. A delivery acknowledgement is emitted only after the terminal reply was successfully delivered, which is what lets the transport drop its replay entry — it is not a signal that the mailbox accepted the item. Use durable message identity for deduplication and a separate interrupt path for immediate cancellation.
41.3 Snapshot evidence
| Source snapshot | Observation |
|---|---|
4ec6772 | mid-run follow-ups are drained into the active context |
4ec6772 | reply addressing is tracked per inbound item |
4ec6772 | delivery_ack and at-least-once replay are distinct states |
The values above describe one dated implementation, not a universal contract.
41.4 Implementation checklist
- Test follow-up arrival before and after a checkpoint.
- Keep cancel, redirect, and ordinary context additions distinct.
- Verify which inbound message receives every terminal reply.
41.5 Takeaway
Steerability is a concurrency and addressing contract, not merely another prompt message.
Read these chapters as one system: context, tool schemas, persistence, steering, time discipline, loop detection, and concurrency affect one another.