Tools / when the model reaches into the world

Tool definitions let `respond` call external functions — live stock, current prices, EMI options — before generating an answer. Every tool added is a new failure mode: APIs time out, parameters get hallucinated, failures are invisible without instrumentation.

Architectural Position

Before

fn(query_user, prompt_rewrite, schema, state, memory) → query_structured

search(query_structured) → context

fn(query_user, prompt_summarise, context, state, memory) → response

fn(response, prompt_extract, state) → memory

After

(, prompt_rewrite, schema, , ) → query_structured

search(query_structured) →

(, prompt_summarise, , , , ) →

(, prompt_extract, ) →

fn: The LLM call — respond can now invoke external functions
query_user: The current user message
state: Conversation history
memory: Persistent user profile
context: Retrieved phone data and user profile
tools: A set of typed, callable functions exposed to the model
response: A response that may include real-world data — live stock, current prices, EMI options

Step by Step

# The failure from Layer 6

User: "Is the Pixel 9a in stock at
       Croma Koramangala?"

Pipeline has:
  ✓ phones.json (static specs)
  ✓ user_profile.json (preferences)
  ✗ live inventory data
  ✗ current pricing
  ✗ any external system access

# The model either guesses or declines

The pipeline knows the phones. It does not know the world. Tools close this gap.

1 / 5

Implementation

What you build

Tool definitions for check_stock(), fetch_current_price(), get_emi_options()
respond decides which tools to call based on query_user
Error handling: structured fallback response when a tool call fails

What it fixes

System answers questions requiring real-world data — stock availability, current pricing, financing options.

Key Concepts

Tool / Function calling: A model feature where the model returns a structured request to invoke a function rather than a text response. You run the function and return the result.
Tool definition: A typed description of a tool — name, purpose, and parameter schema. The model uses this to decide when and how to call it.
Parameter hallucination: The model invents arguments for a tool call that do not match valid inputs — e.g. a store name that does not exist in the system.
Graceful fallback: A structured error response when a tool call fails — the pipeline continues with a useful partial answer rather than crashing.

The Failure

The Cascade Law
Each hop multiplies failure probability. Chains compound, not add.

The user asks: "Is the Pixel 9a in stock at Croma Koramangala?" The pipeline has no way to answer. It cannot reach outside the context window. The model either guesses (likely wrong, possibly stale) or declines. Tools exist to close this gap. But every tool is a new failure mode: APIs time out, the model hallucinates parameters, failures are invisible without instrumentation. A broken tool call silently degrades response or crashes the pipeline.

What it reveals

Tool calls can fail silently. APIs time out. The model hallucinates parameters. Every tools call added is a new failure mode. Failures are invisible without instrumentation.

Implication

Ability LLM can decide when and how to call external functions. Tool definitions shape what actions the model believes it can take.

Behaviour Tool availability changes system behaviour fundamentally. A model with check_stock behaves differently from one without.

Code Error handling is now critical. Every tool is a new failure mode. Defensive validation and graceful fallback are required, not optional.

Design Real-world data appears in response for the first time. Stock levels, current prices, EMI options. The product becomes actionable.

Economics Tool latency adds to total response time. Each external call is a variable. Parallel tool calls matter for user experience.