When an agent “searches the web” or “queries a database,” it’s generating a structured request — a JSON object that says: I want to call this function with these parameters. Your application code receives that, runs the actual function, and passes the result back. The LLM decides what to call. Everything else is software.
That distinction matters more than it sounds. It’s where most agentic systems fail — and almost never in the way teams expect.
The Loop
Every time an agent takes an action, the same cycle runs:
User sends a request
LLM receives the request alongside the tool catalog
LLM decides whether it needs a tool — if yes, generates a structured tool call
Application code executes the tool
Tool result returns to the LLM
LLM reasons over the result, then calls another tool or generates a final response
This loop runs once for a simple question. It runs a dozen times for a complex task, each call building on the output of the last. The loop is the engine. Everything else — the catalog, the schemas, the guardrails — exists to keep it pointed in the right direction.
The Catalog: What the Agent Knows It Can Do
The LLM doesn’t know what tools exist by default. You have to tell it.
When you build an agentic system, you define a tool catalog — a list of available tools passed into the LLM’s context alongside the user’s request. Each entry contains:
Name — what the tool is called
Description — what it does and when to use it
Schema — what parameters it accepts, their types, which are required
Tool selection is probabilistic reasoning, not a lookup table. The LLM reads descriptions and infers which tool best fits the current moment. That means tool descriptions function exactly like prompts — they shape behavior directly.
Same tool. Two descriptions. Different outcomes.
Bad:
fetch_page— Fetches a page from the internet.
Good:
fetch_page— Retrieves the full text content of a specific URL. Use afterweb_searchreturns a result and you need to read the full article. Do not use for general discovery — useweb_searchfor that.
The first leaves ambiguous when to use it. The LLM might call fetch_page before running a search, or call it redundantly. The second constrains the context and the sequencing. That precision prevents an entire class of failures.
Tool descriptions aren’t documentation. They’re behavioral constraints — and they deserve the same care as a system prompt.
Schemas: The Contract Between the LLM and Reality
A schema is the formal definition of what a tool accepts as input. At minimum, it defines:
Each parameter’s name and data type
Whether the parameter is required or optional
For constrained values, the allowed options (enums)
Here’s what one looks like in practice:
