An assistant that answers questions but cannot hand over cleanly leaves the customer to do the integration work. Decide what it may do, what needs confirmation and what belongs with a person, then make the handoff a real workflow.
- 01Anthropic’s agent guidance favours simple, composable patterns and meaningful human oversight.
- 02A handoff carries the question, a short factual summary, record references and the reason, with a named owner.
- 03Test tool failures, duplicates and unsupported promises, not only answer quality.
Start with the boundary.
Anthropic’s agent engineering guidance favours simple, composable patterns and meaningful human oversight. The practical implication for a business: decide which actions a system may take, which require confirmation and which belong with a person before choosing a model.
A hypothetical sales journey.
Imagine a customer asking about a product on WhatsApp, then requesting an exception to a delivery promise. The assistant may explain approved product information. It should not invent stock availability, negotiate unsupported terms or promise an exception. It should transfer the request with enough context for a person to decide.
A delivery exception on WhatsApp
- 01
Customer
Asks about a product on WhatsApp.
- 02
Assistant
Explains approved product information. Does not invent stock availability.
- 03
Customer
Asks for an exception to the delivery promise.
- 04
Assistant
Does not promise or negotiate. Transfers the request with context.
- 05
Team member
Has enough context to decide.
Make the handoff a real workflow.
Our recommended handoff packet includes the customer’s question, a short factual summary, relevant record references and the reason for escalation. Identify an owner and make the pending state visible. Avoid copying unnecessary personal data or including speculative model reasoning.
What a handoff carries, and who holds it
Assistant assembles
- The customer’s question
- A short factual summary
- Relevant record references
- The reason for escalation
Named owner holds
- The pending request, visibly
- The decision
Handle the uncomfortable paths.
What happens outside business hours? What if the CRM is unavailable? What if the customer sends the same message twice? Design a safe acknowledgement, duplicate prevention and a retry policy. A failed tool call must not be presented as a completed action.
The paths to design before launch
- 01Message outside business hoursPass when: The customer gets a safe acknowledgement
- 02The CRM is unavailablePass when: A retry policy applies
- 03Same message sent twicePass when: Duplicate prevention handles it
- 04A tool call failsPass when: It is not presented as a completed action
Test more than answer quality.
Use a small evaluation set with ordinary requests, ambiguous requests, unsupported promises and tool failures. Track successful resolution, repeated questions after transfer, unresolved handoffs and unauthorised actions. Review examples with the people who actually receive escalations.
An evaluation loop for handoffs
- 01Build a small evaluation setOrdinary, ambiguous, unsupported promises, tool failures
- 02Run the assistant against it
- 03Track outcomesResolution, repeat questions, unresolved handoffs, unauthorised actions
- 04Review with escalation staffThe people who actually receive escalations
The goal is continuity.
This is an illustrative implementation pattern, not a reported client result. The business value to test is whether people reach a useful resolution with less friction—not whether the assistant can keep every conversation away from a human.
Sources & context
Sources checked 2026-09-10. Recommendations and illustrative scenarios are Noesis’s analysis, not claims of client results.