01 · Diagnosis
When Your Agent Bypasses get_customer and Calls lookup_order Directly
When Claude calls lookup_order in 12% of cases without first calling get_customer, the cause is ambiguity in the tool contract, not unreliability in the model. Five fixes, in order of leverage:
- Add a mandatory precondition to the tool schema so
lookup_orderdeclaresrequires: ["get_customer"]. The orchestrator validates upstream tool completion before dispatching the downstream call - the constraint is enforced outside the model. - Instrument skip-rate metrics per tool pair. A 12% bypass rate signals a prompt ambiguity or missing dependency declaration, not a model hallucination. Treat it as a schema fix, not a prompt fix.
- Add a strict ordering rail in your system prompt - for example, "Always resolve customer identity via
get_customerbefore any order lookup" - and validate compliance in eval runs against your 12% baseline. Treat the prompt as the secondary guard, not the primary control. - Audit whether lookup_order is partially satisfiable without customer context. If it is, split the tool into
lookup_order_by_customerandlookup_order_by_idto eliminate the ambiguous routing that let Claude bypass the upstream call in the first place. - Map the fix to the CCA-F exam: tool dependency enforcement is a D2 (Tool Design) + D3 (Agent Operations) cross-domain concept. Scenario questions will hand you a skip-rate metric and ask you to distinguish a schema-level fix from a prompt-level fix - the architectural change is the right answer.
02 · Decision table
Schema fix vs. prompt fix
| Layer | Enforced by | Holds under ambiguous input? | Use when |
|---|---|---|---|
| Tool schema precondition | Orchestrator | Yes | The dependency must hold for every call. |
| System-prompt ordering rule | Model | No | Secondary guard, paired with a schema fix. |
| Tool split (by_customer vs by_id) | Schema shape | Yes | The downstream tool is satisfiable from inputs the model can fabricate. |
03 · FAQ
Frequently asked
If my agent skips get_customer and calls lookup_order directly in 12% of cases, what do I change?
Treat a 12% bypass rate as a schema problem, not a prompt problem. Declare lookup_order's dependency on get_customer in the tool schema (requires: ['get_customer']), have the orchestrator enforce that precondition before dispatching the downstream call, and add a strict ordering rule to the system prompt as a secondary guard. Re-measure skip rate against the 12% baseline in eval runs.
Is a 12% tool-skip rate a sign of model hallucination or a design issue?
It is a design issue. Hallucination would surface as fabricated tool names or invented arguments. A consistent skip on a real downstream tool means the model has been given enough latitude to satisfy the request without the upstream call - usually because the downstream tool accepts inputs that look complete on their own. Fix the schema, not the model.
Why is the schema-level fix preferred over a prompt-level fix?
Prompt rules are advisory and degrade under ambiguous input. A schema-level precondition is enforced by the orchestration layer before the tool runs, so the constraint holds even when the model is confident it can skip the step. The prompt rail remains useful as a backup, but the orchestrator is the guaranteed enforcement point.
What if lookup_order is partially satisfiable without customer context?
Split it. A single tool that accepts both customer-scoped and id-scoped inputs creates ambiguous routing, which is exactly what lets Claude skip the upstream call. Replace it with lookup_order_by_customer and lookup_order_by_id so the schema itself rules out the bypass shape.
How does this map to the CCA-F exam?
Tool dependency enforcement is a cross-domain concept in D2 (Tool Design) and D3 (Agent Operations). Expect scenario questions that hand you a skip-rate metric and ask you to distinguish a schema fix from a prompt fix. The correct answer is almost always the architectural change, with the prompt rail as the secondary control.