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

Yes-or-no questions are a bit limiting, apparently

“Wouldn’t it be better to publish directly to your blog, though?” My engineer-brother, who can’t help but make everything around him more efficient, asked me.

I was telling him about my Claude Code project, the note taking system I’m building to help me document my days on Te Araroa, the long tramping trail that goes through the entire length of New Zealand. We’re both starting to walk the trail next week, so we were talking about it and around it, as you do.

You see, I’d built a web page (with Claude Code), where my notetaker app would directly publish any of the entries I chose. I call it TA Dispatch.

If I were to publish my trail notes directly to my blog instead of TA Dispatch, I could drive traffic and attention to my blog, a platform I’ve been writing on for 15 years.

Yo, bro. I know you’re reading this. Here’s your answer.

I had considered plugging my blog into my notetaker app. It’s the first thing I thought of when I decided it’d be nice to have something my dad and friends can use to follow my walk. Then I looked at the practicalities of it.

It wasn’t rocket science. I had to use WordPress’ write API so that every time I selected an entry on my notetaker app, it’d “write” and publish that as a post on my blog. I knew I could make it work. But Claude said something that dissuaded me.

It said I’d need internet connection for the API call to write and auto-publish. If anything were to fail in that process because I was out of network range, that entry might not publish on the blog at all. And I wouldn’t even know.

That made sense, I thought. I didn’t want another potential point of failure—I already had a system to back up my entries, and that could fail too. One risk was enough for me.

But my brother, as most siblings do, has a way of getting in my head. After his comment, I went back to Claude, and asked it to remind me why I’d decided against it. It told me the history. But this time, it also said something else:

If I really wanted to, I could still use the API. In fact, it wouldn’t be any more risky than the setup I had for backing up my entries.

Then it gave me options. Like adding the TA Dispatch page to my blog’s domain. My notetaker would still only publish to TA Dispatch, but the page would “live” on my blog.

I wanted to kick myself for not thinking of that.

Then I wanted to kick Claude for not suggesting it the first time.

As I was writing this, I asked Claude to review it. That’s when it pointed out something I hadn’t realised before: it didn’t give me options before because I didn’t ask for options.

When I first considered using the WordPress API, I’d asked Claude to do or not to do the API. Claude suggested against it.

When I went back after my brother’s observation, however, I reframed the question. Now it wasn’t a yes-or-no, but a why question. The scope was broader and my objective clearer. Claude responded in kind. It explained my initial decision and offered alternatives.

That was a fascinating experience. You hear so much about good prompts and bad prompts. There are even AI tools that convert mediocre prompts into robust ones. But I never expected a casual question, mid-conversation, would need to be as rigorously structured—because that’s not what we do when we talk to people.

If I had had the same conversation with a WordPress expert, they’d have asked me follow-up questions about what I wanted to achieve. Or they might already know the context if we’d been going back and forth on this project like I’d done with Claude. They would’ve offered suggestions earlier on and I might have considered the API option more seriously.

In the end, I didn’t use the API. But as much as I hate to admit it, my brother had a point. So I moved TA Dispatch to my blog.

Check it out: https://te-araroa.narmadhaa.com.

—

This is post 4a of 5. Because I wrote this while putting off writing the actual post 4.

Kill your darlings, they keep saying

For a few months now, I’ve been working with Claude Code on an experimental project. It’s a system to help me document my days and emotions while I attempt to walk the entire length of New Zealand.

Most people who walk this trail document their journey on social media. Instagram is naturally the best fit, because it’s audiovisual and doesn’t penalise you too much if you don’t post chronically. TikTok is another popular choice. For those who use these two platforms to post shorter videos throughout their journey, YouTube is the endgame. Open it up and you’ll see day by day logs, hour-long documentaries, and detailed series that capture the essence of what it’s like to be on this epic adventure.

I wanted to post on Instagram as well. But I also wanted to document daily notes just for myself. As notes. That I can look back on. Like a journal, in written form.

So I planned it. I knew I might be too tired after walking 8-9 hours to sit down and type into a phone. Even though I’ve written several long-form pieces on my phone before, part of me doubted that I’d do that on trail.

