Frame the order-status tool caller experiment

Success is not “I followed the tutorial.” Success is producing evidence that: when the model emits a valid tool call, the runtime executes only the allowlisted function. The accepted input is narrow on purpose: chat messages, tool schema, and a fake order store. That narrowness is what lets you inspect every field and prevents a toy demo from being narrated as a production system.

Record the baseline you must beat: assistant that answers without tools on the same prompts. If the finished artifact cannot beat that baseline on the fixture below, stop and revise the claim before writing more code.

export const acceptance = {
  project: "a support assistant that asks a model when to call a read-only order-status function",
  invariant: "only an allowlisted function receives schema-validated arguments",
  expected: "A request for ord_123 produces one validated lookup and a reply based only on its result.",
} as const;

Expected evidence: A request for ord_123 produces one validated lookup and a reply based only on its result.. Treat the printout as a claim about this fixture, not as proof that the toolchain merely started.

For the order-status function-calling assistant, a decorative win often looks like a clean run that never checks tool-call validity rate; grounded status answers vs fabricated ones. Write the metric down now so later pages cannot redefine success after the fact. Also note the operational threat you will eventually gate on: allowing a write tool (refund/cancel) in the same registry.

For function-calling-code, write the claim on a sticky note in this exact shape: “Given chat messages, tool schema, and a fake order store, the order-status tool caller will …”. Fill the ellipsis with the observable part of: when the model emits a valid tool call, the runtime executes only the allowlisted function. Tape the baseline beside it: assistant that answers without tools on the same prompts. If someone later replaces your metric with a vibe check, the sticky note is how you push back.

Also sketch the one-sentence user story: a person uses this output to let the model request a read-only get_order_status tool, then answer from the tool result. If that sentence needs a dashboard, a model zoo, or five services, the lab scope is too wide—shrink the fixture (orders map + tool schema for get_order_status) until the story fits on one screen.

Decide now whether live network calls are allowed on page 1. For this lab they usually are not; inventory and contracts should run offline against orders map + tool schema for get_order_status. Note the metric you will eventually require (tool-call validity rate; grounded status answers vs fabricated ones) so page 4 cannot invent a softer target. The characteristic failure to keep in mind is executing a hallucinated tool name, or answering status without a tool call.

At the experiment brief stage for function-calling-code, the job is narrower than finishing a product demo. You are creating one progressive evidence piece about orders map + tool schema for get_order_status that later pages inherit without redefining success. Keep that fixture small enough to inspect by hand, keep outputs copy-pasteable as text, and refuse to narrate this baseline as if it were a production SLA: assistant that answers without tools on the same prompts.

For this page specifically, success looks like a falsifiable claim and baseline written before coding while still centering the user decision to let the model request a read-only get_order_status tool, then answer from the tool result. If you cannot point to a file, command, or assertion that proves that for the order-status tool caller, stay on this page instead of advancing.

Glossary: tool · Glossary: structured output · Cheatsheet: production ops signals

Next