# What Connect may do

Autonomy is one rule per channel saying how far Connect may go without a person: `off`, `draft_only`, `ask_before_send` or `autonomous`. The rule can be set at four scopes — contact, endpoint, channel, workspace — and the narrowest one that applies wins. Anything held for a decision arrives in Needs You, and every decision, including a refusal, is written to the decision log.

- **Status:** Available
- **Audience:** both
- **In the app:** #/autonomy, #/approvals, #/needs-you, #/autonomy-audit
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/autonomy/

## The shape of the control

Three things decide whether an outbound action happens: the **mode** (how far Connect may go), the **scope** it was set at (how widely that applies), and the gates that apply whatever the mode says. Read them in that order. Most confusion about why something did or did not go out is a mode question; most confusion about *why the mode you set is not the one in force* is a scope question.

| Mode | Connect prepares | Connect asks | Connect sends |
|---|---|---|---|
| `off` | No — the channel is disabled | No | No |
| `draft_only` | Yes | No, deliberately | No |
| `ask_before_send` | Yes | Yes, every outbound | Only after a yes |
| `autonomous` | Yes | Only when a gate says so | Yes, within the gates |

> **Note** `draft_only` and `ask_before_send` are the two most often mistaken for each other. Both leave a written reply unsent. Only one of them puts it in front of a person. [The four autonomy modes](/docs/autonomy/modes/) sets the difference out in full.

## Where each question is answered

| The question | The page |
|---|---|
| What does each mode actually do? | [The four autonomy modes](/docs/autonomy/modes/) |
| Why is my channel rule not the one in force? | [Autonomy scopes](/docs/autonomy/scopes/) |
| Can email and phone differ? | [Setting autonomy per channel](/docs/autonomy/per-channel/) |
| What can no mode switch off? | [The gates that always apply](/docs/autonomy/explicit-gates/) |
| How do I stop Connect ringing people unasked? | [Asking before placing a call](/docs/autonomy/ask-before-calling/) |
| How do I make one customer an exception? | [Exceptions to a rule](/docs/autonomy/exceptions/) |
| What is waiting for me, and why that order? | [Needs You](/docs/autonomy/needs-you/) |
| Who did what, under which rule? | [The decision log](/docs/autonomy/audit-trail/) |

## What autonomy is not

Autonomy decides **permission**, not **capacity** and not **behaviour**. Three neighbouring controls are frequently mistaken for it.

**The plan allowance** — How much a workspace may do in a day. An `autonomous` channel with a spent allowance sends nothing, and that is a limit, not a rule change. See [Autonomy and spend](/docs/autonomy/spend-context/).
**Memory and standing instructions** — *What* Connect says and remembers, at the same four tiers autonomy resolves through. A standing instruction can change the content of a reply; it cannot promote `ask_before_send` to `autonomous`.
**The runtime switch** — Whether the engine is working at all. Turning Connect off stops the work; it does not rewrite a single autonomy rule. See [Turning Connect on and off](/docs/autonomy/connect-on-off/).

## The four screens

The controls live on four routes, and they are the same four for the Owner and for a customer workspace — one implementation, reached through two doors.

- `#/autonomy` — **What Connect May Do**: the modes, per channel and per scope.
- `#/approvals` — **Waiting For You**: the held actions, each with the draft and the message it answers.
- `#/needs-you` — **Needs You**: every kind of item wanting a person, ranked.
- `#/autonomy-audit` — **Decision Log**: what was decided, by what, under which rule, and what happened.

A customer session reaches all four through the tenant facade rather than the Owner paths. If one of them answers 403 for a tenant and works for the Owner, that is a routing fault in the facade, not an autonomy setting — [Autonomy for the Owner and for a customer](/docs/autonomy/autonomy-owner-tenant/) explains the split.

## Everything in this section

19 pages, each with its own status and the date it was last checked against the running system.

