# Autonomy on one mailbox

Autonomy is a field on the mailbox row as well as a channel-wide setting, and a mailbox is the *endpoint* scope. Scopes resolve narrowest-first — contact, then endpoint, then channel, then workspace — so a rule set on one address overrides the channel's for that address only. It is the tool for making one inbox stricter without slowing the others down.

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

## Four modes, four scopes

**`off`** — The channel is disabled here. Nothing is drafted and nothing is sent.
**`draft_only`** — Prepare a reply, never send it, and do not even ask. Deliberately different from asking: a workspace can watch what Connect *would* say without anyone having to keep saying no.
**`ask_before_send`** — Every outbound message needs a human yes. Replies queue in [Needs You](/docs/autonomy/).
**`autonomous`** — Act within the gates — which still means the allowance, suppression and do-not-contact are all checked.

The four scopes are `contact`, `endpoint`, `channel` and `workspace`, and the narrowest applicable one wins. *Endpoint* means one mailbox or one phone number, which is why this page exists at all: the mailbox is a first-class place to put a rule, not a shortcut for editing the channel.

## How a decision resolves

| Scope | Set against | Typical use |
|---|---|---|
| `contact` | One person | An account where every word matters, or one that must never be written to |
| `endpoint` | One mailbox | A finance or legal address that always asks, while sales runs on its own |
| `channel` | All email | The workspace's normal posture for mail |
| `workspace` | Everything | The floor, and what a new mailbox inherits until you set it |

A mailbox with no rule of its own is not a mailbox with no rule — it falls through to the channel and then the workspace. That is worth stating plainly because of what it means when you add an address: connecting a mailbox never enables anything that was not already enabled for the channel, so a new connection cannot surprise you by sending on its own.

The same hierarchy governs memory. `connect_memory.tiers()` resolves workspace, channel, endpoint and contact in the same order, and returns an empty tier rather than dropping it — so "nothing is set on this mailbox" is a visible answer rather than an absence you have to infer.

## Setting one

1. Decide which address needs to differ, and from what. A rule that matches the channel's is noise.
   - Result: You now know whether you want the mailbox stricter than the channel or looser, which is the only thing that makes the override worth having.
2. Set the mode on the mailbox row at `#/mailboxes`, or from [What Connect may do](/docs/autonomy/), which shows the scopes together.
   - Result: The rule takes effect on the next decision. It is not retroactive — drafts already held stay held, and messages already sent stay sent.
3. Watch the [Decision Log](/docs/autonomy/) for a day.
   - Result: The audit trail records what was decided, by what, under which rule — including refusals, because a refusal is a decision. That is how you confirm the narrower rule is the one being applied rather than the channel's.

> **Careful** `draft_only` and `ask_before_send` look similar from the outside and are not the same thing. `ask_before_send` puts a reply in front of a person; `draft_only` writes it and stops, on purpose, and queues nothing for approval. A mailbox left at `draft_only` will look, to someone working the approval queue, exactly like a mailbox nobody is writing replies for.

## When a per-mailbox rule is the wrong tool

If the concern is one person rather than one address, use the contact scope: it is narrower and it follows them across mailboxes. If the concern is one sender you never want written to at all, that is not autonomy — it is a block, which lives as a `connect_memory` row tagged `block:<channel>` in `tags`, holds across channels, and survives into future conversations. [Blocking a sender](/docs/email/blocking/) covers it.

And if the concern is volume rather than permission, autonomy will not help. The daily allowance is metering, checked separately; a mailbox set to `autonomous` still stops when the allowance is spent, and the work is held rather than dropped. [The daily email allowance](/docs/email/daily-allowance/) is the page for that distinction.

## Questions

### Can one mailbox be autonomous while another asks first?

Yes — that is the main reason the endpoint scope exists. Each mailbox carries its own mode, and neither affects the other or the channel's default.

### Does a contact-level rule beat a mailbox-level one?

Yes. Contact is narrower than endpoint, and the narrowest applicable scope wins. A person you have set to always-ask stays always-ask even in a mailbox running autonomously.

### I set a mailbox to autonomous and replies are still waiting.

Something else is holding them. The usual causes are the daily allowance being spent, the recipient being suppressed, or the mailbox actually sitting at `draft_only` — [Held drafts](/docs/email/held-drafts/) lists the holds in the order they are checked.

## Related

- [What Connect may do](https://connectbyjbrh.com/docs/autonomy/)
- [Held drafts](https://connectbyjbrh.com/docs/email/held-drafts/)
- [Mailboxes](https://connectbyjbrh.com/docs/email/mailboxes/)
- [Blocking a sender](https://connectbyjbrh.com/docs/email/blocking/)
- [Memory in Connect](https://connectbyjbrh.com/docs/memory/)

## What this page is based on

- Connect source pack — autonomy: modes and scopes, endpoint is one mailbox or one phone number (`docs-source/sources/GENERAL.md` §5)
- Connect source pack — memory tiers and `directives()` reading only tags (`docs-source/sources/GENERAL.md` §6)
- Connect source pack — channels, §1: per-mailbox autonomy, the allowance holds rather than drops
- Connect capability registry (`docs-source/facts.py`) — `autonomy_modes`, `approvals`