Build the first working order-status tool caller

Build only what the claim requires: when the model emits a valid tool call, the runtime executes only the allowlisted function. Prefer boring, deterministic code over frameworks you cannot yet explain. Run the path twice; identical output on this fixture is a feature, not a lack of creativity.

export async function run(input: unknown, deps: Dependencies) {
  const started = performance.now();
  const validated = deps.parseInput(input);
  const raw = await deps.execute(validated); // POST `${AI_BASE_URL}/chat/completions` with messages and JSON-schema tool definitions
  const value = deps.parseOutput(raw);
  return { value, durationMs: Math.round(performance.now() - started) };
}

Expected evidence: A request for ord_123 produces one validated lookup and a reply based only on its result.. Read each printed intermediate as part of the argument that the path works—not as decoration.

Narrate the journey from raw input to result for a single example from orders map + tool schema for get_order_status. If you cannot name an intermediate, the implementation is still too opaque for this lab. Only after this path is solid should you generalize data sources or UI.

While implementing the order-status tool caller, print or log at least three intermediates that map to the claim (when the model emits a valid tool call, the runtime executes only the allowlisted function). Good intermediates are values a teammate could recompute with a calculator or diff. Bad intermediates are framework traces you cannot explain.

Re-run with orders map + tool schema for get_order_status twice. If the second run differs, either the path is nondeterministic (document the seed) or you have hidden global state—both are lab bugs until named.

Stop adding features once the path supports let the model request a read-only get_order_status tool, then answer from the tool result. Extra UI, extra tools, or extra models belong in later chapters. The mastery bar for this page is simply: a deterministic end-to-end path with intermediates.

At the implementation 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 deterministic path with printed intermediates 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

Previous · Next