You're building an agent that helps a small business owner manage their Etsy shop. The agent can search recent orders, draft customer replies, update inventory, and adjust prices. The owner asks: "Reply to the angry customer from yesterday and figure out what happened with their order." You expected the agent to use search_orders and draft_reply. Instead, it answers in plain text: "I'd be happy to help. Could you tell me the customer's name?"
The system prompt is reasonable. The tools are well-described.
Why is the agent refusing to use them?
Why did you pick that answer? Two or three sentences. The act of articulating it is what builds the judgment — not the click that follows.
This is a context management problem disguised as a tool-use problem. The agent is acting reasonably given what it knows — it can't search orders without an identifier, and "the angry customer from yesterday" is unresolvable without conversation history. The fix is making sure the agent has access to the relevant past context, either via session continuity or by explicitly passing recent customer interactions in the prompt.
The agent's reluctance has nothing to do with the verb "figure out." Rewriting prompts to be more "tool-call-friendly" is a common dead end — if the agent doesn't have what it needs to act, prompt rephrasing won't fix it.
Forcing a tool call here would just make the agent guess at a customer name or call a search with empty parameters. Forcing tool use when the model lacks information produces worse outcomes, not better ones. tool_choice: "any" is a real lever, but it's the wrong one for this failure mode.
Stop-reason logic governs when the loop continues or terminates after a turn — it doesn't prevent tool calls within a turn. This option sounds technical and plausible but isn't how the SDK works. Students who pick D are reaching for infrastructure explanations when the actual problem is informational.