Sometimes, no matter how well the thing you built works, regardless of all the accolades during the demos, they don’t buy.

As much as that stings, I know what I can do. And I know I can do more today than I knew I could yesterday.

All that learning, the late nights, the early mornings, none of them are wasted. Because now I know when I hit a wall, there’s a way through it. There always has been.

How I got here, though, is a pretty good story. Let me tell you about the chatbot I built which tells a user if it doesn’t know the answer.

The First Step

A former colleague called me a few months back.

We’d worked together on a few projects. It had been a good working relationship, and they appreciated how I carried myself in some challenging conversations. Also, they’d been watching what I’d been posting about AI on LinkedIn.

Turns out their firm was putting together a proposal, and they needed something built. Could I help?

Years of Observations, Stuck in a Spreadsheet

Here’s what they had.

Researchers had spent years gathering climate and wildlife observations from Indigenous communities across Canada’s northern regions. Not satellite data. Not computer models. People who live on the land reported what they actually saw over five years.

Weather conditions. Wildlife health. Fish populations. Berry quality and abundance.

All of it carefully collected then analyzed statistically and presented in an Excel scorecard.

If you knew your way around the spreadsheet, it was a goldmine. If you didn’t, it was a wall of numbers.

So the challenge they posed was, could I unlock the observations for the communities who provided them through an AI-powered chatbot? Could we let anyone type a plain question then receive an accurate answer drawn from the data?

Three conditions: It had to answer only from the data, it couldn’t use any public AI models, and it had to sit online, running around the clock.

Why That’s Harder Than It Sounds

If you’ve used ChatGPT, you know it will answer almost anything you ask.

That’s the feature. It’s also the problem.

The reason these tools can answer anything is the same reason they make things up. They’re built to always produce something. Ask about a dataset they’ve never seen and you’ll still get a confident, well-written, potentially fabricated response.

For a project based on real observations, that’s a disqualifier.

There were other reasons to rule out the easy path. This is a multi-year project, and the big AI models change every few months. You can’t build a research tool that gives different answers in November than it gave in July.

No shortcuts allowed. Period. The whole thing had to run on open-source software on infrastructure I controlled. Getting it to stop making things up turned out to be a separate problem entirely. More on that in a minute.

Three Things I Had to Figure Out

I’d built something like this before. Sort of.

Last winter I put together an AI agent that delivers a localized weather forecast. To get it running around the clock I had to learn how to host it online. I figured I’d lean on that experience.

I figured wrong.

The hosting failed. The setup I’d used before couldn’t handle this. Running a language model on ordinary servers turned out to be painfully slow no matter how much hardware I threw at the problem. I had to move the whole thing to a different kind of infrastructure entirely, the kind with graphics processors built for this work. It only bills while it’s actually running, which keeps it affordable.

The data wouldn’t fit. I couldn’t just hand the spreadsheet over and expect good results. I had to write Python code to rebuild it into something compact. Small enough that the entire dataset could ride along with every single question. That way the system always has the complete picture in front of it and never has to guess at what it’s missing.

I had to learn open-source models. Not one of them. Several. I worked through a handful of options before finding the one that balanced accuracy against speed and cost. I’m still revisiting that choice as the questions get harder.

None of this was in my wheelhouse when I started. That’s sort of the point.

The Mistake That Taught Me the Most

My first instinct was to hand the model the numbers and let it find the trends.

Bad idea.

It got things backwards. Not often. But sometimes it would look at a declining trend and cheerfully report an improvement. Confidently. In well-written English.

Which is exactly the failure mode that makes people skeptical of this technology. The smart play is to always verify.

So I lightened its “mental” load.

I moved every judgment call out of the model and into Python code. The code figures out whether something is rising, falling, or holding steady. Then it hands the finished answer to the model, whose only remaining job is to say it in plain English.

The accuracy problems vanished.

The Part I’m Proudest Of

The finished tool works. It walks through observed trends correctly. It names the worst weather year in the study. It identifies which species took the hardest hit.

But that’s not the part I’d point to.

Ask it something the data doesn’t cover, and it tells you so.

No invention. No hedging. No confident nonsense dressed up in complete sentences. It just says the scorecard doesn’t address that.

Getting it to do that took real work. Tuning the instructions, catching good answers and bad answers, then testing repeatedly until I knew it would work both in the demo and when pushed live.

A research tool that knows what it doesn’t know is worth more than one that always has an answer. That’s as true of a tool as it is for you and me.

About That Proposal

The funder went another direction, and chose one of the other proposals in the mix.

As disappointing as that was, let’s be clear about what did happen.

Someone described a problem to me in plain language. I said I could build the thing that solved it. And I built it. It works. I could spin it up today in about 30 minutes and demonstrate it. The next step is scaling it to a much bigger dataset with more sources and more questions.

That’s the whole story. The outcome of the grant is somebody else’s decision. The work is mine.

Why I’m Telling You This

Much of what I write about helps you get more out of the tools that already exist. That’s real work and I’ll keep doing it.

But this was different, and I think it’s worth sharing.

A firm had a problem they could describe perfectly well in plain English. They didn’t know what was technically possible. They didn’t need to. They needed somebody who could listen to what they wanted, figure out what it would take, and build it.

That’s available to you too.

If your organization has data sitting in a spreadsheet that nobody can get at, or a question you keep answering by hand, or a process that eats hours every week, there may be something buildable there. Not a subscription to another tool. Something made for your actual problem.

I don’t know until I look. But looking is free.

Let’s talk about what you’re trying to solve.