DEV Community

Cover image for AWS Bedrock - Global Weather AI Agent
Charan Puneet Singh
Charan Puneet Singh

Posted on • Originally published at Medium

AWS Bedrock - Global Weather AI Agent

#aws #bedrock #ai #developer

Global Weather AI Agent

Introduction
Background : I travel different cities across the world for Work Purposes. Most of the time, my travels are unforeseen - due to project requirements, customer meetings and sometime with family as well. Unplanned travels almost always need quick planners and here I come up with this Global Weather AI Agent - To which I could ask for weather not just by city name, but in plain English and get a clear, human-friendly forecast.

For example :
- "What's the weather near the Eiffel Tower?" 
- "Capital of Punjab"
- "Largest city in Italy"
Enter fullscreen mode Exit fullscreen mode

What I built
Is an Agentic AI weather agent that does exactly what people like me need. It combines AWS Bedrock (Claude Model) with OpenWeatherMap to interpret vague or natural-language location descriptions, resolve them to coordinates, fetch weather data, and return a concise summary for next few days. No hardcoded city lists and it works for locations around the world.

Github Link : https://github.com/cpsingh87/AWS-Bedrock-Global-Weather-AI-Agent

How it works

  • Input: Free-form text (e.g. "London", "capital of France", "city near Eiffel Tower").

  • Output: A readable weather summary: current conditions, today's forecast, and a 2–3 day outlook with temperature, precipitation, and wind.

Output shown by Weather Agent

The agent does not simply call one API. It orchestrates several steps:
1) Interpret the user's intent with an LLM
2) Geocode the resolved place
3) Fetch raw weather data.
4) Use the LLM again to summarize data into a clear report.

Technical Architecture

Technical Architecture/Workflow

The Four-Step Pipeline : The agent runs a fixed pipeline of four steps for each user query.

  1. Step 1 - Interpret location (using Claude)
    The user input might be ambiguous. A prompt asks Claude to act as a "world geography expert" and return a single, concrete place name (e.g. "city near Eiffel Tower" → "Paris, France"). The prompt includes few-shot examples so the model returns only the place name, no extra text.

  2. Step 2 - Geocode (OpenWeatherMap)
    The interpreted string (e.g. "Paris, France") is sent to OpenWeatherMap's Geocoding API:
    /geo/1.0/direct?q={location}&limit=1&appid={key}
    We take the first result's lat and lon.

  3. Step 3 - Fetch weather (OpenWeatherMap)
    Using that (lat, lon), we call the 5-day forecast API:
    /data/2.5/forecast?lat=…&lon=…&units=metric
    The response is raw JSON (multiple timesteps, nested structures).

  4. Step 4 - Summarize (using Claude)
    Claude receives the raw forecast JSON and a short instruction set: 
    Intro with location
    current/today
    Next 2–3 days
    Notable patterns or alerts

Everything in "easy to read" formatting. The model returns a clean, narrative summary.

Key Implementation Details

  • AWS Bedrock: We use boto3.client('bedrock-runtime') in us-west-2 and the Converse API (converse) with a Claude Sonnet model ID. Parameters like maxTokens and temperature are set in inferenceConfig.
  • Config:OPENWEATHER_API_KEY is read from a .env file (or environment). AWS credentials for Bedrock are provided via aws configure or environment variables.
  • Errors: Each step checks for success (e.g. HTTP errors, empty geocode results). On failure, the loop prints an error and asks for the next location instead of crashing. This gives you a minimal but production-style pattern: env-based config, clear separation of steps, and robust error handling.

Why This Is "Agentic"

An agentic system is one where an AI doesn't just answer from a single call; it plans, uses tools, and iterates to achieve a goal. Our weather agent fits that description in these ways:

  1. Multi-step orchestration: The LLM is used at the start (interpret) and at the end (summarize). In between, deterministic tools run: geocoding and weather fetch. The agent's "brain" (Claude) drives the pipeline; the "hands" (APIs) do the data work.
  2. Reasoning over natural language: Users don't need to know exact city names or IDs. Claude maps vague or conversational input to a concrete place. That's reasoning as a step in the workflow, not a simple keyword lookup.
  3. Tool use pattern: Geocoding and weather APIs are used as tools: the agent (our Python code) decides when to call them and passes the right inputs (interpreted location, then coordinates). In a more advanced setup, the LLM could choose which tools to call via function-calling; here we've encoded the plan as a fixed sequence that mirrors that idea.
  4. Structured output and summarization: The final step isn't "return raw JSON." Claude is asked to produce a structured summary (intro, current, 2–3 days, alerts). So the agent doesn't just retrieve data - it interprets and presents it in a user-friendly way.

So even without dynamic tool selection, the design is agentic: Orchestration + Reasoning + External tools + Structured summarization.

Where You Can Use or Integrate This Agent

This pattern is useful anywhere you need "weather by intent" rather than "weather by city ID."

  • Chatbots and virtual assistants : Plug the same pipeline behind a Slack bot, Microsoft Teams bot, or a custom chat UI. The user message becomes location; the agent's summary is the reply.
  • Travel and hospitality apps : "Weather at my hotel" or "weather in the capital of the country I'm visiting" can be resolved and summarized the same way. 
  • Voice assistants (e.g. Alexa, custom voice UX) : Transcribed speech like "What's the weather near the Statue of Liberty?" can be passed to the agent; the spoken response can be the text summary.
  • Internal tools and dashboards : Support teams or operations might ask for "weather at our data center in X" or "forecast for our event location."
  • Multi-region or white-label products : The same agent works for any country and language (with localized prompts if needed). You can expose it as a shared service for multiple products or regions.

Try It Yourself

  1. Prerequisites: Python 3.7+, an OpenWeatherMap API key, and an AWS account with access to Bedrock (Claude).
  2. Setup: Clone the repo, copy .env.example to .env, set OPENWEATHER_API_KEY, and configure AWS credentials (aws configure or env vars).
  3. Run:pip install -r requirements.txt (only boto3 is required), then python weather_agent.py.
  4. Use: Enter a city, country, or description (e.g. Tokyo, capital of India); type quit or q to exit. The project is a single script plus config, so you can read through the four steps and adapt them to your own Bedrock and API setup.

Summary

We built a Global Weather Agent that:

  • Uses AWS Bedrock (Claude) for interpreting natural-language locations and summarizing weather.
  • Uses OpenWeatherMap for geocoding and forecast data.
  • Runs a Four-step pipeline: Interpret → Geocode → Fetch weather → Summarize.
  • Behaves in an Agentic way: Multi-step orchestration, reasoning over language, tool use (APIs), and structured summarization. You can run it from the CLI today and reuse the same pattern in chatbots, travel apps, voice assistants, and internal tools - anywhere "weather by intent" adds value. If you've built something similar on Bedrock or extended this agent, share your use case in the comments; the AWS Community benefits from real-world examples like this.

Top comments (0)