A user-facing assistant, a process that crosses several systems and an AI product may call the same model. They still require different architectures. The trouble starts when a platform bought for the first use case becomes, through inertia, the answer to the other two.

Before comparing vendors, I decide what the company is prepared to buy, what it needs to assemble and what it must be able to carry elsewhere. That decision narrows the field faster than a feature comparison.

One vendor decision should not become the whole architecture

A regulated banking program made this distinction concrete. The user-facing platform enabled business teams to create more than 2,000 agents. The governance doctrine decided how those systems were assessed. Connectors defined what they could read or do. The registry retained their identity, classification, obligations and the version of the rules applied.

Those four elements served different jobs. Treating them as one product choice would have made the initial platform responsible for the bank’s future products, controls and institutional knowledge. We kept the boundaries explicit instead.

Start with the three workloads

WorkloadSensible starting pointKeep under your control
Employee assistanceA ready-made product in the tools people already useIdentity, approved sources, usage policy and adoption evidence
A process across several systemsWorkflow automation or orchestrationProcess state, permissions, failure handling and audit trail
A differentiating AI productA product and execution layer designed for the jobBusiness logic, evaluation sets, product experience and evidence

An enterprise can use all three approaches. The choice becomes dangerous when nobody can say which parts may move and which parts encode the business itself.

Portability is a boundary, not a promise of zero switching cost

Models are not interchangeable components. They differ in tool use, context handling, latency, safety behavior and cost. Moving from one to another can require changes to instructions, tool schemas, evaluations and the product experience. An architecture that ignores this work is not portable; it has simply hidden the migration cost.

The useful goal is bounded change. A model migration should not require the company to recreate its rules, redefine every connector, rebuild its test cases or lose the evidence behind past decisions. Stable interfaces and company-owned evaluation sets make the effort visible and measurable.

The final MCP 2026-07-28 specification provides one useful boundary. Its stateless core standardizes exchanges between hosts and servers while the host retains permission and security decisions. MCP can make an integration easier to replace. It does not decide who may approve a payment, which customer data an action may use or what evidence the company must retain.

Six questions that survive the vendor demo

01

Whose identity performs the action?

Does the system use the employee’s actual rights, or a technical account with broader access? Can the company limit an action, not only a data source?

02

Who defines what a connector means?

Is it exposing a raw API or a business action with clear conditions? Who updates that meaning when the source system changes?

03

Can the team reconstruct and stop an execution?

The trace should show the user, rule, model, tool and result. Partial actions and integration failures need a recovery path.

04

What can you take with you in usable form?

Rules, prompts, evaluation sets, connector definitions and traces need an export that another team can operate, not a PDF archive.

05

What does a model change actually cost?

Run the same evaluation set on a second model. Track behavioral changes, instruction rewrites, tool failures, latency and correction time.

06

Who owns day two?

Someone must watch cost, quality, permissions, incidents and vendor changes. A pilot owner is not automatically an operating model.

These questions also expose where accountability sits. The NIST AI RMF 1.0 treats Govern, Map, Measure and Manage as continuing work across the system lifecycle. In Europe, the AI Act framework, as amended in July 2026 by Regulation (EU) 2026/1744, still assigns responsibilities to providers and deployers rather than to a procurement category. A platform contract does not absorb the company’s obligations.

Test the platform on the work, not the presentation

I use the three workloads in the matrix: a frequent low-risk task, a process that crosses several tools and a sensitive action involving restricted data or explicit approval. Each one must reach a usable result.

Then the team revokes a permission, changes a source schema, switches a model, inspects the trace and simulates an integration failure. The time spent correcting those events tells us more than the polished path. This is where hidden operating cost and lock-in become visible.

The final test

If the vendor disappeared tomorrow, what would the company have to recreate? Replacing software is expected. Reconstructing the business rules, connector meanings, evaluation history and evidence behind past decisions means the company outsourced its ability to change.

Working references: MCP 2026-07-28 architecture, NIST AI RMF 1.0 and Regulation (EU) 2026/1744.