Model Independence, With the Receipt
ERPClaw has run in production through four different models with no module changed. Why that is possible, why most AI products cannot claim it, and what it tells a buyer.
Short answer. Production has run through Claude Opus 4.8, Kimi K2.6, Gemini 3.5 Flash, and Codex GPT-5.5, all on the OpenClaw platform, with no change to a single module. That is possible because no module was ever trained, fine-tuned, or prompt-engineered for a particular model. Swapping the model costs a configuration change. Disclosure: we build ERPClaw, so weigh the framing accordingly.
Why this is worth stating
Every AI product says it is model-agnostic. Almost none of them can describe what would break if the model changed, which is the question that actually distinguishes the claim.
The test is not whether the product runs on more than one model in a demo. It is whether correctness depends on which one. If a product’s accuracy is materially different across models, the model is load-bearing, and the buyer is exposed to a vendor’s roadmap, pricing, and deprecation schedule in a way nobody mentioned during the sale.
What makes the swap cheap
Three properties, and all three have to hold.
No module was trained for. There is no fine-tune, no model-specific adapter, no weights we ship. A module is a manifest and code. The model reads the manifest the way a chef reads a recipe, which is the argument we made in adding an industry is a recipe, not retraining.
The model interprets, deterministic code writes. The model works out what you meant. It never decides what the books say. Every posting goes through code that behaves identically regardless of which model triggered it, so the output of the write path does not vary with the model at all.
Invariants verify afterwards, unconditionally. Structural checks run after every ledger operation, and they do not know or care which model was in the loop. If a new model produced a wrong interpretation that led to an unbalanced book, the check fails the same way it would for any other cause. The same reasoning drives write ownership: assume the writer might be wrong, and arrange things so being wrong is survivable.
Put together: the model sits at the interpretation boundary, and everything downstream of that boundary is deterministic and checked. That is the entire reason a swap is a configuration change rather than a revalidation project.
What the swap does not fix
Being precise about the limits, since a claim this convenient invites suspicion.
Interpretation quality does vary. A weaker model misreads ambiguous input more often. It will not produce a wrong ledger, because the deterministic layer and the invariants stand between it and the books, but it will ask more clarifying questions and get more first attempts wrong. Model independence is a claim about correctness, not about experience.
Latency and cost vary considerably. A fast, cheap model and a frontier model are not interchangeable from an operator’s point of view even when they are interchangeable from a correctness point of view.
Four models is four. It demonstrates the property rather than exhausting it. A model with a materially different tool-calling contract could require platform work, and we would say so rather than pretend the abstraction is total.
Why most products cannot claim this
Not because their engineers are worse. Because of where the AI was added.
A system that bolted a model onto a schema designed before AI existed has to make the model responsible for correctness, since the deterministic layer underneath was never built to validate what an agent proposes. Once correctness depends on the model, changing the model means revalidating everything, and that is a project rather than a setting.
Which turns a question that sounds like procurement trivia into an architectural tell. Ask a vendor what breaks if the model changes. A specific answer means they know where their boundary is. A vague one means the model is holding more than they have admitted.
What it means for a buyer
Three practical consequences.
You are not exposed to one vendor’s pricing. When a model gets more expensive or a cheaper one becomes good enough, that is a decision you can act on rather than absorb.
You are not exposed to deprecation. Models are retired on schedules set by other companies. A system where that is a configuration change rather than a migration is one less thing on your risk register.
And you can put a different model on different work if you want to, since nothing in the ledger layer needs to know.
The verdict
Model independence is easy to assert and hard to arrange, and the difference between the two is where a system’s correctness lives. If it lives in the model, the claim is aspirational. If it lives in deterministic code with invariants checking afterwards, the model becomes a component, and components are replaceable by definition.
This is one of the explanations we developed for the IEEE International Conference on Information Reuse and Integration in July 2026. The receipt is the part that mattered to that audience: not that the architecture permits a swap, but that four have already happened.
Related posts
Adding an Industry to an ERP: a Recipe, Not a Kitchen
Why a new vertical in an AI-native ERP is a manifest rather than model training, what a generated tattoo-parlour module actually required, and where the analogy breaks.
The State of AI in Accounting: A 2026 Outlook
Where AI actually shipped value in accounting by 2026, what underperformed the hype, the automation tooling stack that earns its place, and what comes next.
Where AI Belongs in Accounting (And Where It Doesn't)
Three places AI earns its keep in accounting and three places it doesn't. A practitioner framework with the decision tree, not the marketing pitch.