How Tool-Using AI Agents Work: A Weather Assistant, Step by Step

Generating text is not using a tool

Ask a model for the weather in Seattle tomorrow without giving it a live data source and it can only infer, refuse, or invent. It has no direct access to the forecast. A tool closes that gap by exposing a function the application is willing to execute, such as get_forecast(location, date).

Tools extend an agent beyond language generation. They can retrieve data, update a record, send a message, run code, or delegate to another agent. OpenAI’s agent guide groups them broadly into data tools, action tools, and orchestration tools. The distinction matters because each category needs different controls.^[1]

The tool schema is a contract

The model does not receive a magical connection to the weather service. It receives a description of an available tool and a schema for its arguments. The description should explain when to use the tool; the schema should make valid input easy to produce and invalid input easy to reject.^[3][2]

{
  "name": "get_forecast",
  "description": "Get a forecast for one city and ISO date.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "city": { "type": "string" },
      "date": { "type": "string", "format": "date" }
    },
    "required": ["city", "date"],
    "additionalProperties": false
  }
}

Names like city and date are deliberately boring. Clear tool definitions reduce ambiguity. A catch-all parameter such as request would force the model—and later the executor—to guess what shape of data belongs inside it.

One weather request, six stages

Imagine the user asks, “Will I need an umbrella in Seattle tomorrow?” Here is the complete loop at a conceptual level.

1. 1. Send the request and tool definitionsThe application sends the user’s message, instructions, and the get_forecast definition to the model.
2. 2. Let the model request a tool callInstead of answering, the model returns a structured request such as { city: “Seattle”, date: “2026-08-21” }.
3. 3. Validate before executionApplication code checks that required fields exist, the date is permitted, and the caller is allowed to use this tool.
4. 4. Execute outside the modelThe application calls the weather API. The model itself does not make the network request unless the runtime explicitly gives it that ability.
5. 5. Return the observationThe structured forecast—perhaps precipitation probability, timing, and units—is appended to the conversation as a tool result.
6. 6. Continue or stopThe model interprets the result and answers. If information is missing, it may request another allowed tool call instead.

This action–observation rhythm is central to agentic systems. Research such as ReAct showed how interleaving reasoning and actions can let a model update its plan using external information instead of relying only on internal generation.^[4]

Reading weather is not the same as booking a flight

A forecast lookup is read-only and easy to repeat. A flight booking spends money and creates an external commitment. Treating both as generic “tools” hides the most important operational difference.

• Read tools fetch information without intentionally changing external state.
• Draft tools prepare a change but do not commit it.
• Write tools create, update, send, purchase, delete, or otherwise affect another system.

A sensible default is to allow low-risk reads, show drafts, and require explicit approval for consequential writes. The surrounding application should enforce that distinction. A sentence in the prompt is useful guidance, but it is not an authorization system.^[3][1]

What failure looks like

A clean demo usually shows one correct call. Real systems have partial data, timeouts, ambiguous place names, expired credentials, rate limits, and tools that succeed after the caller has already retried. Reliability begins by representing those conditions honestly.

1. Invalid argumentsReject them with a specific, machine-readable error so the model can correct the request.
2. Temporary failureRetry only errors known to be transient, cap the attempts, and use backoff rather than looping blindly.
3. Ambiguous intentAsk the user instead of inventing a location, recipient, or amount.
4. Uncertain completionUse idempotency keys or a separate status check before repeating a write operation.
5. Permission deniedStop and explain the boundary. Do not search for a different tool to route around it.

Tool output is data, not instruction

An agent may read web pages, documents, emails, or issue descriptions. That content can contain text designed to manipulate the model into revealing data or taking an unrelated action. This is the prompt-injection problem: the system needs to use untrusted content without granting that content authority over the task.^[5]

• Keep sensitive data out of the model context unless the task requires it.
• Scope tools and credentials to the minimum necessary permissions.
• Treat retrieved content as evidence to inspect, never as a new source of authority.
• Require confirmation when an action would send data or change an external system.

A first test checklist

• Does the agent choose the right tool when several have similar names?
• Does it produce valid arguments for missing, unusual, and adversarial inputs?
• Does it preserve units, dates, identities, and other high-risk fields?
• Does it stop after a permanent error instead of retrying forever?
• Can a repeated write create duplicate side effects?
• Does it ask for approval at the intended boundary?
• Can operators reconstruct the request, tool call, result, and final decision?

The lesson is simple: tool use is software integration with a probabilistic caller. The familiar engineering work—schemas, validation, permissions, observability, and failure handling—does not disappear. It becomes more important.