Sending messages and the send queue

Writing in Conversation is simple: you type in the field below the conversation and send. What deserves an explanation is what happens while the agent is still working — because there the right answer is not “wait”, it is to queue without losing what you wrote.

Sending during a turn

When you send while a turn is in progress, the message is neither discarded nor delivered halfway: it enters a send queue and goes out later. On screen it appears with the queue state.

The confusion worth avoiding is treating that state as delivery. “Queued” means your intent was stored, not that the agent received it and not that it has already answered. Only the later delivery state says the message went out.

The durable queue is the source when it exists

There are two possible paths for the queue: a durable one in the main process, and one in the renderer. The recorded decision is direct — where the durable port exists, it is the source, and the renderer queue leaves the path for native providers.

The port exists when the provider exposes the queue’s five methods: prepare the input, admit the send, change the queue, list the queue and report deliveries. The providers exposing the full port are: Claude, Codex, Grok, OpenCode and Hermes. Verboo, Cursor and Pi do not expose it, and sending on them follows the previous route.

The queue is declared per provider rather than by a fixed list in the screen: enabling the queue on an adapter means touching that adapter’s block, not the shared component. A namespace without the methods means no port — and the screen does not pretend otherwise.

The rule that prevents the disappearing message

This part exists because a real defect was measured, and the reason is worth knowing:

Idleness is decided before the claim. A send with a turn in progress stays queued — the state the drain knows how to pick up. A delivery is not claimed before it is known whether it will go out.

The original defect had two causes: the route sent to the renderer queue, which has no drain when the provider is native; and dispatch claimed the delivery before knowing whether a turn was in progress, leaving it in a state that the end-of-turn settlement accepted and marked completed. The visible effect was the worst possible: the message disappeared without an error and the screen said it had been delivered.

Limits worth knowing now

• Do not claim the send arrived just because it was queued. Watch the delivery state.
• The queue is not the same thing on every provider. Where the port does not exist, the same guarantee does not exist, and this page does not promise that it does.