It was easy enough to build the shell. The interface was decent with an option to record voice notes, that would be transcribed and cleaned up before saving. And because I like to double check my work and double bag my electronics, I also decided to have a text-only log. That way, I could write or talk into my phone, depending on my mood.

I tested it. Neither the record button nor the save text button worked. I sat down to diagnose. After a lot of back and forth and enabling and disabling the developer menu on Safari, I learnt how to verify the error. A bit more back and forth with Claude Chat and we finally fixed the save text button. By then, it was 2am and we still needed to figure out what was wrong with the audio record button.

So I fell asleep and forgot about the project for two weeks. That was my reality throughout this process—I didn’t magically build a fabulous thing over a weekend. It took me months. Work and life happened. No matter how much I wanted to ignore the world and play with Claude, I had other commitments to honour, a father recovering from surgery, and a family that loves to be dramatic.

When I eventually returned to Claude, we went through several attempts to fix the issue before realising I needed to sign up to a voice transcription service, connect its API to Claude, and only then would my record button work.

Obviously, that’s common sense. However, I was under the impression that Claude Chat, with all its mightiness, could transcribe audio. In the planning stage, I didn’t ask the question specifically so Claude didn’t tell me.

Now I know Claude can’t transcribe audio. Neither can ChatGPT. But Perplexity does a pretty good job—it even transcribed Tamil, my first language.

Then I had to contend with two options: Sign up to a transcription tool and connect that to my Claude app. Or ditch the voice recording feature entirely.

The purpose of this project was to be able to talk into my phone. I didn’t want to get rid of it.

I took several days to think it over and kept coming back to the same idea: What if the transcription connection failed mid-way?

I’ve worked in tech long enough to know that every piece of tech you plug into another piece of tech—like adding more weight to your bicycle rack—is a potential point of failure. This is how software works. When something’s off, you check the plumbing, where things connect with each other, because that’s almost always the cause for a leak.

I went down that thought process rabbit hole. If transcription does fail for whatever reason, I would know fairly quickly. But there’d be no way to fix it while I’m on a 3000-km tramp. I mean, strictly speaking I could, but it’d be tedious and not what I’d want to do on trail anyway.

Then there’s the issue of backup. I wanted all my entries (text and voice) to be backed up to my Zoho WorkDrive account. In case I dropped my phone in the Whanganui river, everything I’d done until that point would still be safe. If transcription fails and I fix it, then I’d also have to re-check the backup status. All of this is super simple when I have a laptop connected to a stable internet connection, sat in my home with a hot coffee by my side. It’s torture to work all of that out on my iPhone, with spotty internet, in the backcountry, sitting on an uncomfortable rock, hungry and sore from walking all day.

If transcription fails and I don’t fix it, I won’t have an alternative voice recording system that’s as efficient and battery-conscious as the one I was trying to build. My phone’s voice notes would be fine, but they’d become messy. They won’t be automatically location-tagged or categorised by emotions and regions—a feature I definitely wanted.

Eventually, I decided to remove the voice option altogether. Going the extra mile to build it didn’t guarantee reliability. The extra work and admin didn’t justify the risk.

This was my biggest disappointment in the whole process: Having to kill the thing that got me started.

Even without the voice recording feature, I still have other potential points of failure in my app. I’ve done what I can to minimise niggly issues, but the real test would be on trail. One way to find out.


—
This is post 3 of 5.

Who will I be on trail?

A little while ago, I decided to create something with Claude Code to help me document my upcoming hike along Te Araroa—or TA. It’s a 3000 kilometre walk from one end of New Zealand to the other. I’m going southbound—so from Cape Reinga at the top to Bluff at the bottom of the South Island.

Map of Aotearoa New Zealand with the Te Araroa trail running through it
Source: https://www.teararoa.org.nz/map/

I’ve never done a multi-day hike before. I’ve done lots of day hikes of varying complexities but I’ve never had to worry about not having phone signal for long stretches or being out in the wild having to fend for myself. So I don’t know what that would do to me physically and psychologically. Which is fine, and is kind of the whole point of doing the hike—to challenge myself in ways I never have before and to hopefully find the courage and resilience within me to keep going.

