Human in the loop
Human in the loop means a person's decision is required before a specific action completes. The design question is never whether to have one — it is where, because a checkpoint on everything is abandoned within a fortnight and a checkpoint on nothing is discovered after something has gone out. Put it where the action is expensive to undo.
Placing the checkpoint#
Two properties decide whether a step deserves one: how hard it is to reverse, and how visible a mistake is to somebody outside the business. Everything else — how clever the step is, how much the model was trusted with — is a distraction.
| Action | Reversible? | Checkpoint |
|---|---|---|
| Reading and classifying incoming mail | Nothing left the building | No |
| Drafting a reply | A draft can be deleted | No |
| Sending to a customer | It has been read | Yes, unless the workspace has chosen otherwise |
| Placing a call | It rang | Yes, at first |
| Recording a memory or a fact | Editable, visible | No, but it must be visible |
| Clearing a do-not-contact entry | Legally and commercially costly | Always, and never by the Assistant |
That is a shape, not a policy. In Connect the policy is yours: autonomy is set per channel and can be narrowed to one mailbox, one number or one contact, and the narrowest scope wins.
The review-speed problem#
A checkpoint only exists if reviews actually happen. A queue that takes a minute per item and receives eighty items a day is not a control — it is a backlog that will be cleared by someone approving in bulk without reading, which is worse than no checkpoint because it produces a record of approvals nobody made.
- Everything needed to decide in one place. The message being answered sits above the draft, not on another screen.
- Ranked, not chronological. A first-time enquiry held for an hour is a different debt from a held reply on a week-old thread. Needs You is ranked for that reason.
- Edit and approve as one action. If correcting means rewriting elsewhere, people approve things they would have changed.
- Self-draining. Items whose cause has cleared leave on their own; a queue that keeps resolved work trains people to skim it.
- Narrow scope rather than blanket holds. Holding one account's replies keeps attention where it is deserved — see human approval without blocking low-risk work.
Does Connect use a human in the loop?#
Used, and it is a setting rather than a fixed behaviour. The four autonomy modes are off (the channel is disabled), draft_only (prepare, never send, do not even ask), ask_before_send (every outbound needs a human yes) and autonomous (act within the gates). They resolve across four scopes — contact, endpoint, channel, workspace — narrowest first.
draft_only is the mode people overlook and the most useful one early. It writes what Connect would say and stops, without queueing anything for approval, so a workspace can watch the quality of the drafts for a fortnight without anyone having to keep saying no.
Held work waits in Needs You, which is also where operational problems land — voice line health escalates into the same queue for both audiences — so there is one place a person looks rather than several. Every approval and every rejection is recorded against the person who made it in the decision log, which answers 'who released this' long after everyone has forgotten.
How the pattern fails#
- Rubber-stamping
- Volume outruns attention and approval becomes a reflex. The fix is fewer, better-targeted holds, not a reminder to read carefully.
- The queue as a bottleneck
- Work that could have gone out in seconds waits for a person who is asleep. Narrow the scope instead of widening the mode.
- A stale approval
- The thread moved on while the draft waited, so approving sends an answer to a superseded message. Regenerating uses the newer messages; editing does not.
- Responsibility without authority
- A reviewer who cannot change what they are approving is a signature, not a control.
- Silent expiry
- Items that vanish unresolved leave the business believing something was handled. Draining must have a visible cause.
Questions#
Does a held item stop the customer's clock?
No — and this is the part that surprises people. Nothing has been handed to a provider, so there is no message in flight and nothing in your sent folder. A held reply is not a slow reply; it is no reply, and the customer is still waiting.
Can approval be required for one customer only?
Yes. Autonomy resolves at four scopes and the narrowest wins, so a rule set against a single contact overrides the channel's. That is the usual way to handle an account where every word matters without slowing everything else down.
What is the difference between draft-only and ask-before-sending?
ask_before_send puts the reply in front of a person and waits for a yes. draft_only writes it and stops, deliberately without asking. The first is a control on sending; the second is a way of observing what Connect would say.