Modular, multi-model, no vendor lock-in
How we design AI systems you can still change your mind about in two years — when the models, the pricing and the vendor landscape all look different.
Assume every component will be replaced
The single most expensive architectural mistake in enterprise AI right now is treating the current best model as a fixed point. Capability, context limits and price per token have all moved by more than an order of magnitude inside the last two years. Any system that hard-wires a specific model, a specific vendor SDK or a specific prompt format into its business logic has a rewrite scheduled that nobody has budgeted for.
So we design for substitution. Model access sits behind an internal interface. Prompts, tools and evaluation criteria are versioned artifacts, not string literals buried in application code. Retrieval is a service with its own contract. The result is a system where swapping a provider is a configuration and regression-test exercise rather than a project.
This has a commercial consequence worth stating plainly: it makes us easier to leave. That is intentional. A client who stays because switching is painful is not a reference.
Six decisions we make the same way every time
Not a reference architecture — those age badly. These are the constraints we hold constant while the specifics change.
Model-agnostic by abstraction
All model calls route through an internal gateway with a stable contract. Provider, model version and routing policy are configuration. Cost, latency and quality are measured per route so substitution is an evidence-based decision.
Evaluation before autonomy
Every workflow ships with an evaluation harness and a defined human-in-the-loop boundary. Autonomy is widened on evidence from production traces, never on optimism at design time.
Retrieval as a governed service
Source of truth stays in your systems. Retrieval enforces the same access control as the underlying data, so a model cannot become a path around your permissions model. Lineage is recorded for every answer.
Legacy platforms are first-class
The systems that run your business — ERP, EHR, PMS, CRM, warehouse, custom line-of-business apps — are integration targets, not obstacles to be replaced. Most AI value in the mid-market is unlocked at those seams.
Governance in the pipeline
Policy is enforced in code — data classification, retention, PII handling, prompt and output logging, model allow-lists — not in a document nobody reads. Auditability is a build requirement.
Cost modeled as an SLO
Token spend, cache hit rate and routing mix are instrumented from day one and treated as an operational target. Unit economics per transaction are visible before scale, not discovered after it.
Where lock-in actually comes from
Rarely the model. Usually one of these four, and each has a design answer.
| Lock-in vector | How it happens | Our design answer |
|---|---|---|
| Vendor SDK sprawl | Provider-specific client calls and response shapes spread through application code. | A single internal gateway interface. Application code never imports a provider SDK. |
| Prompt and tool coupling | Prompts tuned to one model’s quirks, tool schemas written to one vendor’s format. | Versioned prompt and tool artifacts with a portable schema, plus a regression suite that proves parity on a new model. |
| Proprietary data gravity | Embeddings, indexes and conversation state held in a vendor-managed store you cannot export. | Vector and state stores in your own cloud account, with re-embedding treated as a routine operation. |
| Consultant dependency | Undocumented systems only the delivery partner can safely change. | Your repositories, your accounts, documented handover, and your engineers reviewing our code throughout. |
Technical due diligence
Which cloud and AI platforms do you build on?
We build on the platform you already run — commonly Azure, AWS or Google Cloud — and access frontier and open-weight models through it or directly, depending on your data residency and procurement constraints. We hold no exclusive platform allegiance, and platform choice is an output of your constraints rather than an input we bring.
Do you use a proprietary Xcelacore AI platform?
No. There is no licensed middleware you become dependent on. The gateway, evaluation harness and pipeline patterns we bring are implemented in your codebase, in your accounts, and are yours to keep and modify.
Will our data be used to train models?
No. We configure enterprise API tiers with training explicitly disabled, and data handling — classification, retention, logging and redaction — is specified during architecture and enforced in the pipeline. The specifics are documented per engagement so your security reviewers can verify them rather than take our word. See Trust & Security.
How do you handle model behavior changes and regressions?
Every workflow has an evaluation suite with recorded expected behavior. Provider or version changes are run against that suite before promotion, the same way a code change is run against tests. Production traces feed back into the suite, so coverage grows against real failure modes rather than imagined ones.
Can you work inside our existing architecture review and change processes?
Yes, and we assume it. Our engineers work in your repositories, your pipelines and your review ceremonies. Where you have an architecture review board, security review gate or CAB, we scope around it explicitly rather than treating it as friction to route around.
Bring your architects
We would rather spend an hour with your technical team than send a deck. Book a working session and we will design against your real constraints.