Not sure I can call it an agent anymore

As a marketer, one of the things I keep hearing over and over again from peers in technology is how good AI agents are. People seem to be running multiple agents that do fantastic work, and particularly the mundane.

Almost a year ago, I tried building my first agent. It didn’t go too well. The technology was intuitive enough but not nearly as simple as it is today. More importantly, I had no idea what I was doing or why I was building the agent in the first place. I didn’t know how to frame what the agent should and shouldn’t do. The scope was surface-level, and I did it because everyone was doing it and not because I had a real need.

I decided then that I’d build another agent only when I have a real problem that only an agent can solve convincingly. I keenly observed what others built and learnt their use cases and reasoning.

Then a few weeks ago, I was working on my notetaker app for my Te Araroa adventure, when the idea came to me.

I’m going off on a 3000 kilometre hike next week, and I’m building this app to serve as my digital notebook, as well as a single database for additional details like emergency contacts, remote towns I need to ship food boxes to, details of my trail crew and an inventory of what they have (food, warm weather gear, extra toothbrushes and sanitisers, etc.), food expenses on trail, and a few other such things.

And so my genius idea was to add agentic capabilities to the app. That’s all I knew. So I asked Claude what agentic things I could realistically build for this project. One thing it said stood out: A resupply agent.

Here’s how it’d work:

One afternoon at a coffee shop, while refilling our bodies and phones, I’d open the app, go to the resupply agent section on the app, and tap a button that says: Check Ahead. 

The agent would only work if I had reasonably stable internet connection, hence the coffee shop.

Once I tap the button, the agent would search for up to five of the next resupply points on the trail, spanning roughly 150-200 kilometres. Then it’d fetch and display the following details:

• Grocery stores and smaller shops (called dairies in NZ) in that town, including addresses so I can check how far outside the trail marker these shops are.
• Opening and closing hours for those shops, factoring in any public holidays that might affect operating hours.
• List of food items I could buy in those shops, considering my vegan and mostly whole food diet.

With this information, I could plan out the next 8-10 days. For instance, if there was a Pak’nSave (large NZ supermarket chain) in two days’ time, then we don’t need to carry too much food until we hit that town. But if the next big shop is 5 days away with only a dairy shop in between, then we’d rather carry 5 days’ worth of food, because dairy shops typically have limited stock.

The agent would play a vital role in helping me organise trail logistics, and it’d be a pretty awesome story to tell. Or that’s what I thought.

Claude Code and I built the thing. Backend seemed solid. But when I tested out the agent, it timed out.

I knew it’d take a bit longer than looking up a predefined list because the agent has to do a live web search. But I hadn’t expected it to time out. After about 5 to 8 attempts, and failures, I asked Claude what could’ve possibly gone wrong.

Then Claude told me: It most likely timed out because the live web search was taking up more processing time than the free version of Vercel allows. Vercel is the backend tool my app is built on, and that platform has a 60-second window for web searches. The agent needs far more than 60 seconds to fetch all the information I asked it to.

So I was at a crossroads. Again. Do I pay for Vercel to increase the time limit? 

It was about US$20/month. I almost said yes to paying—just because I so wanted to see it work and then tell people about this amazing thing I built.

Then my common sense voice spoke up. Realistically, remote towns and cities rarely publish their store times and food lists on the internet. The big ones would have all details linked in Google Maps, and I’ll have Google Maps anyway.

Most importantly, the Te Araroa Trust (which maintains the trail) has a dedicated mobile app that maps out the entire trail, and has detailed notes about every section—including things like shops, water stations, shelters and campsites, honesty boxes, farms, Te Araroa partner suppliers, water crossings, tide info, weather info, and live comments from other hikers who’d gone before me.

This Te Araroa app is the holy grail for all hikers and it’s updated every day. There’s also a WhatsApp group for app support where the developer and the Te Araroa Trust crew are always available to answer questions.

To try and duplicate what they’ve already done, and so much more comprehensively than I ever could, is stupid and vain and a waste of energy and money—even if it was only about $80-$100 over the course of the trail.

As much as I hated admitting it, common sense made sense. So I scaled back my ambitions for the agent. Instead of doing a live search, I got the agent (not sure I can even call it an agent anymore) to lookup the list of towns along the trail and just fetch the next five. No shop names or times, but town names and their kilometre markers, which would still be super helpful for me to plan.

This was easier. I’d already uploaded the full trail map, and the detailed section notes from the Te Araroa website. The app was already using this database to calculate km points and section details for my daily logs.

I was rather disappointed to dial down the agent. I knew the scope well this time and it would’ve added genuine value to the app. I’d finally found a problem worth solving, but the Te Araroa Trust had already solved it, packaged it, and added a bow on top.

—

This is post 4 of 5 of me using Claude Code to build an app for my Te Araroa hike.

Post 1: The notebook guy started it

Post 2: Who will I be on trail?

Post 3: Kill your darlings, they keep saying

Post 4a: Yes-or-no questions are a bit limiting, apparently