DEV Community

Cover image for I Built an AI Agent to Check the Weather. It Was Gloriously Unnecessary.
Daniel Akudbilla
Daniel Akudbilla

Posted on

I Built an AI Agent to Check the Weather. It Was Gloriously Unnecessary.

Let me get the confession out of the way early: I built an AI agent that, given a city name, tells you about the place and then checks the weather.

You know what already checks the weather? A weather API. One fetch. No model, no tokens, no monthly bill with the word "usage" in it. I knew this the whole time I was building. Built the agent anyway.

Here's the story of that, and a small argument for why doing the unnecessary thing was actually the point.

What the thing does

It's called the Travel & Weather Guide. You type in a city Lisbon, Kyoto, wherever and it gives you back four things: a couple of sentences on what the place is known for, the live weather right now, what people tend to do there this time of year, and a straight verdict on whether now is a good time to visit.

It runs two ways. A web page with a search box:

The Travel & Weather Guide web UI:Web UI of the travel and weather guide

And a terminal version, for when you want to feel like a hacker while asking about the weather in Bali:

The CLI starting up, printing "Travel & Weather Guide (type exit to quit)" and prompting for a city name]CLI for the travel and weather guide

Both talk to the same agent underneath. The weather itself comes from Open-Meteo, which is free and needs no key. The "thinking" comes from a model via the OpenAI Agents SDK.

How it actually works (spoiler: not MCP)

The interesting part is how the model gets the weather, because it doesn't. The model can't make an HTTP request or run code, it can only generate text. So instead of fetching anything itself, it asks an internal tool to do it, and waits for the answer.
In the SDK that looks like this:

export const getWeather = tool({
  name: 'get_weather',
  description: 'Fetch current weather for a given city using Open-Meteo.',
  parameters: z.object({
    city: z.string().describe('The city or town name to check weather for'),
  }),
  execute: async ({ city }) => {
    // geocode the city, then hit the forecast endpoint
    // ...return "Lisbon, Portugal: 24°C, wind 12 km/h"
  },
});
Enter fullscreen mode Exit fullscreen mode

That tool() wrapper turns my Zod schema into a description the model can read. So now the model knows a get_weather(city) function exists — but it can't run it. It can only ask.

The loop goes like this:

  1. You ask about Lisbon.
  2. The model thinks, "I need weather data," and emits a structured tool call: get_weather({ city: "Lisbon" }). No code has run yet. That's just the model raising its hand.
  3. The SDK's runner sees the request, runs my actual JavaScript function locally, and that function makes the plain fetch to Open-Meteo.
  4. The result gets handed back to the model.
  5. The model writes the final answer using that data.

People sometimes assume this is MCP. It isn't. MCP is for tools that live in a separate server you connect to over a protocol. This tool is just a function in my own process. The model requests, my code runs, the result goes back. All in-memory, one repo, no protocol.

The uncomfortable part

Look at that loop again. To tell you it's 24°C in Lisbon, the system:

  • sends the full conversation and tool definitions to a model,
  • waits for the model to decide it wants the weather,
  • runs the fetch I could have run in the first place,
  • sends everything back to the model,
  • waits again while it writes a paragraph.

Two model round-trips and a pile of tokens, wrapped around a single HTTP call that a first-week bootcamp student could write. The fetch was always the easy part. I built a very expensive middle manager to decide when to make it.

And here's the thing: this isn't just my weird little project. It's the whole moment we're in.

Everything is becoming an agent now

There's a quiet shift happening. A lot of things that used to be a function call, a cron job, or an if statement are being rebuilt as agents. Not because the old way stopped working. The old way is fast and basically free. It's just that "agent" is the shape everything wants to be right now.

Some of that is genuinely good. When a task is fuzzy, open-ended, needs judgment, or strings together tools in ways you can't predict up front, an agent earns its tokens. That's the real use case, and it's legitimately new.

But a lot of it is us wrapping perfectly deterministic problems in a probabilistic, token-metered layer because it feels like the future. We took things that were already solved and made them "smart," which mostly means slower, pricier, and occasionally confidently wrong about the weather. The wins are real. So is the tax. Both things are true at the same time, and nobody wants to say the second one out loud.

My weather agent is a tiny, honest monument to that tax. It is a fetch cosplaying as artificial intelligence.

So why did I build it?

Not to solve a world problem. Let's be very clear. Nobody was out there suffering from a lack of AI-narrated weather. Climate change did not get one degree cooler because my agent can tell you it's warm in Lisbon.

I built it because I did not want to be the guy who talks about agents at parties without having actually built one. You know that guy. I refuse to become that guy.

The agentic era is happening whether I have opinions about tokens or not.

Turns out the best way to understand the expensive absurdity of the agentic era is to commit a small, cheerful act of it yourself.

So no, you should not build an agent to check the weather. You should just call the API.

I, however, have now called the API. Through an agent. On purpose. And I regret nothing, except slightly the tokens. Cheers


Try it yourself

The code is on GitHub: Dakudbilla/openai-travel-weather-agent.

# clone and install
git clone https://github.com/Dakudbilla/openai-travel-weather-agent.git
cd openai-travel-weather-agent
npm install

# add your OpenAI key
cp .env.example .env      # then paste your key into .env: OPENAI_API_KEY=sk-...

npm start                 # web app → http://localhost:3000
npm run cli               # or the terminal version
Enter fullscreen mode Exit fullscreen mode

The weather data is free (Open-Meteo, no key), so the only thing you'll pay for is the tokens.You can get a free openai account generate the API key for it.

Happy Coding

Top comments (0)