Important scope before you build

A weather assistant sounds simple: a person asks for rain, temperature, wind, or a recommendation such as whether to carry an umbrella. But the application is making factual claims about an external, changing environment. A language model can write a clear explanation, yet it is not itself a weather instrument, forecast service, numerical solver, or authorization system.

The verified research context supports a practical principle for this kind of agent: a numerical result should be reported only when it originates from a trusted tool and passes explicit verification. The principle comes from research on LLM and agentic systems for smart grids, a domain where outputs can appear numerically plausible while remaining physically infeasible or untrustworthy. Weather applications are different from grid control, but the design lesson transfers directly. Do not let polished prose substitute for a verified measurement.

This tutorial therefore focuses on an architecture rather than claiming a particular SDK, model, weather provider, framework version, or endpoint contract. Before implementing any code, verify current vendor documentation for your chosen Next.js release, OpenAI API, weather-data provider, authentication system, deployment environment, and applicable organisational requirements.

What you are designing

The finished pattern has five clear responsibilities. The browser collects a user question. A server-side route accepts only a constrained request shape. A language model may decide that an approved weather capability is needed. The server validates that proposed capability call, invokes a trusted weather-data service, verifies the returned result, and gives a small structured result back to the model. Finally, the model produces an explanation based on that verified result.

The central rule is simple: the model may request an approved tool, but it must not receive authority to define the tool, choose arbitrary network destinations, alter authorization, or invent measurements when a tool fails.

• User interface: collects the question and displays an answer or a clear retrieval failure.
• Server-owned controller: owns policies, credentials, request limits, tool allowlists, logs, and error handling.
• Language model: interprets the request and decides whether an approved tool is relevant.
• Weather tool: queries a selected data source using only validated, bounded parameters.
• Verification layer: checks the returned structure, date, units, location match, and freshness rules before data can be reported.

This separation also makes the design useful beyond weather. The same pattern can support controlled access to internal data, forecasting solvers, analytics systems, and business workflows. In every case, the application—not the model—remains responsible for the action boundary.

Step 1: Write concrete policies first

Do not start with a broad prompt such as “help users with weather.” Start with a policy that an engineer can implement and test. This is important because the verified symbolic-guardrails research found that 85% of reviewed agent safety and security benchmarks lacked concrete policies. High-level goals and common sense are not precise enough for reliable enforcement.

For a read-only weather assistant, a practical policy could state the following:

• The assistant may retrieve weather only through a server-approved weather capability.
• The only accepted tool inputs are a location identifier or city query and an optional calendar date in a defined format.
• The server must resolve ambiguous place names through the selected trusted provider or ask the user for clarification.
• The server must reject arbitrary URLs, headers, SQL, shell commands, access tokens, account identifiers, and provider-selection instructions from model-generated arguments.
• The assistant may report temperatures, precipitation, wind, conditions, and dates only after the returned data matches the requested location and requested date.
• If retrieval or verification fails, the answer must say that live data could not be confirmed. It must not estimate or fabricate a forecast.
• The system must impose a maximum number of tool attempts and a bounded request duration.

These are not merely prompt instructions. Convert them into deterministic checks in server code. The symbolic-guardrails study reports that 74% of specified policy requirements can be enforced by symbolic guardrails, often with simple, low-cost mechanisms. An allowlist, schema validator, date parser, maximum-call counter, and field-level verifier are examples of straightforward controls that do not rely on the model obeying prose.

Step 2: Define a narrow weather capability

A narrow tool contract is easier to authorize and verify than a universal network tool. Your weather capability...