# Turning Connect on or off at runtime

The switch stops Connect taking new work. Anything already handed to a provider finishes there — a sent message is not recalled — and nothing is deleted. What changes is that scheduled work stops firing, and the people writing in receive no reply at all rather than a slower one, because nothing announces that Connect is off.

- **Status:** Available
- **Audience:** both
- **In the app:** #/home, #/autonomy
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/workflows/runtime-toggle/

## The flow

1. Trigger — somebody decides Connect should stop working: an unexpected action, a change being prepared, a quiet period, or plain caution.
2. User or external event — the runtime control in the application layout is switched off. It is one control, available to both audiences.
3. Authentication and workspace resolution — the change belongs to one workspace, and it is not a global stop for anybody else.
4. Ingest — new mail still arrives at the mailbox; calls still reach the carrier. Switching Connect off does not cancel arrangements made with providers.
5. Canonical record — records already created stay exactly as they are. Nothing is removed by switching off, and nothing is created by switching on.
6. Reasoning — this is where the change actually bites. The engine stops picking work up, so nothing is triaged, drafted or decided.
7. Knowledge, memory and rules — retained, unread. They are inputs to work that is not happening.
8. Autonomy and approval — untouched. The autonomy rules are still whatever they were, and they apply again the moment work resumes.
9. Action through a provider — an action already handed over completes at the provider. There is no recall, and a message that has been sent stays sent.
10. Result — quiet. The absence of results is the intended outcome, and it is also what makes this easy to forget about.
11. Relationship, timeline and memory — no new entries, because nothing happened to record.
12. Audit, usage and Needs You — the change itself is recorded, and Needs You keeps showing what a person still has to decide.

| Work | While off | When switched back on | Risk |
|---|---|---|---|
| Already handed to a provider | Completes at the provider | Nothing to resume | None — but it cannot be undone either |
| Waiting for approval | Waits, unchanged | Still waiting, and may have gone stale | Approving an answer to a conversation that has moved on |
| Inbound arriving | Accumulates at the provider and in the workspace | Picked up in order | A backlog large enough to be worth watching |
| Scheduled follow-ups | Do not fire | Fire if still in time | A phone follow-up more than a day late is closed as missed rather than rung |

## The one that quietly expires

Most held work is patient. Phone follow-ups are not: a row more than twenty-four hours late is closed as missed and never rung, on the reasoning that a very late call-back is worse than none. Somebody who was told they would be rung yesterday does not want the call today; they want an explanation.

> **Careful** A weekend with Connect switched off is long enough for that rule to apply. If a stop lasts more than a day, the follow-ups screen is the first place to look afterwards — the missed rows are visible, and a person can decide what to do about each.

## What the people on the other end see

Nothing. There is no automatic notice, no away message, no change of tone. From a customer's point of view a switched-off Connect is indistinguishable from a business that has not replied — which is the accurate description of what is happening, and the reason to treat the switch as a decision with a cost rather than a pause button.

That is the same logic as a reply that is written and held: it is not a slow reply, it is no reply, and the clock the customer is counting keeps running. If a stop is planned and long, the honest thing is for a person to answer the conversations that matter by hand while it lasts.

## Choosing this switch or a narrower one

**The runtime switch** — Stops all of Connect's work in this workspace. The blunt instrument, and the right one when you do not yet know what is wrong.
**Autonomy set to `off` for a channel** — Disables one channel and leaves the rest working. The right one when the problem is a channel.
**Autonomy set to `draft_only`** — Connect keeps preparing and never sends, not even to ask. The right one when you want to watch what it would do.
**Autonomy set to `ask_before_send`** — Everything outbound waits for a person. The right one when you want the work but not the independence.

Reaching for the runtime switch when a narrower control would do is a common and expensive habit: it stops the useful work along with the worrying work. [The four autonomy modes](/docs/autonomy/modes/) covers the narrower controls, and [Stopping Connect, end to end](/docs/workflows/stopping-connect/) covers the urgent case where the blunt instrument is correct.

## Switching it back on

1. Look at the follow-ups screen before anything else.
   - Result: Anything closed as missed is visible, and a decision about each is better made now than discovered later.
2. Work the approval queue, checking whether the conversations have moved.
   - Result: A stale draft answers an older message. Regenerating gives the model what has arrived since; editing does not.
3. Switch on, and watch the first few pieces of work rather than walking away.
   - Result: If the reason for stopping has not been addressed, you find out in minutes rather than overnight.

## Questions

### Does switching off recall a message that has already gone?

No. Once a provider has accepted an action it belongs to the provider, and there is no mechanism here that reaches into somebody else's mailbox. The switch stops the next action, never the last one.

### Is anything lost while Connect is off?

Mail and messages accumulate rather than disappearing, and records stay as they are. The exception is a phone follow-up that becomes more than a day late, which is deliberately closed as missed rather than rung very late.

### Does switching off affect other workspaces?

No. It is a workspace's own control, like everything else here, and it says nothing about anybody else's.

## Related

- [Turning Connect on and off](https://connectbyjbrh.com/docs/autonomy/connect-on-off/)
- [Stopping Connect, end to end](https://connectbyjbrh.com/docs/workflows/stopping-connect/)
- [The four autonomy modes](https://connectbyjbrh.com/docs/autonomy/modes/)
- [Follow-ups in Connect](https://connectbyjbrh.com/docs/follow-ups/)
- [Connect appears to be doing nothing](https://connectbyjbrh.com/docs/troubleshooting/nothing-is-happening/)

## What this page is based on

- Connect source pack section 7 — a phone follow-up more than twenty-four hours late is closed as missed and never rung (`docs-source/sources/GENERAL.md`)
- Connect source pack section 5 — the autonomy modes and Needs You (`docs-source/sources/GENERAL.md`)
- Connect capability registry (`docs-source/facts.py`) — `runtime_on_off`, `followups`, `phone_followup_drain`