Sample questions, analyzed.

Production data shows that in 12% of cases, your agent skips get_customer entirely and calls lookup_order using only the customer's stated name, occasionally leading to misidentified accounts and incorrect refunds. What change would most effectively address this reliability issue?

• AAdd a programmatic prerequisite that blocks lookup_order and process_refund calls until get_customer has returned a verified customer ID.
• BEnhance the system prompt to state that customer verification via get_customer is mandatory before any order operations.
• CAdd few-shot examples showing the agent always calling get_customer first, even when customers volunteer order details.
• DImplement a routing classifier that analyzes each request and enables only the subset of tools appropriate for that request type.

Production logs show the agent frequently calls get_customer when users ask about orders (e.g., "check my order #12345"), instead of calling lookup_order. Both tools have minimal descriptions ("Retrieves customer information" / "Retrieves order details") and accept similar identifier formats. What's the most effective first step to improve tool selection reliability?

• AAdd few-shot examples to the system prompt demonstrating correct tool selection patterns, with 5-8 examples showing order-related queries routing to lookup_order.
• BExpand each tool's description to include input formats it handles, example queries, edge cases, and boundaries explaining when to use it versus similar tools.
• CImplement a routing layer that parses user input before each turn and pre-selects the appropriate tool based on detected keywords and identifier patterns.
• DConsolidate both tools into a single lookup_entity tool that accepts any identifier and internally determines which backend to query.

Your agent achieves 55% first-contact resolution, well below the 80% target. Logs show it escalates straightforward cases (standard damage replacements with photo evidence) while attempting to autonomously handle complex situations requiring policy exceptions. What's the most effective way to improve escalation calibration?

• AAdd explicit escalation criteria to your system prompt with few-shot examples demonstrating when to escalate versus resolve autonomously.
• BHave the agent self-report a confidence score (1-10) before each response and automatically route requests to humans when confidence falls below a threshold.
• CDeploy a separate classifier model trained on historical tickets to predict which requests need escalation before the main agent begins processing.
• DImplement sentiment analysis to detect customer frustration levels and automatically escalate when negative sentiment exceeds a threshold.

You want to create a custom /review slash command that runs your team's standard code review checklist. This command should be available to every developer when they clone or pull the repository. Where should you create this command file?

• AIn the .claude/commands/ directory in the project repository
• BIn ~/.claude/commands/ in each developer's home directory
• CIn the CLAUDE.md file at the project root
• DIn a .claude/config.json file with a commands array

You've been assigned to restructure the team's monolithic application into microservices. This will involve changes across dozens of files and requires decisions about service boundaries and module dependencies. Which approach should you take?

• AEnter plan mode to explore the codebase, understand dependencies, and design an implementation approach before making changes.
• BStart with direct execution and make changes incrementally, letting the implementation reveal the natural service boundaries.
• CUse direct execution with comprehensive upfront instructions detailing exactly how each service should be structured.
• DBegin in direct execution mode and only switch to plan mode if you encounter unexpected complexity during implementation.

Your codebase has distinct areas with different coding conventions: React components use functional style with hooks, API handlers use async/await with specific error handling, and database models follow a repository pattern. Test files are spread throughout the codebase alongside the code they test (e.g., Button.test.tsx next to Button.tsx), and you want all tests to follow the same conventions regardless of location. What's the most maintainable way to ensure Claude automatically applies the correct conventions when generating code?

• ACreate rule files in .claude/rules/ with YAML frontmatter specifying glob patterns to conditionally apply conventions based on file paths
• BConsolidate all conventions in the root CLAUDE.md file under headers for each area, relying on Claude to infer which section applies
• CCreate skills in .claude/skills/ for each code type that include the relevant conventions in their SKILL.md files
• DPlace a separate CLAUDE.md file in each subdirectory containing that area's specific conventions

