Review and sending

Nothing an agent drafts reaches a customer without a person reading it. That is the tool's central rule, and everything here follows from it.

The gate is on who wrote it

drafted by	what happens
an agent, through MCP (`upload_response`, `reply_to_sms`)	`review_required`: waits for an operator or admin — anyone, the token's owner included; never the agent token itself
a junior operator	the same
an operator or admin	sends directly, or is held with Request review until someone approves it or the author sends it (which withdraws the request)

A reviewer may approve as drafted, edit then approve (every edit is a revision with a note, visible on the case), or send back with a required note. A sent-back draft returns to whoever wrote it — for an agent's draft, the token's owner is told.

How to behave with a draft

Draft, say so, stop. After upload_response, tell the person in chat: the case ref, the response id, one line on what it says. Do not ask "ready to send?", do not restate the draft, do not nag. The draft is on the case; the Needs review list is where reviewers look.
A draft is stale the day after it was written. Before drafting, list_responses: if a draft of yours is already waiting, edit it (edit_response, with expected_version and a note) rather than adding a second. If a draft was never sent and the situation has moved on, say so and discard it (discard_response); the customer has meanwhile chased, and the next draft answers their latest message, not their first.
Every revision is re-checked against Writing to customers. A draft revised five times gets checked five times.
Never edit a person's words. If a person wrote or edited the draft, report what you would change and why; do not change it. edit_response on someone else's draft is for reviewers who are people.
Read the reviewer's edits. When a person tightens your draft, the revision and its note are on the case (list_responses, get_response). Read why before the next draft, or you will write the weaker version again.
Send what is on the case, not what you remember. If your token is a person's and may send, get_response immediately before send_response and pass the version you just read. A draft is edited by people between your reads; a remembered copy once went out in place of the edited one.
One summary per batch. When you have worked several cases, report once: one line per case — the ref, what you did, what waits on whom. Not a message per case, and not a Slack post per case; the reviewers' list is where the drafts are.
Check the delivery. A sent response shows delivery_status: delivered, deferred, or bounced. A bounce means it did not arrive even though it was sent — the address is wrong, and the case needs a new message to a working one. Say so in chat.

Scheduling

send_response with scheduled_send_at (a reviewer's action) holds a message until then, up to 72 hours ahead. cancel_scheduled_response before it goes; restore_scheduled_response until its time passes. The message leaves from a job that runs every five minutes, so it goes out within five minutes after its time, never before; until then nothing has reached the mail provider, and get_response shows scheduled or sent.

Batch approval

Under the Needs review scope a reviewer can approve several drafts at once. Each is read in full and sent on its own version; one that changed since it was read is skipped and reported. approve_responses does the same over MCP for a person's token. It is a human reading, not a shortcut past one.

What sends without review