| Page | What it covers |
|---|---|
| [Approvals](/docs/autonomy/approvals/) | Waiting For You: how a held action is presented, what a person may change, the two decisions available, and what each one records. |
| [Asking before placing a call](/docs/autonomy/ask-before-calling/) | Holding outbound calls for a human yes: what the setting covers, what the approver is shown, and what happens to a call-back that waits too long. |
| [Autonomy and spend](/docs/autonomy/spend-context/) | Permission and capacity are separate controls: how the plan allowance and the workspace budget limit what an autonomous channel actually does. |
| [Autonomy for the Owner and for a customer](/docs/autonomy/autonomy-owner-tenant/) | One implementation serves both audiences: a customer gets the same modes, scopes, queue and log, with the plan bounding volume rather than permission. |
| [Autonomy scopes](/docs/autonomy/scopes/) | Contact, endpoint, channel and workspace: the four levels an autonomy rule can be set at, and why the narrowest one always wins. |
| [Editing before approving](/docs/autonomy/editing-before-approval/) | Changing a prepared reply before releasing it: which parts a person may alter, what the edit records, and when to regenerate instead. |
| [Exceptions to a rule](/docs/autonomy/exceptions/) | Overriding a channel rule for one contact or one mailbox: when an exception is the right instrument, and the three tools often confused with it. |
| [How long the record is kept](/docs/autonomy/audit-retention/) | How long decision records last, what actually limits an investigation, and why no age-based deletion schedule is published for them. |
| [How Needs You is ordered](/docs/autonomy/needs-you-ranking/) | Why the list is not in arrival order: the signals that push an entry up, the ones that pull it down, and how your own triage feeds back into it. |
| [Needs You](/docs/autonomy/needs-you/) | One ranked place for everything wanting a person: held decisions, mailboxes needing attention and line health, each clearing as its cause resolves. |
| [Rejecting an action](/docs/autonomy/rejecting/) | Saying no to a held item: what happens to the prepared work, what is written down, and whether Connect tries the same thing again. |
| [Setting autonomy per channel](/docs/autonomy/per-channel/) | Email, WhatsApp, SMS and voice each carry their own autonomy mode. Why they usually should not match, and the configurations that work. |
| [Standing instructions](/docs/autonomy/standing-instructions/) | Durable directions a person gives Connect: where they apply, how to write one that can be acted on, and how they differ from memory and autonomy. |
| [The decision log](/docs/autonomy/audit-trail/) | What was decided, by what, under which rule, and what happened — including the refusals, because a refusal is a decision like any other. |
| [The four autonomy modes](/docs/autonomy/modes/) | Off, draft only, ask before sending and autonomous: what each does to an outbound action, and the difference readers most often miss. |
| [The gates that always apply](/docs/autonomy/explicit-gates/) | Suppression, blocks, allowances, evidence and workspace isolation: the refusals that stand even when a channel is set to autonomous. |
| [Turning Connect on and off](/docs/autonomy/connect-on-off/) | The runtime switch: what stops when you turn Connect off, what carries on regardless, and the four things it deliberately does not change. |
| [What appears in Needs You](/docs/autonomy/needs-you-kinds/) | Every sort of entry the attention list carries, what each one means, and the screen you go to in order to make it go away. |
| [Who may change what](/docs/autonomy/permissions/) | Who is allowed to change autonomy, decide a held item and read the record — and the rights the Connect Assistant is never given. |

## Questions

### If I set the workspace to `autonomous`, does everything send by itself?

No. A workspace-scope rule is the widest and therefore the weakest: any narrower rule set on a channel, an endpoint or a single contact overrides it. The gates apply as well — a suppressed recipient, a spent allowance or a channel with no provider that can carry the message all stop a send the mode permits.

### Is autonomy set once for the whole product?

No. It is per channel — email, WhatsApp, SMS and voice each carry their own mode — and each of those can be overridden for one mailbox, one phone number or one contact. Running email `autonomous` and voice `ask_before_send` is an ordinary configuration, not an exception.

### Where do I see what Connect decided not to do?

The decision log. A refusal is recorded there with the rule that caused it, in the same shape as an action, because a refusal is a decision. That is the screen answering 'why did nothing happen' without guesswork.

## Related

- [The four autonomy modes](https://connectbyjbrh.com/docs/autonomy/modes/)
- [Autonomy scopes](https://connectbyjbrh.com/docs/autonomy/scopes/)
- [Needs You](https://connectbyjbrh.com/docs/autonomy/needs-you/)
- [The decision log](https://connectbyjbrh.com/docs/autonomy/audit-trail/)
- [Memory in Connect](https://connectbyjbrh.com/docs/memory/)
- [Connect is preparing work but sending nothing](https://connectbyjbrh.com/docs/troubleshooting/nothing-is-sending/)

## What this page is based on

- Connect source pack §5 — autonomy, approvals and Needs You (`docs-source/sources/GENERAL.md`)
- Connect capability registry (`docs-source/facts.py`) — `autonomy_modes`, `approvals`, `needs_you`, `audit_trail`
- `backend/app/autonomy.py` — the modes, the channels and the scope order