Architect AI around principles, not vendors
Tools will keep changing; architectures tied to a specific vendor ecosystem age poorly and limit the organisation's ability to adopt what comes next.
The pace at which AI tools change is higher than most organisations’ procurement and architecture processes are tuned for. A tool that is the obvious choice today may be a legacy dependency in two years. That would be manageable if switching were cheap — but organisations that embed a specific vendor ecosystem deeply in their knowledge architecture discover, when they want to move, that they cannot.
The working rule is to architect around principles and interfaces, not around vendors. The specific tool chosen today should sit at the end of a chain of decisions that are themselves durable: where the knowledge lives, how it is structured, what formats it is stored in, how it is accessed. A new tool should be a change of endpoint, not a change of foundation.
What principle-first architecture looks like
In practice, this tends to mean four things.
Knowledge stored in open, portable formats. Not inside a vendor’s proprietary content system, where extraction is possible but expensive. Plain text (see Structure documents for AI consumption, not just human reading) and open schemas do the work here.
Interfaces described abstractly, not vendor-specifically. The organisation’s design should describe what it needs an AI tool to do — retrieval over a corpus, drafting against context, summarisation — rather than which vendor’s product does those things today. That allows the vendor behind the interface to change without the architecture changing.
Identity, access control and audit kept under the organisation’s control, not delegated entirely to a vendor. The vendor’s approach may change, or the vendor may disappear. Governance should not depend on that.
A small number of vendors, deliberately chosen, with clear switching stories. Not single-vendor lock-in, not promiscuous adoption of anything that demos well. The midpoint — a curated set of tools where the cost of leaving any one of them is known and manageable — is where the durable architectures tend to sit.
Why the heuristic holds against the temptation to specialise
Vendors will offer integration and optimisation as reasons to commit more deeply. Those offers often produce genuine short-term value, at the cost of long-term optionality. The relevant question is whether the specific optimisations justify the cost of being unable to switch later. In most cases, for knowledge architecture decisions that will still be load-bearing in five years, they do not.
The heuristic argues for a certain kind of discipline rather than vendor avoidance. Use the best tools available today. Use them in ways that do not require them to still be the best tools in three years.