After running the system on the topic "impact of AI on creative industries," you observe that each subagent completes successfully: the web search agent finds relevant articles, the document analysis agent summarizes papers correctly, and the synthesis agent produces coherent output. However, the final reports cover only visual arts, completely missing music, writing, and film production. When you examine the coordinator's logs, you see it decomposed the topic into three subtasks: "AI in digital art creation," "AI in graphic design," and "AI in photography." What is the most likely root cause?

• AThe synthesis agent lacks instructions for identifying coverage gaps in the findings it receives from other agents.
• BThe coordinator agent's task decomposition is too narrow, resulting in subagent assignments that don't cover all relevant domains of the topic.
• CThe web search agent's queries are not comprehensive enough and need to be expanded to cover more creative industry sectors.
• DThe document analysis agent is filtering out sources related to non-visual creative industries due to overly restrictive relevance criteria.

The web search subagent times out while researching a complex topic. You need to design how this failure information flows back to the coordinator agent. Which error propagation approach best enables intelligent recovery?

• AReturn structured error context to the coordinator including the failure type, the attempted query, any partial results, and potential alternative approaches.
• BImplement automatic retry logic with exponential backoff within the subagent, returning a generic "search unavailable" status only after all retries are exhausted.
• CCatch the timeout within the subagent and return an empty result set marked as successful.
• DPropagate the timeout exception directly to a top-level handler that terminates the entire research workflow.

During testing, you observe that the synthesis agent frequently needs to verify specific claims while combining findings. Currently, when verification is needed, the synthesis agent returns control to the coordinator, which invokes the web search agent, then re-invokes synthesis with results. This adds 2-3 round trips per task and increases latency by 40%. Your evaluation shows that 85% of these verifications are simple fact-checks (dates, names, statistics) while 15% require deeper investigation. What's the most effective approach to reduce overhead while maintaining system reliability?

• AGive the synthesis agent a scoped verify_fact tool for simple lookups, while complex verifications continue delegating to the web search agent through the coordinator.
• BHave the synthesis agent accumulate all verification needs and return them as a batch to the coordinator at the end of its pass, which then sends them all to the web search agent at once.
• CGive the synthesis agent access to all web search tools so it can handle any verification need directly without round-trips through the coordinator.
• DHave the web search agent proactively cache extra context around each source during initial research, anticipating what the synthesis agent might need to verify.

Your pipeline script runs claude "Analyze this pull request for security issues" but the job hangs indefinitely. Logs indicate Claude Code is waiting for interactive input. What's the correct approach to run Claude Code in an automated pipeline?

• AAdd the -p flag: claude -p "Analyze this pull request for security issues"
• BSet the environment variable CLAUDE_HEADLESS=true before running the command
• CRedirect stdin from /dev/null: claude "Analyze this pull request for security issues" < /dev/null
• DAdd the --batch flag: claude --batch "Analyze this pull request for security issues"

Your team wants to reduce API costs for automated analysis. Currently, real-time Claude calls power two workflows: (1) a blocking pre-merge check that must complete before developers can merge, and (2) a technical debt report generated overnight for review the next morning. Your manager proposes switching both to the Message Batches API for its 50% cost savings. How should you evaluate this proposal?

• AUse batch processing for the technical debt reports only; keep real-time calls for pre-merge checks.
• BSwitch both workflows to batch processing with status polling to check for completion.
• CKeep real-time calls for both workflows to avoid batch result ordering issues.
• DSwitch both to batch processing with a timeout fallback to real-time if batches take too long.

A pull request modifies 14 files across the stock tracking module. Your single-pass review analyzing all files together produces inconsistent results: detailed feedback for some files but superficial comments for others, obvious bugs missed, and contradictory feedback—flagging a pattern as problematic in one file while approving identical code elsewhere in the same PR. How should you restructure the review?

• ASplit into focused passes: analyze each file individually for local issues, then run a separate integration-focused pass examining cross-file data flow.
• BRequire developers to split large PRs into smaller submissions of 3-4 files before the automated review runs.
• CSwitch to a higher-tier model with a larger context window to give all 14 files adequate attention in one pass.
• DRun three independent review passes on the full PR and only flag issues that appear in at least two of the three runs.