exam-a · Q13Customer support

When the agent calls lookup_order and receives order details showing the item was purchased 45 days ago, how does the agentic loop determine whether to call process_refund or escalate_to_human next?

1. AThe orchestration layer automatically routes to the next tool based on the order’s status field.
2. BThe order details are added to the conversation and the model reasons about which action to take.
3. CThe agent executes the remaining steps in a tool sequence planned at the start of the request.
4. DThe agent follows a pre-configured decision tree mapping order attributes to specific tool calls.

nobody has checked this keyWhy

exam-a · Q14Customer support

After investigating a billing dispute over 25+ turns, you’ve identified that duplicate charges occurred due to a payment gateway timeout triggering retry logic. The required refund ($847) exceeds your $500 authorization limit You need to call escalate_to_human, and the human agent won’t have access to your conversation transcript. What context should you pass to enable effective resolution?

1. AA structured summary: customer ID, root cause, refund amount, and recommended action.
2. BYour diagnosis and the refund amount only.
3. CThe customer’s original complaint verbatim plus the tool result excerpts showing duplicate transactions.
4. DThe complete conversation transcript with all tool results.

nobody has checked this keyWhy

exam-a · Q15Customer support

Your agent is handling a billing dispute. After calling get_customer and lookup_order, it identifies that the dispute involves a promotional pricing error requiring manager approval – beyond the agent’s authorization level. How should the workflow handle this mid-process escalation?

1. ACompile a structured handoff with customer details, order info, and the identified issue before calling escalate_to_human.
2. BPersist the complete conversation and tool response history to a database, then call escalate_to_human with a reference ID.
3. CCall escalate_to_human passing only the customer’s original message.
4. DAttempt the refund with process_refund anyway, escalating only if the system rejects the transaction.

nobody has checked this keyWhy

exam-a · Q16Customer support

You’re implementing the escalation logic for when the agent should call escalate_to_human. Your team proposes four different approaches for triggering escalation. Which approach will most reliably identify cases that genuinely require human intervention?

1. AImplement sentiment analysis that monitors for frustration indicators (negative language, repeated questions, exclamation marks) and trigger escalation when the frustration score exceeds a configured threshold.
2. BConfigure the agent to escalate after three consecutive tool calls that fail to resolve the customer’s stated issue, ensuring a reasonable attempt before involving a human.
3. CInstruct the agent to escalate when the customer requests a human, when the issue requires policy exceptions, or when the agent cannot make meaningful progress.
4. DBuild a rules engine that maps specific issue types, customer segments, and product categories to escalation decisions, removing the need for model judgment calls.

nobody has checked this keyWhy

exam-a · Q32Customer support

Production logs reveal inconsistent error handling: when lookup_order fails, the agent sometimes retries 5+ times (wasteful when the order ID doesn’t exist), sometimes escalates immediately (premature for temporary network issues), and sometimes asks users for clarification (inappropriate when the issue is a backend permission error). Investigation shows your MCP tool returns uniform error responses: {"isError": true, "content": [{"type": "text", "text": "Operation failed"}]}. The agent cannot distinguish between error types. What’s the most effective improvement?

1. ACreate an analyze_error MCP tool the agent calls after any failure to determine the error category and recommended action.
2. BAdd few-shot examples to the system prompt demonstrating how to interpret error message patterns and select appropriate responses for each.
3. CEnhance error responses with structured metadata: include errorCategory (transient/validation/permission), isRetryable boolean, and a description of what caused the failure.
4. DImplement retry logic with exponential backoff in your MCP server for all errors, returning to the agent only after retries are exhausted.

nobody has checked this keyWhy

exam-a · Q33Customer support

When implementing your lookup_order MCP tool, the backend sometimes returns errors (e.g., “Order not found” or temporary database failures). What is the correct pattern for communicating these errors back to the agent?

1. AThrow an exception from the tool handler so the agent framework can catch and log it
2. BReturn the error message in the tool result content with the isError flag set to true
3. CLog the error server-side and return an empty result to avoid confusing the model
4. DReturn a success response with a “status” field indicating the error type

nobody has checked this keyWhy

exam-a · Q34Customer support

Your process_refund tool returns two types of errors: technical errors (“503 Service Unavailable”, “Connection timeout”) that are transient (5% of calls), and business errors (“Order exceeds 30 day return window”, “Item already refunded”) that are permanent (12% of calls). Monitoring shows the agent wastes 3-4 turns retrying business errors that can never succeed. Currently, both error types return only a plain text message to Claude. What’s the most effective way to reduce wasted retries while improving customer-facing response quality?