I don’t know the person I’d become on trail, so building any piece of technology for this person is a bit tricky. I mean, would I want to sit down and write long drawn essays at camp after walking 25 kilometres a day? What would my tolerance be like after 20 river crossings and a big gash on my foot, surrounded by sandflies? Would I even care about writing the story then as I care about it now? Maybe, but also maybe not.

And that’s a problem. Because good technology understands the user’s mindset and behaviours. For instance, if you’re sat in an office with access to unwavering internet, you take it for granted that Safari will load your website without glitches. But when you’re going in and out of network areas all day, would you prioritise sending a message to your now-single and post-heart-surgery dad or would you try and open a website?

So many questions and so few answers. That’s what I was dealing with when I first went back and forth with Claude to see what we could build together.

As nerve wracking as that was, it was also one of the best lessons from this process: I had to do my best without assuming anything about my future self.

So I started making a list of things I need to factor in, while still allowing room for failure.

My solution needed to be as light weight as possible. It needed a daily journal log, and tags and categories to filter entries by. It needed to work offline, sync online. Mobile first, basic interface, less scrolling, big font, dark text, automatic location tagging that matches the TA route map, periodic data back-up, built-in language checker… all the things I needed to figure out how to do.

This is post 2 of 5.

The notebook guy started it

For a few months now, I’ve been actively thinking about and planning for the biggest trip of my life so far: Te Araroa—or TA. Basically, a long walk from the top of the North Island of New Zealand to the bottom of the South Island.

An essential part of the research is watching YouTube videos of other hikers that have gone before me, to learn from their experiences, to observe their gear, and methodologies and incorporate the lessons in my own planning and preparation. In one such video, I saw a brief scene where a hiker walks into a hut and greets the rest of the hikers who return the gesture—clearly they all know each other. And one of the hikers in the hut looked up from his notebook in which he’d been scribbling something.

It was the first time I saw a video of someone writing in a notebook on TA. Most people use technology—cameras, voice recorders, phones, drones. It’s not a big deal, if you think about it. Journaling is such a common habit and a lot of hikers do it. I just hadn’t seen anyone do it on a five-month endurance hike like TA.

That got me thinking about my own trip and how I’d document my journey. I hadn’t thought about that particular thing before. I loved the idea of writing on a notebook—in fact, I think I’ll still have a notebook. I’d appreciate the sheer analogue-ness of it after a hard day of walking.

But I also knew, within five seconds of watching that video, that I couldn’t rely only on handwritten notebooks to document my trip. One accident on the Whanganui river canoe section and all my notes would be dripping, dead weight.

I could use the Notes app on my phone, I considered. But they’d be so scattered. I didn’t know if I could trust myself to have the discipline to date and location-tag every entry, especially when I might be going through rainy, windy, sleety, scree slopey environments every day.

So I decided to find an alternative option that’d work a bit more… the way I want it to.

As a marketing copywriter who once obsessed with being found online, I’m ashamed to admit this: I didn’t even research what other options might be out there. Instead, like so many people of my generation and industry, I figured I’d just ask Claude.

For months I’d watched people on LinkedIn rave about Claude Code and brag about how they kept hitting their limits. There were proud posts about being on the highest paid plan of Claude Code because they were just building so much cool shit that the peasant version wasn’t enough anymore.

I hadn’t tried Claude Code yet because I didn’t know what I’d build. It seemed rather frivolous to pay for it for the sake of poking it and seeing if it’d poke back.

That clip of a guy writing on his notebook was the impetus I needed. I sat down with Claude Chat to talk it through. What could I build with Claude that could be useful for me on trail, and help me learn the basics of Claude Code and building a solution on it?

So I started experimenting with Claude Code. I’m building something to help me document my trip, and structure it in a way I can look back on and appreciate in the future. But as with any experiment, although the excitement and novelty of it buoys me, I also wonder if what I’m building will truly withstand the trail. I guess there’s only one way to find out.

This is post 1 of 5.