Why we never lock a client's automation to one AI model

A client asked us last week if she should switch her support inbox automation to whatever AI model is newest. She had read a headline about it over coffee and wanted to know if she was falling behind. The honest answer was that the question itself should not come up. If switching models means touching the build, something was built wrong the first time.

What actually changed

On July 24, Anthropic (the company behind the Claude AI assistant) released Claude Opus 5, pitched as its best everyday model for knowledge work, priced the same as the model it replaces. It is the fourth new model Anthropic has shipped in under two months, following three others released in June, according to Axios.

The pricing held steady at $5 per million input tokens and $25 per million output tokens, the same rate as the previous version. So did nothing get more expensive. What changed is capability, and a new dial: users can now toggle how much effort the model spends on a task, low, medium, or high, trading speed and cost against how hard the model tries.

That is genuinely useful. It is also the fourth time this quarter a business owner has had a reason to wonder if they are on the right model. OpenAI has done the same thing with its own releases this year. The pace is not slowing down, and it is not going to.

The model is a part you swap. The system around it should not notice.

How a founder-led business actually uses this

You do not need to track every model release. You need to make sure your automations do not care when one happens.

The mistake we see most often is a workflow built with the AI call hardwired into the middle of it: the prompt, the model name, and the business logic all tangled together in one step of a Make or n8n scenario. When a better or cheaper model comes out, or the old one gets deprecated, someone has to open that scenario, find the buried call, and rebuild the reasoning around it while praying nothing else breaks.

The fix is to treat the model like a part you can pull out and replace, not a wall you build the house against. Concretely, that means three things when we build a system for a client. The prompt and the business rules live in one place, separate from whichever API is doing the thinking. The step that calls the model is a single, named point in the workflow, so swapping it is a one-line change, not a rebuild. And nothing downstream (your CRM update, your invoice, your customer's reply) assumes anything about which model produced the input, only about the shape of what comes out.

This is most of what we mean when we say a build is model-agnostic. It is not a marketing phrase. It is the difference between a ten-minute update and a two-day rebuild every time one of these companies ships something new, which right now is roughly monthly.

The honest math

Say your support triage automation runs on whichever model was current when it got built, wired directly into the workflow. A better, cheaper model comes out. Untangling that one call from the rest of the logic, testing it, and confirming nothing downstream broke typically runs 4 to 8 hours of a developer's time, more if the original build was rushed. At $75 to $150 an hour for that kind of work, one avoidable rebuild costs $300 to $1,200, and it repeats every time a vendor ships a meaningful update.

Building the swap point in up front costs very little extra the first time, usually under an hour of the build's total time, because it is a decision about structure, not additional work. You are not paying twice for the same thing. You are paying once, for a shape that does not need paying for again.

This is the actual job of a fractional Chief AI Officer, in one sentence: not chasing the newest model, but making sure your systems are built so that chase is never your problem.

That is also the difference in how we run a one-off project versus how these things usually get built without us. If you hire us for a single build, a support inbox, a lead router, an onboarding sequence, the model swap point goes in as standard operating procedure the first time, not as a change order after the next headline. We would rather spend the extra 45 minutes at the start than have you staring down a two-day rebuild in October because a vendor felt like shipping again. You should not have to know to ask for this. It should just be how the thing gets built.

What to do this week

1. Open your most important AI-powered automation and find where the model gets called. If the prompt, the model name, and your business rules are all jammed into one step, that is your risk.
2. Ask whoever built it (or ask yourself, if you built it in Make or n8n directly) how long a model swap would take today. If the honest answer is "I would have to rebuild it," that is worth fixing before you need to, not after.
3. Pick one automation and separate those three things: the prompt and rules, the model call, and what happens with the result. You do not need to touch anything else this week. That one change is what makes every future model release someone else's headline instead of your fire drill.