1. AImplement automatic retry logic at the tool level for technical errors only, passing business errors to Claude without retries.
2. BAdd few-shot examples showing how to distinguish retriable from non-retriable errors by parsing error message text.
3. CReturn structured error responses with retriable: false for business errors and a customer-friendly explanation for Claude to use.
4. DAdd a check_refund_eligibility tool that must be called before process_refund to prevent business rule violations.

nobody has checked this keyWhy

exam-a · Q41Customer support

During a billing dispute resolution, your agent successfully retrieves customer info via get_customer and order details via lookup_order, but when attempting to call process_refund, the tool returns a timeout error. The agent has enough information to explain the charges and verify refund eligibility, but cannot actually process the refund due to the backend failure. What approach best balances first-contact resolution with appropriate error handling?

1. AExplain the billing confirm refund eligibility, acknowledge the system issue preventing immediate processing, and offer escalation or retry later
2. BConfirm the refund will be processed and close the conversation, since the system has all necessary information to complete it automatically
3. CImplement automatic retries with exponential backoff for process_refund, keeping the conversation open until the refund is successfully processed
4. DEscalate immediately to a human agent since the refund action cannot be completed

nobody has checked this keyWhy

exam-a · Q42Customer support

Your agent has called lookup_order multiple times while investigating a customer’s return requests. Each response includes 40+ fields (items, shipping details, payment info, status history). Tool outputs now represent the majority of the conversation’s context. The customer mentions two more orders they want to discuss. What’s the most effective approach before making additional lookups?

1. AMove all tool responses to a vector database with semantic indexing, retrieving relevant portions as the conversation continues
2. BProceed with additional lookups without modifying the existing tool output context
3. CHave the model generate a natural language summary of each order’s key details, replacing structured responses with prose descriptions
4. DExtract only the return-relevant fields (items, purchase date, return window, status) from each existing order response, removing verbose details

nobody has checked this keyWhy

exam-a · Q43Customer support

A customer writes: “I’ve been going back and forth on this return for days. I just want to speak to someone who can actually help me.” The agent has confirmed via lookup_order that the return is straightforward – within policy and eligible for immediate processing. What should the agent do?

1. AProcess the refund via process_refund to resolve the underlying issue, then inform them it’s complete
2. BAcknowledge frustration, inform them this is resolvable now, and offer to complete it or escalate
3. CCall escalate_to_human immediately to honor the customer’s request
4. DAsk what specifically hasn’t worked in previous attempts before deciding whether to escalate or resolve automatically

nobody has checked this keyWhy

exam-a · Q45Customer support

A customer returns 4 hours after the initial session about the same billing dispute. The previous 32-turn session contains lookup_order results showing “Status: PENDING, Expected resolution: 24-48 hours.” In testing, you observe that when resuming sessions with stale tool results, the agent often references the outdated data in responses (e.g., “I see your refund is still being processed”) even after subsequent fresh tool calls return different information. What approach most reliably handles returning customers?

1. AStart a new session, inject a structured summary of the previous interaction (issue type, actions taken, resolution status), then make fresh tool calls before engaging.
2. BResume with full history but filter out previous tool_result messages before resuming, keeping only the human/assistant turns so the agent must re-fetch needed data.
3. CResume with full history and configure the agent to automatically re-call all previously-used tools at session start to ensure data freshness.
4. DResume with full history and add a system prompt instruction telling the agent to always prefer the most recent tool results when multiple calls to the same tool exist in context.

nobody has checked this keyWhy

exam-a · Q47Customer support

After expanding the agent’s MCP tools with delivery-specific capabilities (check_delivery_status, contact_driver, issue_credit, apply_promo_code, update_delivery_address, reschedule delivery), the total tool count has grown from 4 to 10. Your evaluation suite shows tool selection accuracy has dropped from 88% to 71%. Log analysis reveals the majority of errors involve the agent selecting between semantically overlapping tools — calling issue_credit when process_refund was correct, and calling check_delivery_status when lookup_order already returns the needed data. Which approach structurally eliminates the semantic overlap identified in the logs as the error source?

