Drafting and approving a reply, end to end
Connect drafts a reply on every thread it is allowed to answer, then asks one question before sending: what does autonomy say at the narrowest scope that has a rule? autonomous sends through outbound.py; ask_before_send puts the finished reply in Needs You; draft_only writes it and stops. A send is reported as sent only once the provider acknowledges it.
The chain from message to sent reply#
- Trigger — a canonical thread the engine has picked, ranked by
threads.priorityrather than by arrival time. - User or external event — the customer's message is already a canonical record; see inbound email, end to end for how it got there.
- Authentication and workspace resolution — the engine runs inside one workspace; the mailbox, its signature and its autonomy are read only after that.
- Ingest — the thread, its history and the person behind the address are loaded together, so the reply answers a conversation rather than a message.
- Canonical record — the answer is written as a record before anything is sent, which is what makes holding it, editing it and auditing it possible.
- Reasoning — the reply is generated against the thread, grounded in the workspace's knowledge rather than improvised.
- Knowledge, memory and rules — memory resolves workspace, channel, endpoint and contact narrowest-first; a
block:emaildirective on the contact stops the draft being written at all. - Autonomy and approval — the mode at the narrowest applicable scope decides: send, ask, or stop. A refusal is a decision and is recorded as one.
- Action through a provider —
outbound.pyis the single send boundary, used identically by the engine and by a person pressing Send. - Result — sent, failed, or *uncertain*. The third state is shown as uncertain rather than guessed either way.
- Relationship, timeline and memory — the reply joins the person's timeline; a commitment made in it becomes a follow-up rather than a promise nobody tracks.
- Audit, usage and Needs You — the send is metered, the Decision Log records what released it under which rule, and the Needs You entry drains itself.
The gate in the middle#
Autonomy has four modes and four scopes. The scopes are contact, endpoint (one mailbox), channel and workspace, and the narrowest one that has a rule wins — which is how a workspace can run autonomously everywhere and still hold every word going to one account.
| Mode | What you see | What changes | What can fail |
|---|---|---|---|
autonomous | A sent message on the thread | An outbound message, metered, with provider evidence | The provider rejects it, or the allowance is already spent |
ask_before_send | An item in Needs You with the original above the draft | A held draft row, ranked into the queue | Nobody works the queue; the customer is waiting on no reply at all |
draft_only | A finished reply on the thread and nothing in Needs You | A row that is never queued for approval | Being mistaken for ask_before_send — the one difference the screen does not make obvious |
off | Nothing | Nothing is written | A channel switched off for a test and never switched back on |
What counts as verified success#
A reply is reported as sent when the provider has acknowledged it, and at no earlier point. Handing a message to an SMTP server is not evidence; neither is a request that has not returned. Where the acknowledgement never arrives — a connection dropped after the message was accepted, a timeout on a call that may well have succeeded — the state is uncertain, and it is shown that way.
Uncertain is deliberately not resolved by guessing. Re-sending on a maybe is how a customer receives the same reply twice, and treating an uncertain send as a failure is how one thread gets answered twice by two different people. The send result is uncertain explains how one resolves.
Open the thread on Conversations after approving.
Result The reply is on the thread with its state, not merely in a queue somewhere.
Read the Decision Log entry for that action.
Result It names what was decided, under which rule, by which person or by the engine — including refusals.
If Gmail is the provider, check the label and the read state on the original.
Result Write-back is best-effort and is allowed to fail without affecting the reply, so a missing label is not a failed send.
What can go wrong on this path#
- The draft never appears
- Autonomy is
offfor this scope, or ablock:emaildirective is set against the contact. Both are deliberate, and both are visible on the contact's memory. - The draft appears and never moves
- One of four holds. The draft is still waiting takes them in the order they are evaluated.
- Approval succeeds and nothing is sent
- The daily allowance was spent between the draft and the approval. The approval stands and the send waits for the allowance to reset.
- The reply is stale by the time it goes
- The thread moved on while it waited. Regenerating gives the model the newer messages; editing the old text does not.
- The reply went from the wrong address
- The mailbox role decided the sender. The reply went from the wrong address covers the fix.
Questions#
Does the customer see anything while a draft is held?
No. A held reply has been handed to no provider, so there is no message in flight and nothing in the sent folder. A held reply is no reply rather than a slow one, which is why the queue is ranked instead of chronological.
Can the Assistant approve a draft for me?
It has approve_draft, send_draft_now and reject_draft among its tools, and its rights are deliberately narrower than a person's elsewhere — it cannot set pricing and cannot clear a do-not-contact entry.
Is the engine's send different from mine?
No. outbound.py is one boundary shared by both, so metering, suppression checks and provider evidence apply the same way whether a person or the engine pressed the button.