Honor human requests before investigating

Learning objective

Honor an explicit request for a human immediately without attempting an autonomous resolution first.

Core idea

An explicit request for a person changes the next action. The agent should initiate handoff, even when it could probably solve the issue. It must not investigate the customer’s problem to decide whether the preference deserves to be honored.

The exam guide makes this ordering explicit. The architectural question is therefore about precedence: does the transfer path run before the normal lookup-and-resolution path? A system that acknowledges the request and then continues its usual investigation still gets the sequence wrong.

How it works

Recognize the requested destination

“Please connect me to a representative,” “I want a person,” and “Get me your manager” all express a destination rather than a request for another automated attempt. Neither courtesy nor anger changes that meaning. A request can be explicit without using the word “human.”

Distinguish a direct request from dissatisfaction. “This delivery is ridiculous” describes frustration; it does not select a representative. That case belongs to 5.2.3. If the customer follows with “No, I want a person,” the condition changes on that turn. Do not keep applying the earlier autonomous-resolution decision.

The instruction should recognize meaning rather than one exact phrase. A detector that matches only “human agent” misses ordinary requests for a representative or supervisor. In the standing prompt, state the action priority and include representative request forms; 5.2.5 owns the broader example-selection method.

Make escalation the next operation

In a Messages API support application, put the rule in the top-level system parameter. Define a custom client tool named escalate_to_human through tools, with a description stating that explicit human requests do not require prior investigation. That name belongs to the example application; it is not a platform-provided transfer service.

Claude returns the selected client call in a tool_use block, and your application executes it. Design the handoff’s input_schema to accept the conversation and known routing context without demanding facts that can only be collected through a problem investigation. An application-specific reason: "human_request" and a concise summary can distinguish this path from policy or tool-failure escalation.

The call sequence is the acceptance criterion. After the explicit request, lookup_order and process_refund must not run as attempts to avoid transfer. A short acknowledgment can accompany initiation, but a paragraph explaining the agent’s ability to fix the issue is another attempt to redirect the customer.

If the application has already resolved the case before the request arrives, preserve that result in the summary and transfer the subsequent request. Do not undo a completed refund merely because the customer requests a person. The rule controls what happens next; it does not rewrite completed history.

Pass existing context without creating a barrier

Include information already available in the conversation: the customer’s request, the issue as described, and any established case identifier. Mark unverified statements as customer reports. See 1.4.4 for the structure of the handoff summary. If no order has been identified, the handoff can say so without delaying transfer to search for one.

This distinction avoids two opposite defects. Sending no context forces the customer to repeat information the system already holds. Starting a fresh investigation turns context collection into an obstacle. Summarizing known information serves the request; obtaining extra evidence to prove that automation could work overrides it.

A queue may require routing information. Design that integration to accept incomplete problem details or an intake destination for unidentified cases. If a genuinely required transfer field is missing, ask only for that field and explain that it is needed for routing. Do not disguise optional troubleshooting as mandatory intake.

Verify the transfer result

The client-tool flow returns a tool_result after the application executes the queue operation. Report transfer status from that result. A queued case is different from a live representative joining the conversation. Use wording that matches what your integration actually confirms.

If the handoff service fails, the customer’s preference remains in force. Use the documented recovery path of your queue integration or present its available contact alternative. Do not silently return to autonomous troubleshooting because escalation failed. Also do not claim that a representative is connected when the tool reports an error.

After a human request, the handoff is the next operation, and the queue’s result decides what the agent reports.

The queue’s status names and recovery rules are application-defined. Claude’s tool-use interface carries the call and result; the application owns the business meaning and actual transfer. This lesson does not introduce a built-in Anthropic escalation API.

Key distinctions and trade-offs

The following alternatives can sound helpful while producing different behavior:

Immediate handoff can reduce automated resolution rates. That does not make it an error. Anthropic’s support guide discusses escalation efficiency separately from deflection rate; a customer choosing a person can make transfer the correct outcome even for an easy case.

Architecture / decision scenario

A customer says, “The delivery fee is wrong. Please connect me to a representative.” The retailer’s agent already knows the conversation identifier but has not looked up the order. Its usual workflow would retrieve the order and offer a covered fee refund.

The agent instead invokes the custom escalate_to_human tool with the available conversation context and reason: "human_request". The summary says that the customer reports an incorrect delivery fee and that order eligibility has not been checked. The queue accepts the case; the agent confirms that the request has been queued for a representative.

Compare a competing implementation that says, “Of course—let me check whether I can refund that first,” calls lookup_order, and transfers only after the customer refuses the offer. It has delayed the requested destination to attempt resolution. A polite acknowledgment does not repair the wrong tool sequence.

Now suppose the queue returns a failure. The first implementation states that it could not complete the transfer and offers the retailer’s configured contact alternative. It does not use that failure as permission to resume refunds. Test both acceptance and failure traces: the deciding evidence is what the agent executes after the human request.

Common exam traps

• Investigating first because the issue appears straightforward.
• Offering one more automated fix after an explicit request.
• Detecting only the exact phrase “human agent.”
• Treating a handoff promise as a successful transfer.
• Reverting to autonomous resolution when the queue fails.

What to remember

An explicit human request takes priority over the ordinary resolution workflow. Initiate handoff with existing context, perform only intake genuinely needed for that transfer, and report the integration’s actual result. The customer does not need to prove that the problem exceeds the agent’s capability.

Knowledge check

References

• Anthropic, Claude Certified Architect – Foundations Exam Guide
• Anthropic, Create a Message
• Anthropic, Define tools
• Anthropic, Tool use with Claude
• Anthropic, Customer support agent