1. AEnable the tool search tool with defer_loading on the six new tools, keeping the original four always loaded, so the agent dynamically discovers specialized tools only when needed.
2. BSplit the tools across two sub-agents – a “financial resolution” agent with process_refund, issue_credit,and apply_promo_code, and a “delivery operations” agent with the remaining delivery tools – with a coordinator routing between them.
3. CAdd few-shot examples to the system prompt demonstrating correct selection for each ambiguous tool pair, such as showing when issue_credit applies versus when process_refund is appropriate.
4. DConsolidate semantically overlapping tools – merge issue_credit and process_refund into a single resolve_compensation tool with an action parameter, and fold check_delivery_status into lookup_order with an optional include_tracking flag.

nobody has checked this keyWhy

exam-a · Q48Customer support

During testing, you find that when a customer says “I need a refund for my recent purchase,” the agent calls process _refund immediately – but populates the required order_id parameter with a plausible-looking but fabricated value instead of first calling lookup_order to retrieve the actual order ID. The refund call fails because the fabricated ID doesn’t exist. Which change directly addresses the root cause of the agent fabricating the order_id value?

1. ASwitch tool_choice from “auto” to “any” to force the agent to make a tool call on every turn.
2. BUpdate the process_refund tool description to explicitly state that order_id must be obtained from a prior lookup_order call and must never be assumed or invented.
3. CPre-parse incoming customer messages to extract any order IDs mentioned, and inject them into the conversation context before passing to Claude.
4. DAdd server-side validation that checks whether the order_id exists in your database before executing the refund, returning an error to the agent if not found.

nobody has checked this keyWhy

exam-a · Q49Customer support

Anthropic’s tool use documentation states: “Write instructive error messages. Instead of generic errors like ‘failed’, include what went wrong and what Claude should try next.” A billing dispute agent uses lookup_order, which catches all exceptions and returns a tool_result with is_error: true and the message “Tool execution failed”. Monitoring shows two failure modes: the agent retries the identical call until hitting the turn limit, or it immediately calls escalate_to_human without trying alternative tools. Which change follows the documented recommendation and gives Claude the information it needs to select the correct recovery action for each error type?

1. AImplement retry logic with exponential backoff inside each tool implementation so transient errors are resolved transparently within the tool before any failure result is surfaced to Claude in the agentic loop.
2. BAdd an error classification step in the agentic loop that intercepts tool errors before Claude sees them, tags each as “retry,” “try_alternative,” or “escalate,” and appends that recommendation to the tool result.
3. CRemove is_error: true and return the error details as normal tool content, so Claude reasons about the response as data rather than treating it as a flagged failure condition that biases retry behavior.
4. DReturn error-type-specific messages with is_error: true, e.g., “Order not found-try get_customer to search by phone” for data errors and “Database timeout (transient)-retry should succeed” for infrastructure errors.

nobody has checked this keyWhy

exam-a · Q50Customer support

Production logs show that when the agent handles complex billing disputes requiring 6+ tool calls, it sometimes exhausts its max_turns limit after gathering data but before completing resolution or escalating. The team’s goal is to guarantee that every customer interaction ends with either a completed resolution or a human handoff, regardless of how the agent loop terminates. Which approach achieves this guarantee?

1. AAdd system prompt instructions telling the agent to call escalate_to_human with a summary of its findings whenever it determines it cannot complete resolution within its remaining actions.
2. BSplit the workflow into two sequential agent invocations – a first agent gathers information via get_customer and lookup_order, then a second agent receives that data and handles process_refund or escalate_to_human, each with separate turn budgets.
3. CAdd orchestration-layer code that checks the agent’s outcome after each loop termination – if the loop ended without a completed resolution or escalation, programmatically call escalate_to_human with the accumulated conversation context and tool results.
4. DImplement a pre-tool-use hook that counts tool invocations and terminates the loop with an automatic escalation once the agent reaches 80% of its max_turns limit.

nobody has checked this keyWhy

exam-a · Q51Customer support

A customer contacts the agent about a warranty claim on a power drill. Resolving this requires multiple sequential tool calls: get_customer to look up their account, lookup_order to find the purchase details, and then either process_refund or escalate_to_human depending on warranty eligibility. You’re implementing the agentic loop that orchestrates these steps using the Claude API. What is the primary mechanism your application uses to determine whether to continue the loop or stop?

1. AYou manually set the tool_choice parameter to “none” after the final expected tool call to force Claude to stop requesting tools.
2. BYou check whether Claude's response contains a text content block – if text is present, the agent has produced its final answer and the loop should exit.
3. CYou track the number of tool calls made and exit the loop once a preconfigured maximum is reached.
4. DYou check the stop_reason field in each API response – the loop continues while it equals “tool_use” and exits when it changes to “end_turn” or another terminal value.

nobody has checked this keyWhy