Brute forcing increases costs

Tokenmaxxing is definitely not the flex it was a few months ago. It essentially means letting the model do whatever it takes to get to an answer, burning through tokens and API costs, spinning up unnecessary loops and reasoning steps, and turning something that should be deterministic into something erratic that needs minutes of thinking time. It’s really a symptom of a lack of precision in either the prompt or the configuration of the agent. Use any of the frontier models from the big three - Anthropic, Google and OpenAI - and they’ll usually paper over the gaps and produce something that looks sensible. But that relies on luck, and at production volumes the misses start to add up.

Using the right architecture

The basic rule of thumb is the simpler and more deterministic the agent and tasks, the better, so reduce the agent's thinking and reasoning as much as possible. If you're running Opus 4.8 with an orchestrator that needs several reasoning steps, or re-ingests the same data on every turn, that should be split into sequential tasks that are observable and controllable independently of each other, but that run together according to well-defined logic rather than the model choosing the path each time. Only then do you get full visibility and the ability to optimise cost at every step. Determinism wins every time.

The expenses processing agent we built in-house for finance teams is a good example of this. It uses a more powerful model for orchestrating, but a small model classifies, extracts and validates perfectly well at a fraction of the cost, removing around 90% of the unnecessary reasoning. It could be done by the orchestrating agent, but then you lose control and transparency. A video walkthrough is on the way very soon, or available now on my LinkedIn feed if you're reading this more than a week after publication.

The power of being model agnostic

Fallback Model

This is an essential part of agents and tasks in production. If the primary model fails, which is more often the case than you might expect, then you need a similarly capable model from a different provider to seamlessly carry out the task.

There are more scenarios where this happens than people expect. Even the major providers go down or hit capacity limits without warning, and managed services can enforce global usage quotas that fail your task at seemingly random moments. None of it is your fault, and none of it is something you can prevent from inside a single provider, which is exactly why a fallback on a different provider matters.

These points also speak to the next huge advantage…

Avoiding Vendor Lock-in

Not being tied to a model provider is not only beneficial, but it is essential for any enterprise today. It matters in production, but also for evaluation, because being able to run the same agent across different models makes it far easier to replicate or simulate how it will actually behave once it’s deployed.

We are also entering a period where safety and regulatory pressure can change a model's availability at short notice. A provider can restrict access to a model, or pull a version entirely, on grounds that have nothing to do with your use-case, and if your agent is built around that one model you inherit that risk with no say in it. The more capable the models get, the more likely this kind of intervention becomes, and the worse it is to be locked to a single provider when it happens.

Open source models need to remain an option for many businesses - as data becomes more valuable, and running private instances enters the radar.

Transparency wins

Ask most people who have built a Skill in Claude to tell you what the steps are in the reasoning or processing, and most will return your question with a blank look. And even the ones who can describe it in theory usually cannot tell you whether the agent actually executed those steps in practice. That is the dangerous part. When a step is missing or a tool quietly fails, the model does not stop and flag it, it carries on and returns the most plausible-looking result. You get a confident answer that looks right but has skipped something important, and without visibility into the run you have no way of knowing.

This is why, on every agent we put into production, you have to be able to explain and review the execution flow for any given run. Not the intended flow, the actual one.

Once you can see the cost, latency and inner workings of each step, the fixes are usually high value and low effort; not just model choice, but prompt engineering, tool use, or removing a tool and replacing it with a configured, deterministic task. Often a few hours of work takes a significant chunk out of the running cost.

Your team in control, supported however you need

For many enterprises, once you understand what needs to be done in production with your agents, the natural next step is to manage them in-house, learn from edge cases, handle them quickly, and run your agents like you do your own software stack. That is also where the care you took about the initial build pays off, as your own team becomes the one continuously improving the agent and driving it down the cost curve.

In the expenses agent, the orchestrator does real work when it outputs the extracted receipt data and appends it to a Google Sheet, or pushes it through a tool into a third-party system like Xero. Today, that justifies a more capable model with enough reasoning capability power to overcome edge cases. Over the coming months, as we discover those edge cases and harden the prompt and instructions across iterations, we can move that step to a smaller or open-source model and it will become more deterministic in how it runs, which on this build points to roughly another ten-fold reduction in cost. You earn the cheaper architecture as you become more precise and efficient.

As mentioned, I’ll be publishing a video walkthrough of the expenses agent I have referred to throughout, so you can see the architecture rather than just read about it. It is the first in a short series of build walkthroughs.

If you are trying to get agents working properly inside your own workflows, that is exactly what we do, so do get in touch.

By Chris Davison - Head of Agent Delivery

Original Article: https://www.linkedin.com/pulse/production-agents-hard-parts-chris-davison-nizbe/