---
id: "conversa.enviar-mensagens"
titulo: "Sending messages and the send queue"
resumo: "Write and send during a turn in progress without losing the message, and understand why 'queued' means neither 'delivered' nor 'answered'."
idioma: "en"
tipo: "guia"
categoria: "telas"
aplicavelDesde: "0.0.16"
capabilities: ["chat.queue.durable"]
estadoEditorial: "aprovado"
nivelEvidencia: "artefato-distribuido"
refFonte: "27574c339b58316408f6be2d62169d59041d07bf"
revisaoFonte: "2026-09-24"
revisor: "mantenedor (v1, 2026-10-03)"
rota: "/docs/en/conversa/enviar-mensagens/"
fonte: "pt-br/conversa/enviar-mensagens.md"
caminhoPublico: "docs/publica/en/conversa/enviar-mensagens.md"
hashFonte: "sha256:aed5fbd94de356e9888352a0c8e885a531fa5ad9ca6b5b943f3d1035cae3017b"
hashDestaPagina: "sha256:f1e408e33e380a98a6aa77b7d3cd4e32851a3499e4c12d5741672a05d666987a"
traducaoAssistidaPorIA: true
traducaoDesatualizada: false
corpoRetido: false
---
<!-- traducao-assistida-por-ia: idioma=EN fonte=pt-br/conversa/enviar-mensagens.md fonteHash=sha256:aed5fbd94de356e9888352a0c8e885a531fa5ad9ca6b5b943f3d1035cae3017b estado=atual -->

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.
