Service
Vendor-neutral AI architecture
Vendor-neutral architecture means the parts that carry your business value, the evaluation set, the rules, the retrieval content and the data, belong to you and sit outside any provider. Changing model then becomes a decision you evaluate, not a project you fund. It does not mean a change costs nothing.
Who this is for
Companies making a first significant AI commitment, and companies that already feel the cost of a dependency they did not choose deliberately.
The business problem it addresses
Model capability and pricing are moving faster than procurement cycles. A system built tightly around one provider’s tool-calling format, output schema and quirks becomes expensive to move exactly when moving would pay.
The lock-in is rarely contractual. It is architectural, and it accumulates quietly.
Signs you may need this
Nobody can estimate what changing provider would cost. Prompts and business rules live inside application code. There is no evaluation set, so a switch could not be assessed anyway. A provider price change would materially affect the business case.
What the engagement includes
Separation of business rules and prompts from application logic. A provider-agnostic interface for model calls. An evaluation set that can be run against any candidate. Data and retrieval content held in your environment. Documented trade-offs for each deployment option.
What this does not promise
A model change still has to be evaluated. Tool calling, context limits, output schemas, safety behaviour, latency and cost all differ between providers, and some differences require real work to absorb.
The claim is narrower and more useful: you will be able to measure what a change would cost, and you will not have to rebuild the system to find out.
When this is not appropriate
When a single provider’s specific capability is the entire reason the system works. When the system is a short-lived experiment. When the added indirection would cost more than the flexibility is worth, which is a real possibility for small internal tools.
Questions buyers ask
Does this mean we use open-weight models?
Not necessarily. It means the choice stays open and can be revisited on evidence.
Is there a performance cost?
A small one, usually in engineering complexity rather than runtime. We state it rather than pretending it is free.
Can we still use provider-specific features?
Yes, deliberately and with the dependency documented, so the cost of moving is known rather than discovered.
What do we actually own at the end?
The evaluation set, the rubric, the business rules, the retrieval content, the data, and the documentation. Those are the assets.