Stop Connect immediately
Use the runtime switch in the application shell. It stops new work instantly and changes no configuration, so autonomy modes, schedules and mailbox settings are exactly as you left them when you switch back on. Work already handed to a provider — a send in flight, a call in progress — is not recalled, because it is no longer Connect's to recall.
Do this first#
Use the runtime switch in the application shell. It is a control on the frame rather than inside any one screen, so it is reachable from wherever you happen to be when you need it.
Result New work stops being picked up. No mode changed, no schedule was deleted, and nothing needs to be reconstructed later.
Open Needs You and read what is queued.
Result Anything that was waiting on a person is still waiting. Stopping does not approve or reject anything on your behalf.
If a specific outbound action is the problem — one sequence, one person, one channel — deal with it now, while nothing new is being generated on top of it.
Result You are making the durable change under calm conditions rather than under a queue that keeps growing.
Switch back on when you are ready.
Result Work resumes from where it stopped, under the same rules as before, because none of them were touched.
What actually stops, and what does not#
| Thing | Stops? | Why |
|---|---|---|
| New drafts, new outbound, new calls placed | Yes, at once | These are new work, and new work is what the switch gates |
| A send the provider has already accepted | No | Once a provider acknowledges a message it is delivered by them, not by Connect |
| A call already connected | No | The audio path is live between a caller and the model; ending it is a hang-up, not a setting |
| Inbound mail, inbound calls, inbound webhooks | Still arrive | Stopping does not disconnect a mailbox or hand a number back to the carrier |
| Held drafts and approvals | Unchanged | They stay queued; approving one is a person's action, not the engine's |
| Autonomy modes, schedules, mailbox settings | Unchanged | The switch is runtime state, deliberately not configuration |
Choosing between the switch and a setting#
- Something is going out that should not be, right now
- The switch. It is the only control that needs no decision about scope and leaves nothing to restore.
- One channel is misbehaving and the others are fine
- Set that channel's autonomy to
draft_onlyoroffinstead. Turning everything off to fix email costs you the phone as well. - One person should stop receiving anything
- A block. It is one directive that holds across every channel and across future conversations, which stopping the whole engine for an afternoon does not.
- You are going away and want considered handling in the meantime
- Autonomy plus hours plus a staffed queue, not the switch. Stopping for a week means a week of mail nobody triaged.
How to tell it worked#
The switch's own state is the first signal, but it is a claim about intent rather than about outcome. The evidence is that nothing new appears: no new drafts against threads that arrived after you stopped, no new calls in the call list, no new entries in the decision log attributed to the engine. Give it a minute — work already picked up before you stopped finishes rather than being torn in half, which is the correct behaviour and briefly looks like the switch did nothing.
If new engine activity is still appearing several minutes later, the likely explanation is that what you are watching is not engine activity. A person on your team approving a held draft, an inbound call being answered by a line you did not close, or a provider's own delivery retries all continue by design. The decision log names the actor for every action, which settles it faster than watching a list.
Questions#
Does stopping lose the queue?
No. Nothing is discarded. Held drafts, approvals, follow-ups and scheduled work all survive; they simply are not acted on until you switch back. This is the same principle as a spent daily allowance, where work is held rather than dropped so that nothing is silently lost.
Can a customer workspace use it, or is it an operator control?
Both audiences have it, over the same implementation. There is no operator-only kill switch and no customer-only one.
Will a caller hear anything different while Connect is stopped?
Not by itself, which is why closing the line is the better tool for planned quiet periods. A closed line answers with a deterministic message in your business's name and records the call with an outcome that says why, rather than leaving the caller with a connection that goes nowhere.
Does it stop mail arriving?
No. Mail keeps being fetched and keeps becoming conversations. What stops is Connect deciding anything about it or replying to it.