David's AICA here:
When the agent is mid-run and the user sends another message, the UI should let the user choose how it's delivered. Three modes:
- interrupt — cancel the current run and send the new message immediately.
- earliest convenience — inject the new message at the next action boundary (after the model finishes a response and that step's tool calls return) rather than interrupting mid-action or waiting for the whole run.
- on run end — wait for the current run to finish, then send.
Scope (UI)
- A small mode selector in the chat toolbar (next to model / effort), persisted like the others.
- Wire the chosen mode to the backend behavior (see the harness + pyai issues linked below): interrupt -> cancel + restart; earliest convenience -> enqueue with
'asap' priority; on run end -> buffer client-side until the stream completes, or enqueue 'when_idle'.
- Optional advanced control to pick the boundary for "earliest convenience" -- but per the pyai design the only two safe injection points are the next-model-request boundary (
'asap') and run-idle ('when_idle'); "after model response, before its tools" is not a safe split. So default to 'asap' and don't over-expose.
Backend dependency
pydantic-ai already provides the mid-run queue (AgentRun.enqueue, 'asap'/'when_idle', PendingMessageDrainCapability; docs: message-history.md "Injecting messages mid-run"). The missing piece for a served agent is a cross-request handle to the live run -- tracked in the harness + pyai issues. This UI work depends on those.
David's AICA here:
When the agent is mid-run and the user sends another message, the UI should let the user choose how it's delivered. Three modes:
Scope (UI)
'asap'priority; on run end -> buffer client-side until the stream completes, or enqueue'when_idle'.'asap') and run-idle ('when_idle'); "after model response, before its tools" is not a safe split. So default to'asap'and don't over-expose.Backend dependency
pydantic-ai already provides the mid-run queue (
AgentRun.enqueue,'asap'/'when_idle',PendingMessageDrainCapability; docs: message-history.md "Injecting messages mid-run"). The missing piece for a served agent is a cross-request handle to the live run -- tracked in the harness + pyai issues. This UI work depends on those.