AI & Tech

Build on the Workflow, Not the Model

Two major labs shipped flagship models within days of each other. The lesson for founders: the model is a part you'll replace. The workflow is the asset.

Eduardo Diaz · 2026-09-11 · 6 min read

AI strategy LLMs product architecture founders

On September 1, Anthropic released Claude Fable 5.1 and Claude Mythos 5.1, calling them "the world's most advanced models for coding and knowledge work." Two days later, OpenAI announced GPT-6 Astra as "the most intelligent and aligned model in the world." Both list standard pricing at 0 per million input tokens and $50 per million output tokens.

If you run a company that depends on AI, that week probably raised a question in your leadership meeting: do we switch?

My honest answer is that it's the wrong question to have to ask in a panic. If a new model release forces a rebuild, the product was built on the wrong foundation. The foundation should be your workflow, your data and your business rules. The model is a part you'll replace, probably more than once this year.

The pace is the point

Look at Anthropic's own API release notes for this summer alone. Claude Fable 5 shipped on June 9. Claude Sonnet 5 followed on June 30, Claude Opus 5 on July 24, and Fable 5.1 on September 1. In the same stretch, older models were retired outright: Claude Sonnet 4 and Opus 4 on June 15, Opus 4.1 on August 5. After retirement, requests to those models return an error.

OpenAI's rollout of Astra was staged, too. Constellation Research reported that it went first to a select group of customers before broader availability. So even when you want the new model, you may not get it on your schedule.

None of this is a complaint. Better models are good news for everyone building products. But it means the model layer behaves less like a foundation and more like a supplier whose catalog changes every few weeks.

Prices and behavior shift, not just names

Swapping a model is rarely a one-line change, and the details are where budgets and timelines go sideways.

A few examples from the official notes, all public before this week:

That last one is the kind of thing nobody puts in a board deck. It's also the kind of thing that takes a feature down on a Tuesday afternoon.

What durable actually looks like

When we design AI systems at AetherCraft, we assume the model will change during the life of the product. That assumption shapes four decisions.

An abstraction layer between your product and the model. Your application should call your own interface ("summarize this filing," "classify this ticket"), not a vendor SDK scattered across fifty files. Behind that interface sits the model call, the retry logic and the vendor quirks. When something changes, you fix it in one place.

Evaluations on your own data. Public benchmarks tell you how a model does on someone else's test. You need a set of real examples from your business, with the answers your best people would give, that you can run against any model in an afternoon. This is the single most useful asset for model decisions, and most teams don't have one.

Prompts and rules in version control. Prompts, extraction schemas and business rules are product logic. They belong in your repository with history and review, not in a dashboard someone edited last month. When a new model behaves differently, you can see exactly what changed and roll back.

A human approval step where it matters. Anything that sends money, commits you to a customer or touches regulated data should have a person in the loop until your evaluations say otherwise. That step also protects you during a model switch, because a person catches the odd output before a customer does.

If you're new to how these pieces fit together, our glossary entry on what AI-powered software is is a good starting point.

Different models for different jobs

We don't have a favorite model. We have jobs to do.

For an international insurance brokerage, we built two production AI systems on Microsoft Azure in about eight weeks. Azure OpenAI reads 12 news feeds and hands the team a daily lead book, alongside a live 3,495-policy dashboard. Azure made sense there because of where the client's infrastructure and data already lived.

For a medtech parts and service company, we built three production AI systems where Claude works across five systems via MCP. That job was about operating across tools, and the choice followed the job.

What the two have in common is that both systems are organized around the client's workflow and rules, which is what makes the model a replaceable part rather than the whole product.

Questions to ask before you commit to one model

Before you tie a product to a specific model, put these to your team or your vendor:

  1. If this model were retired in 90 days, what would we change? If the answer is "most of the code," you have a coupling problem.
  2. Do we have an evaluation set from our own work? How many real examples, and who decided what a good answer looks like?
  3. Where do our prompts and business rules live? Can we see who changed them and when?
  4. What's our cost per task, not per token? Tokenizers, caching and output length all move the real number.
  5. Which features depend on vendor-specific behavior? Tool-calling modes, thinking settings and output formats are where upgrades break.
  6. Is the model available where our data has to stay? Cloud region, data retention terms and staged rollouts can all rule a model out.
  7. Where does a human approve the output, and what would let us remove that step?

You don't need perfect answers to all seven. You need to know which ones you can't answer yet.

The model will keep changing

There will be another flagship release soon, then another. Some will be meaningfully better for your use case, some won't be, and you should be able to find out which in days, not months.

That's the real test of an AI product: whether the business keeps running when the model underneath it changes. If you're weighing a build, or wondering whether something you already have would survive a switch, we're glad to talk it through with you.

Sources

Keep reading

← Back to Insights