When a Spreadsheet Beats an Agent: Deciding Where an LLM Earns Its Cost

Most of what I’ve shipped this year has less AI in it than people expect.

A WhatsApp messaging automation for a field-services company with no model in its runtime at all. A property Q&A where every number comes from code and a model is optional. A digital clone where the model does most of the work, but only after I stopped sending it everything on every turn.

Those weren’t three different philosophies. They were the same question asked three times: does this step need judgement, or does it need a rule? This piece is about how I answer it, and what each answer cost.

What does “token economics” actually mean?

It means pricing every step of a system by what it costs to run each time, not by what it cost to build.

A language model charges for the text it reads and the text it writes, every time it runs. A rule written in code costs almost nothing per run once it exists. So the real comparison isn’t “AI vs no AI”. It’s:

                     COST TO BUILD     COST PER RUN      WHEN IT'S WRONG
  Rule / code        hours of work     ≈ $0              wrong the same way every time — easy to find
  LLM step           minutes           paid per token     wrong differently each time — hard to find

The last column matters as much as the first two. A rule that’s wrong fails predictably and you fix it once. A model that’s wrong fails plausibly, a little differently each time, which is far more expensive to catch.

When should a step be a rule instead of a model?

When you can write down the correct answer as a condition, write the condition.

My first paid Insight Bay deployment was a WhatsApp messaging automation for a Dubai field-services company, which ran live as a pilot in July. Each day it read the dispatcher’s job list, matched every job to the booking portal, skipped cancellations, and sent customers an approved message before and after the visit. It would have been easy to build as an “AI agent” that reads the day’s chat and decides who to message. I built the production loop as plain code instead, using Claude Code to write it.

The core loop is matching and a template. A model would have added a per-message cost, a chance of messaging the wrong customer with a confident explanation, and nothing a customer would notice. The decision log from that build says it in one line: an LLM is overkill and costly for this. On its best day it detected 42 jobs and delivered 39 messages with zero errors, and every one of those runs cost nothing in tokens.

The test I use now:

1. Can I state the right answer as a condition? (“job is in today’s list and not cancelled”, “fewer than 30 sales → refuse”) → it’s a rule.
2. Is the input messy human language I can’t enumerate? (“what’s going on with Creek Harbour?”) → that’s where a model earns its place.
3. Would a wrong answer be expensive? Then even if a model reads the input, a rule should decide what it’s allowed to do.

What if only part of the job needs a model?

Split the job. Let the model handle language, and let code handle anything that has to be correct.

Dubai Intelligence answers questions about Dubai property sales from government data. Every number in an answer is computed by code from the raw records. A model never does the arithmetic and never makes up a trend.

The part that could use a model is the planner: reading a question and deciding which calculation to run. Today it’s a rules planner. Here’s what the alternatives would cost:

  PLANNER             COST PER 100 QUESTIONS*     WHAT IT HANDLES
  Rules (keywords)    $0                          the phrasings I anticipated
  LLM (Sonnet)        ≈ $0.11                     phrasings I didn't anticipate
  LLM (Haiku)         ≈ $0.06                     same, cheaper model
  * list-price estimate at the time, excluding extended thinking

Those LLM costs are tiny. Cost isn’t the reason the live demo runs on rules. The reason is a rule I set early: an LLM planner has to beat the rules planner on the same test set before it earns a place. That benchmark is the next step, and until it’s run, the rules planner stays. A cheaper, predictable component stays until something measurably better replaces it. Being cheap per call doesn’t make a step free if it’s wrong in ways that are hard to spot.

How do you keep the cost down when a model is the right tool?

Stop paying to resend what never changes.

The digital clone on this site genuinely needs a model: visitors ask anything, in any phrasing, and expect a sensible answer. Its first version sent the model everything I know, my whole background, on every single turn of every conversation. Most of that was irrelevant to most visitors, and paying to send it again on every turn added up.

Three changes fixed that:

• A stable core, cached. The part of the prompt that never changes, around 21 KB covering who I am and how to behave, uses prompt caching, so repeated turns read it from cache instead of paying full price to resend it.
• Detail on demand. A further ~21 KB of detail (systems, career walkthrough, investing, personal) sits behind a tool. The model fetches a section only when the visitor’s question needs it.
• Every conversation logs its own cost. Input, cached input, cache writes and output tokens are recorded per chat, so cost is a measured number, not a guess.

The last one changed how I think. Once cost per conversation is a number you can see, “should this be a model call?” stops being a debate about taste.

How do I decide, in practice?

I run every step through four questions:

  1. Can the correct answer be written as a condition?      yes → rule
  2. Is the input open-ended language?                      yes → model may read it
  3. Does the output have to be exactly right?              yes → code computes it
  4. Has the model version beaten the simpler one on a test? no → keep the simpler one

Most systems end up as a mix: a model at the edge, where people talk to it, and rules and code underneath, where things have to be correct. The model gets the job only it can do. Everything else gets the cheapest thing that’s reliably right.

The takeaway

Building with AI made it easy to put a model everywhere. The useful skill now is knowing where not to: price each step per run, count the cost of being wrong as well as the cost of the tokens, and make the model prove it beats the spreadsheet before it replaces it.