Escalating to a person, end to end
Connect escalates when it cannot answer safely: the knowledge is missing, the question is outside what it may decide, or a gate refuses the action. The refusal becomes an item in Needs You naming what it could not settle, a person decides, and the decision is recorded. Getting the answer back into future work is a separate, deliberate step — a decision alone teaches nothing.
The chain#
- Trigger — the engine reaches a point it may not pass: an unanswerable question, a price, a commitment, or a gate that refuses.
- User or external event — a customer has asked something; on the phone, a caller is still on the line.
- Authentication and workspace resolution — already resolved; the escalation is written inside the workspace that owns the conversation.
- Ingest — nothing new arrives. The material is the conversation that already exists.
- Canonical record — the refusal is recorded against the thread or call, with the reason, not discarded as a non-event.
- Reasoning — the model states what it could not settle rather than producing a plausible answer. Uncertainty is a valid answer here.
- Knowledge, memory and rules — the escalation names what was missing, which is what makes it fixable: a gap in knowledge reads differently from a limit on authority.
- Autonomy and approval — a gate or an
ask_before_sendmode turns the refusal into an item awaiting a person. - Action through a provider — often none. On a live call the caller is told a person is coming back to them, and a follow-up is created to make that true.
- Result — the item sits in Needs You with the decision it wants.
- Relationship, timeline and memory — the refusal is on the person's timeline, so the next conversation starts knowing it happened.
- Audit, usage and Needs You — the decision log carries the refusal and, later, what the person decided.
Stage by stage#
| Stage | What you see | What changes | What can fail |
|---|---|---|---|
| The refusal | Connect saying, in the conversation, what it cannot settle | A logged refusal with its reason | A model that invents an answer instead — which is what the safe-refusal path exists to prevent |
| The promise | On a call, a spoken commitment that somebody is coming back | A follow-up is created so the promise has an owner and a date | A promise with no follow-up behind it; every call-back commitment must create the record that makes it real |
| The queue entry | One item naming the question and the conversation it came from | Needs You gains an item | Reading it as a draft to approve. There is nothing to approve — there is a question to answer |
| The decision | Your answer, in the item | The thread continues with your words | Answering the customer and nothing else, so the next identical question escalates again |
| The lesson | A memory at the right tier, or a standing instruction | Future drafts are written knowing it | Skipping this step; guidance on one thread does not generalise on its own |
| The record | The decision log entry | Refusal and resolution stored together | Nothing — both halves are written whether or not anybody acts |
Escalating from a live call#
A call is the hardest case, because the caller is present and waiting. Connect does not hand a live caller to a colleague: a completed transfer to a human is not available on the live carrier, and a page implying otherwise would be describing something that cannot happen. What it does instead is say so, take what it needs to make the call-back useful, and create a follow-up on the phone or task channel.
The live supervisor screen is the other half of this. Somebody watching a call in progress can steer it, which is a different thing from taking it over — and knowing which of the two you have is worth more than either.
Making an escalation stop repeating#
- Read the reason on the refusal. A missing fact and a withheld authority look identical in the conversation and are fixed in opposite places.
- If it was a missing fact, add it to Knowledge so answers are grounded in it rather than in a one-off reply.
- If it was authority, decide whether the boundary is right. Some questions should escalate every time — pricing is the obvious one, and the Connect Assistant cannot quote a price either.
- If it was a gate, leave it. Gates apply whatever the autonomy mode says, and an escalation caused by one is the gate working.
The measure of a good escalation is that the same question does not arrive twice for the same reason. A queue that keeps re-raising one topic is telling you where the knowledge gap is, in the most direct way available.
Questions#
Does escalating stop Connect working on everything else?
No. One conversation waiting for a person does not pause the others. The engine carries on with work it is allowed to do, which is the point of holding the boundary at the action rather than at the whole workspace.
Can a caller be put through to somebody while still on the line?
Not on the live carrier — a completed human transfer is not available there, so Connect does not promise one. It records what is needed and creates a follow-up instead, which is a commitment with an owner rather than a hopeful hand-off.
Where do I see everything Connect refused this week?
The decision log. Refusals are recorded with the rule or the reason behind them, alongside the actions, so the two can be read together rather than inferred from what is missing.