Building Weather Agent Chat: Intent Extraction, Natural Language Chat, and Meteorological APIs
How Weather Agent Chat parses user intent, extracts geographical entities from natural dialogue, and returns structured meteorological forecasts in real-time.
By Uttam Thapa · · AI/ML
⚡ Executive Summary (TL;DR)
Weather Agent Chat answers questions like "should I pack an umbrella for Tokyo this weekend?" — which requires two
extractions (where, and when), three OpenWeather endpoints, and one translation step from telemetry into advice. The architectural point that matters:
intent extraction and data retrieval are separate stages, so a bad parse and a failed API call produce different, individually recoverable errors.
Figure 1: A conversational answer built from three separate OpenWeather calls, resolved from one sentence.
From Dashboard to Conversation
Conversational agents are steadily replacing static dashboards, and weather is a good place to see why. A dashboard shows you 28°C, 85% humidity and an AQI of 4.
A person wanting to know whether to carry an umbrella has to interpret all three. The agent's job is to do that interpretation, which turns out to be a much
harder engineering problem than fetching the numbers.
Two Entities, Extracted Separately
Every weather question resolves to two things, and both can fail independently:
📍
Target location
City, country, or coordinates — Tokyo, Japan. Ambiguity is common: "Springfield" needs a follow-up question, not a guess.
🕒
Temporal scope
current, tomorrow, weekend. This decides which endpoint answers the question at all.
// Entity extraction runs before any network call is made.
async function processChatMessage(userInput: string) {
const extractedIntent = await extractLocationAndDate(userInput);
if (!extractedIntent.location) {
// A clarifying question is a valid answer. Guessing is not.
return "Which city or location would you like me to check weather for?";
}
const weatherData = await fetchOpenWeatherData(extractedIntent.location);
return formatNaturalResponse(weatherData, extractedIntent);
}
💡 Why the split matters
Fusing extraction and retrieval into one model call feels simpler and costs you observability. Separated, "I could not understand the location" and
"OpenWeather timed out" are distinct failures with distinct recoveries — ask a question, or retry. Fused, they both surface as an unhelpful apology and you
cannot tell from the logs which one happened.
Mapping Intent to Endpoints
The temporal scope selects the data source. Choosing wrongly produces answers that are confidently about the wrong day.
| Endpoint |
Answers |
Returns |
| /data/2.5/weather |
"right now" |
Temperature, humidity, pressure, wind, condition code |
| /data/2.5/forecast |
"tomorrow", "this weekend" |
Five days in three-hour steps |
| /data/2.5/air_pollution |
"is it safe to run outside" |
AQI plus PM2.5, PM10 and NO₂ concentrations |
The forecast endpoint deserves care: it returns three-hour buckets, not days. "This weekend" means selecting and aggregating the buckets that fall inside
Saturday and Sunday in the destination's timezone — a detail that silently breaks for any user asking about a city on the other side of the date line.
Turning Telemetry Into Advice
Returning Temperature: 28°C, Humidity: 85% makes the agent a slower dashboard. The value is in the last translation step, where thresholds become
recommendations:
☀️
UV index above 8
Recommend sun protection, sunscreen, and shaded routes for midday travel.
🌧️
Precipitation above 70%
Recommend an umbrella and a waterproof layer; suggest indoor alternatives for the affected window.
😷
AQI above 4
Advise caution on outdoor exercise, particularly for sensitive groups.
These thresholds live in code, not in the prompt. A model asked to decide whether 71% precipitation warrants an umbrella will answer differently on different
days; a constant will not. Let the model handle language, and keep every number that drives a recommendation in a table you can test.
✅ Key takeaways
- ✓Separate extraction from retrieval. Distinct stages produce distinct, debuggable failures.
- ✓Ask rather than guess. An ambiguous location deserves a clarifying question, and users read that as competence.
- ✓Aggregate forecasts in the destination timezone. "This weekend" is local to the place being asked about.
- ✓Keep decision thresholds in code. The model writes the sentence; the constant makes the call.
- ✓Translate data into action. Advice is the product; the numbers are the input.
Frequently asked questions
How does a conversational weather agent understand a question?
It extracts two entities before any network call: the location and the temporal scope. The temporal scope then selects which API endpoint can answer at all — current conditions, forecast, or air quality.
What should an AI agent do with an ambiguous location?
Ask. A clarifying question is a valid answer and reads as competence, where guessing between two cities of the same name produces a confidently wrong forecast.
Should recommendation thresholds live in the prompt?
No. Keep every number that drives a decision in code where it can be tested. A model asked whether 71 percent precipitation warrants an umbrella will answer differently on different days; a constant will not.
Home · Projects · Blog · Services · Résumé · Contact