Share:








Share:




Share:




What we learned after putting AI into our own products, operations, and client work, then watching unnecessary intelligence show up on the bill.
| TL;DR ✓ AI does not need to sit in every step of an AI workflow. Repeated lookups, calculations, fixed checks, and predictable routing often belong in ordinary software. ✓ The first run and run 50 can be different problems. AI may need to discover the path early, while repeated structure can move into automation later. ✓ Before we hunt for a cheaper model, we look for model calls that should disappear. That can reduce tokens, latency, tool calls, testing, and avoidable errors at the same time. ✓ Keep AI where the work still needs interpretation, judgment, generation, or a path that genuinely changes with the case. |
A few years ago, automation was boring in a useful way. Rules, scripts, APIs, scheduled jobs. If this happens, do that. The work was rarely exciting, but companies knew what they were buying.
Then AI arrived and the center of gravity moved. Suddenly every workflow wanted a model in the middle.
We get the excitement. We were early to build our own AI products, put AI into our own operations, and do the same for clients. We still think a lot of business software is moving this way.
We also got the bill.
The model call is only one line. Around it come subscriptions, usage credits, context, tool calls, retries, testing, monitoring, and human correction. A tool can enter on a small plan and look almost free in a demo. Real volume is where the economics become visible.
We have felt that directly. AI tools often enter as cheap experiments, then usage grows, the work gets longer, teams move into higher tiers, and production adds the services around the model. The price itself may be fair. The mistake is assuming variable AI effort will behave like a fixed software subscription.
That experience changed one question we ask very early now: does this step still need intelligence at all?
Imagine a recurring management report built with an AI agent.
The first few runs can genuinely need intelligence. The agent may have to figure out which systems matter, which metrics belong together, how to handle odd records, what deserves explanation, and how the final report should be assembled.
After enough successful runs, some of that work stops being a discovery problem. The same systems are queried. The same calculations happen. The same sections are assembled. The same distribution list receives the result.
Only a smaller part still changes: the anomaly, the unusual event, the explanation, the decision about what deserves attention.
At that point, asking the agent to rediscover the entire path every time is expensive flexibility. We would rather automate the repeated structure and keep AI on the part that still changes.

We have learned to look suspiciously at any model call that returns a fact the business already had or repeats a decision the business already settled.
That usually includes structured retrieval, arithmetic, thresholds, permission checks, fixed routing, and repeated assembly.
The examples are ordinary because that is the point. Finance does not need a model to total known values. Sales does not need a model to check whether a discount exceeds an approved threshold. Support does not need a model to guess whether an account is active when the system already knows. Operations does not need an agent to choose a route that has been the same for the last 200 cases.
AI can still sit around those steps. It can interpret the messy email, read the unusual clause, explain the exception, or decide what to investigate next. The known part should stay known.

This is one source of avoidable AI spend. Our AI Token Cost Checklist looks across 10 checks, including repeated context, model choice, unnecessary steps, evidence quality, retries, and ongoing cost controls.
One unnecessary model call rarely looks scary. The problem is repetition.
Each avoidable call adds tokens, latency, tool use, another output to test, another place for a plausible wrong answer, and another thing the team has to observe in production.
That is also how we think about the economics in our own workflow cost work. We calculate cost per successful outcome, then look behind the number. Before we optimize the price of a model call, we check whether the model call should exist.

There is an opposite mistake here too. A team can hear “move repeated work into automation” and start forcing everything back into rules.
That gets painful quickly when the work is genuinely messy. If you are maintaining dozens of branches just to understand the many ways a customer can describe the same problem, the rule system may be telling you where AI earns its cost.
We keep AI where the step needs interpretation, judgment across ambiguous evidence, useful generation, or a path that changes based on what gets discovered.
The goal is not to use less AI for the sake of it. The goal is to pay for flexibility where flexibility has a job.
Take 10 recent successful runs from one AI workflow.
Mark the steps that genuinely changed from case to case. Those are candidates to stay intelligent.
Then mark the steps that happened the same way every time. Same lookup. Same calculation. Same threshold. Same route. Same assembly. Those are the first places we investigate for automation.
After moving the stable work out, measure the workflow again. Did cost per successful outcome fall? Did latency improve? Did retries or human correction change? Savings only count if the quality holds.

We are still very pro AI. Building our own AI products and putting AI into real operations only made us more selective about where we spend intelligence.
Automation is excellent at repeating what the business already knows how to do. AI is excellent when the work still needs interpretation, judgment, generation, or discovery. A mature workflow can use both without pretending one should replace the other everywhere.
The cheapest AI architecture knows when not to call the model.
If you want a second set of eyes on where AI is genuinely earning its cost in your workflow, and where ordinary automation would do the job better, let’s talk.
Use automation when the correct result can be specified exactly or the business already knows the answer. Common examples include calculations, fixed rules, permission checks, structured lookups, and predictable routing.
Yes. In many production workflows, ordinary software handles stable steps while AI interprets messy input, judges unusual cases, generates useful output, or chooses a path that cannot be fully defined in advance.
It removes repeated model calls, context, tool use, testing, and possible retries from work that does not need probabilistic reasoning. The savings can show up in both spend and reliability.
An agent earns its flexibility when the next step genuinely depends on what it discovers while working. If the route is known in advance and rarely changes, a fixed workflow is usually easier to control.
Review a batch of recent successful runs. Look for steps that repeat the same lookup, calculation, check, route, or assembly every time. Then test whether moving those steps into software reduces cost while quality holds.
Share:




We’ve helped teams ship smarter in AI, DevOps, product, and more. Let’s talk.
Actionable insights across AI, DevOps, Product, Security & more
AI Token Cost Checklist