# The four autonomy modes

`off` disables the channel entirely. `draft_only` writes a reply and stops, without asking anyone. `ask_before_send` writes a reply and puts it in front of a person, who must say yes before it goes. `autonomous` sends within the gates. The pair to keep straight is the middle two: both hold the message, only `ask_before_send` requests a decision.

- **Status:** Available
- **Audience:** both
- **Channels:** email, whatsapp, sms, phone
- **In the app:** #/autonomy
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/autonomy/modes/

## The difference that costs people a week

> **Careful** A workspace set to `draft_only` has an empty approval queue and a growing pile of unsent replies. That is the mode working correctly. If you are waiting for approvals to appear and none do, check the mode before you check anything else.

|  | `draft_only` | `ask_before_send` |
|---|---|---|
| Connect writes the reply | Yes | Yes |
| It appears in Waiting For You | No | Yes |
| Anyone is notified | No | Yes — it is a queued decision |
| It can be sent by one click | No — send it from the conversation | Yes — approve |
| Saying nothing means | It stays unsent, permanently and by design | It stays unsent until someone decides |
| What it is for | Watching what Connect would say, without asking anyone to keep saying no | Keeping a person in the loop on every outbound |

The intent behind `draft_only` is the part that gets lost. It is not a stricter `ask_before_send`; it is a **silent** one. A workspace evaluating Connect on a live mailbox uses it to read a fortnight of drafts at leisure and judge the quality, without an approval queue nagging anybody and without the risk that a tired approval sends something nobody read. Because it never asks, nothing accumulates as a task. Because it never asks, nothing goes out either.

## Each mode in full

**`off`** — The channel is disabled. Connect does not draft on it, does not queue anything for it and does not place calls on it. Inbound messages are still received and still appear in Conversations — turning a channel off is a decision about output, not about blindness. Use it when a mailbox is being migrated, or when a number is registered but not yet meant to be answered by Connect.
**`draft_only`** — Connect does the whole job up to the send: it reads, grounds the answer in Knowledge and Memory, writes the reply, and stops. Nothing enters the approval queue. The draft sits with the conversation, where a person can read it, edit it and send it by hand if they choose.
**`ask_before_send`** — Every outbound on that channel becomes a held action with a decision attached. It appears in Waiting For You and in Needs You, alongside the message it answers, and it goes out unchanged the moment somebody approves it — through the same send boundary a person's own send uses.
**`autonomous`** — Connect acts without asking, within the gates. The gates are not optional and not part of the mode: a suppressed or do-not-contact recipient, a spent daily allowance, a channel with no provider that can carry the message, and the workspace budget all still refuse. An `autonomous` channel therefore still produces refusals, and they are recorded.

## Choosing one

1. Start a new channel at `ask_before_send`.
   - Result: You see every reply before a customer does, and the queue tells you how often Connect is right without you having to sample.
2. If the queue is becoming a chore and the approvals are almost all straight yeses, move the channel to `autonomous` and keep `ask_before_send` on the contacts that matter most.
   - Result: The narrowest scope wins, so the exceptions survive the channel-wide change. See [Exceptions to a rule](/docs/autonomy/exceptions/).
3. If you want to read Connect's judgement without committing to a queue, use `draft_only` for a fixed period and set a reminder to review.
   - Result: Nothing is sent, nothing is asked, and the drafts are there to read against the messages that prompted them.
4. If a channel must go quiet — an out-of-hours number, a mailbox mid-migration — set `off` rather than emptying the credentials.
   - Result: Inbound keeps arriving and stays readable; only the output stops, and the change is one field to undo.

> **Note** Changing a mode takes effect on the next piece of work, not retroactively. Actions already held stay held under the rule holding them; moving a channel to `autonomous` does not release a queue of drafts held under `ask_before_send`, and moving it to `off` does not withdraw an approval already given.

## What each mode does not change

None of the four modes changes how Connect *reasons*. Triage, grounding, research and drafting run identically under all of them; the mode decides only what happens to the finished action. That is why a `draft_only` workspace is a fair test of quality — you are reading the same output an `autonomous` workspace would have sent.

None of them changes what Connect is allowed to know, either. Memory resolves through the same four tiers whatever the mode is, and a block recorded against a contact holds across every channel regardless. A mode is a rule about sending, and it is only that.

## Questions

### Which mode is the default for a new workspace?

Nothing goes out until somebody chooses. Treat `ask_before_send` as the position to start from and move outward once the queue has taught you what Connect gets right on your own mail — that is the sequence giving you evidence before it gives you volume.

### Does `autonomous` mean Connect can do anything on that channel?

No. It means Connect does not stop to ask. The gates no mode can switch off still apply, and some actions are outside the Connect Assistant's rights entirely — it cannot quote pricing and it cannot clear a do-not-contact entry, whatever the channel mode says.

### I set `draft_only` and Waiting For You is empty. Is it broken?

That is `draft_only` behaving as specified: it prepares and never asks. The drafts are on the conversations, not in the queue. If you want them queued for a decision, the mode you want is `ask_before_send`.

### Can one channel be `off` while the others run?

Yes — the mode is per channel, and a workspace running email `autonomous`, voice `ask_before_send` and SMS `off` is an ordinary configuration.

## Related

- [What Connect may do](https://connectbyjbrh.com/docs/autonomy/)
- [Autonomy scopes](https://connectbyjbrh.com/docs/autonomy/scopes/)
- [Setting autonomy per channel](https://connectbyjbrh.com/docs/autonomy/per-channel/)
- [The gates that always apply](https://connectbyjbrh.com/docs/autonomy/explicit-gates/)
- [Approvals](https://connectbyjbrh.com/docs/autonomy/approvals/)
- [The approval is not in the queue](https://connectbyjbrh.com/docs/troubleshooting/approval-not-appearing/)

## What this page is based on

- Connect source pack §5 — modes, channels and scopes (`docs-source/sources/GENERAL.md`)
- Connect capability registry (`docs-source/facts.py`) — `autonomy_modes`, `held_draft_approval`
- `backend/app/autonomy.py` — the four modes
- `backend/app/outbound.py` — the send boundary shared by the engine and by people