AI Architecture & Platforms

27 MIN READ

The Enterprise AI Vendor and Tool Landscape: How to Read It and Choose

AI vendor rankings sort by popularity, not architecture. This guide maps the Vendor and Tool Ecosystem by layer, lock-in risk, and format portability.

Every ranking of the enterprise AI vendor and tool ecosystem sorts the same forty-five names by popularity, not by where each one sits in your architecture. Popularity tells you nothing about which layer a product occupies, which layer it quietly locks you into, or whether it can talk to the agents you already run.

The Enterprise AI Vendor and Tool Ecosystem: Three Platform Patterns Read by Architecture Layer

The enterprise AI vendor and tool ecosystem is the set of vendors and tools that fill each layer of an AI architecture, compute, storage systems, Kubernetes, data, model serving, orchestration, monitoring and observability tools, security and developer tools, and reading it by layer rather than by brand is what turns a list into a map.

Aimultiple’s list of more than 45 MLOps tools, kai-waehner.de and vdf.ai all rank vendors by name and by publication year, not by which layer of the architecture a product actually fills. A reader who wants a shortlist gets a popularity contest instead: every name looks interchangeable because the list never says which vendors compete for the same slot and which ones stack on top of each other. Fix the layers first, and any vendor page you open afterward tells you something specific; which slot it fills, and which other names in the list are its real competitors.

Three patterns organize how the ecosystem actually stacks. Every vendor and open-source project in it belongs to one of them, whatever the ranking page calls it.

Cloud-Native Suite

A Cloud-Native Suite is a single hyperscaler’s integrated machine learning platform, AWS SageMaker, Azure ML or Google Vertex AI, that bundles data access, model training, serving and monitoring inside one cloud account and one billing relationship. The integration is the product: identity and access management, storage, and compute all come from the same provider, so a team can go from a notebook to a production endpoint without provisioning a separate service for logging, secrets or networking.

That bundling is also the cost. Every capability a Cloud-Native Suite adds, a new model registry feature, a managed vector index, a fine-tuning pipeline, ships wired to that provider’s identity system and billing meter. An organization that standardizes on one suite gets faster compliance alignment, because a single audit covers the whole stack, but every layer it adopts inside that suite adds to what it would need to re-platform if it left. The trade only becomes visible when a team tries to move a workload out, not when it moves one in.

Open-Source Stack

An Open-Source Stack replaces a vendor’s integrated platform with independently maintained components, MLflow for experiment tracking and model registry, Kubeflow for pipeline orchestration on Kubernetes, that a team assembles and operates itself. Nothing in the stack is licensed from a single vendor, so nothing in it can be discontinued, re-priced, or gated behind a new contract by one company’s product decision.

That independence has a cost the marketing copy for either pattern rarely states plainly: an Open-Source Stack requires the internal engineering capacity to integrate, upgrade and operate each component, work a Cloud-Native Suite does on the vendor’s side of the contract. Teams that choose this pattern are trading a subscription for headcount. The trade is not automatically the cheaper one: it is the one that keeps control inside the organization instead of inside a vendor’s roadmap.

MLflow for Experiment Tracking and Model Registry

MLflow tracks experiment parameters, metrics and artifacts across training runs and exposes a model registry that records which version of a model is staged, in production, or archived, independent of any cloud provider’s own registry. A team running MLflow self-hosted keeps that history even if it later changes which cloud runs the training jobs.

The registry matters more than the tracking once a model ships: it is the record an auditor or an incident responder consults to answer “which model version generated this output, and when did it get promoted.” A Cloud-Native Suite’s built-in registry answers the same question, but only for models that never leave that cloud; MLflow’s answer survives a migration.

Kubeflow for Pipeline Orchestration on Kubernetes

Kubeflow orchestrates multi-step machine learning pipelines, data preparation, training, evaluation, deployment, as Kubernetes-native workflows, so a pipeline that runs on one Kubernetes cluster runs the same way on any other cluster that meets the same specification. The orchestration logic lives in the pipeline definition, not in a vendor’s workflow engine.

That portability is the reason an Open-Source Stack is often anchored on Kubeflow rather than a cloud-native pipeline tool: a team that later needs to run the same training pipeline on-premises for a data residency requirement, or on a second cloud for redundancy, changes the cluster underneath the pipeline instead of rewriting the pipeline.

How Analysts and Researchers Score an Ecosystem

Two analyst methods and one academic finding define what “ecosystem” means when a vendor uses the word, and none of them treat it as a synonym for a large partner list. Forrester’s AI Platforms Landscape, Q1 2026, sorts AI platform vendors by size, market focus and the value they deliver, giving a reader a way to place a vendor before comparing it to a peer of a different size or focus. Gartner’s 2025 method for naming AI platform leaders, as VP analyst Anthony Bradley has explained it, scores vendors against six ecosystem-centric criteria that include technical capabilities, evidence from customer implementations, and the breadth of the vendor’s wider ecosystem: not the vendor’s own feature list alone.

The word “ecosystem” earns that weight because of what a 2020 study in Information and Software Technology on software ecosystem governance found: software companies can no longer compete through product excellence alone, because the ecosystem surrounding a platform, its partners, integrations and third-party tools, is responsible for a large part of that platform’s eventual success (Information and Software Technology, 2020). A platform with a thin product but a deep partner network can outcompete a platform with a stronger product and no ecosystem around it. That is why Gartner’s criteria score the ecosystem’s breadth as its own line item rather than folding it into “technical capabilities.”

Two industry reports supply the demand side of the same picture. Menlo Ventures’ 2025 report on the state of generative AI in the enterprise tracks where enterprise AI spending has concentrated as adoption has scaled past pilot projects. The Zscaler ThreatLabz 2025 enterprise AI report names which large language model vendors and ecosystems carry the resulting enterprise traffic; evidence a reader can use to sanity-check whether a vendor’s claimed customer base matches independently observed usage, rather than taking a vendor’s own case-study page at face value.

Pattern	Example vendors and tools	What it optimizes for	What it costs
Cloud-Native Suite	AWS SageMaker, Azure ML, Google Vertex AI	One identity, billing and compliance surface across the whole stack	Every added capability deepens the exit cost
Platform-Independent Product	Databricks, Domino, DataRobot, Weights & Biases, Comet	A single product layer that runs across more than one cloud	Still a vendor relationship, still a contract to exit
Open-Source Stack	MLflow, Kubeflow	No single vendor can gate, re-price or discontinue the stack	Internal engineering capacity to integrate and operate it

The Fourth Pattern: What Is a Platform-Independent Product?

A fourth name belongs in the middle row, not the first: a Platform-Independent Product such as Databricks, Domino, DataRobot, Weights & Biases or Comet sells a single product layer, usually experiment tracking, a unified data and AI platform, or model governance, designed to run across more than one cloud rather than bundled into one. It removes the single-cloud lock-in of a Cloud-Native Suite without removing the vendor relationship itself; the product can still be re-priced, and its own roadmap still decides what the platform supports next.

How to Read a Vendor’s Ecosystem Map: Open Layers, the Locked Layer and Model Format Portability

A vendor’s ecosystem map tells an architecture team which layers it can swap for a competitor and which layer the vendor keeps closed, once a reader knows how to read the open categories, the locked layer, and the model formats that decide exit cost.

Open Layers Versus the Locked Layer: NVIDIA’s Partner Map as the Worked Example

A vendor’s own partner-ecosystem page states, in its own structure, which layers it expects a customer to be able to swap and which layer it intends to keep. NVIDIA’s Enterprise AI Factory white paper is the clearest published example: it sorts ecosystem partners into five component categories, Enterprise Kubernetes, storage, observability, security and developer tools, while keeping the compute layer to itself.

The pattern is not an oversight; it is the map. Every category NVIDIA opens to a named partner is a category where NVIDIA expects a customer to be able to choose a different vendor without disrupting the rest of the stack. The one category it does not open, the compute layer, is where the lock-in lives, and NVIDIA’s own documentation says so implicitly by never listing a partner for it (NVIDIA Enterprise AI Factory). Vendor Lock-In, in other words, is not a claim you have to take on faith from an analyst report: it is legible directly from which layers a vendor lists partners for and which layer it does not.

That gives a reading rule that applies to any vendor’s partner or marketplace page, not only NVIDIA’s: the layers a vendor opens to partners are the layers it expects you to swap; the layer it keeps closed is where its lock-in lives. Apply that rule before reading a vendor’s feature list, and the feature list tells you something different: not what the product can do, but what you would be trading away to use it.

Five Categories Partners Fill

NVIDIA’s white paper names Enterprise Kubernetes, storage, observability, security and developer tools as the five categories where ecosystem partners supply components. Each category maps to a layer an enterprise architecture team already owns a decision for outside NVIDIA’s stack, which Kubernetes distribution, which storage backend, which observability suite, so NVIDIA’s own documentation is telling the reader those decisions stay theirs to make.

That matters for a shortlist because it means a partner listing in one of these five categories is evidence of interoperability, not evidence that NVIDIA’s platform requires that specific partner. A team already committed to a particular observability suite can check whether it appears in the partner list as a confirmation, not treat the absence of its preferred tool as a blocker to evaluate further.

The Compute Layer NVIDIA Keeps

The hardware layer, NVIDIA Blackwell GPUs, NVIDIA BlueField DPUs for infrastructure acceleration and security, and Spectrum-X Ethernet for networking, appears in the white paper as infrastructure design, never as a partner category with alternative vendors listed beside it. The accelerated computing platform that combines these components is described as delivering the latency and throughput real-time inference and agent workloads require, but the description never offers a substitute for any one piece.

That is the layer a shortlist team should treat as the actual purchase decision, because it is the one layer the vendor’s own ecosystem map does not let you negotiate around. Everything in the five open categories can be re-sourced later without renegotiating the core contract; the compute layer cannot.

Faster Compliance Alignment or Control Portability: The Trade the Enterprise Actually Makes

Two goals pull against each other whenever an organization chooses between a Cloud-Native Suite and an Open-Source Stack, and no vendor’s marketing resolves the tension because each pattern is better at one goal and worse at the other. A Cloud-Native Suite delivers faster compliance alignment, one identity system, one audit trail, one vendor’s compliance certifications covering the whole stack, but at a higher cost in Vendor Lock-In. An Open-Source Stack maximizes Control Portability but requires more internal capability to operate at the same reliability.

AI Advisory Practice’s portability criteria give the trade a checklist instead of leaving it as a feeling: whether the platform is open source, whether it uses interoperability standards such as MLflow, ONNX and Seldon rather than proprietary equivalents, its Data Export Completeness, whether every artifact a team created can leave with them, not just the final model file, and whether its APIs follow published standards rather than a proprietary schema.

Data Export Completeness is worth testing before signing, not after: ask a vendor for every artifact type their platform stores, training logs, feature definitions, evaluation results, prompt templates, fine-tuning datasets, and confirm each one exports in a format another platform can ingest. A platform that exports the model but not the surrounding artifacts has priced part of the exit cost into the product without stating it.

Model File Formats as Exit Cost: GGUF, Safetensors, PyTorch and ONNX

A model’s file format decides which serving platforms can run it without a conversion step, and four formats cover most of what an enterprise team will encounter: GGUF, Safetensors, PyTorch and ONNX. Xuan-Son Nguyen’s Hugging Face community write-up on common AI model formats lays out what each one is for and, more usefully, where the compatibility boundaries actually sit.

GGUF was built specifically for llama.cpp and is supported by llama.cpp, Ollama and vLLM: a format born inside one serving project that has since become a de facto standard for running language models efficiently on consumer and edge hardware. Safetensors is the format most model repositories now ship by default for safe, fast tensor storage, and PyTorch remains the format most models are actually developed in before conversion to something else for serving. ONNX exists as the cross-framework interchange format, letting a model trained in one framework run in a serving engine built for another.

The practical test for a shortlist is not which format a vendor’s platform prefers, every serving platform prefers something, but which formats it ingests and which formats it exports. A platform that only ingests its own proprietary format, and exports nothing else, has priced the exit for you before you have used it once; ask the question at proof-of-concept time, when switching costs nothing, rather than at renewal, when switching costs a migration.

Reading Trust, Flexibility and Vendor Lock-In as the Three Columns of Your Own Map

Kai Waehner’s Enterprise Agentic AI Landscape for the second quarter of 2026 names three axes for comparing agentic platforms, trust, flexibility and Vendor Lock-In, and those three words work as well as column headers on a reader’s own comparison sheet as they do in the published landscape itself.

Trust asks what evidence a vendor offers beyond its own claims: named enterprise customers, independent benchmark results, or academic evaluation rather than a case-study page written by the vendor’s own marketing team. Flexibility asks whether the platform’s architecture matches the open-layers pattern this article already established; does it name interoperability partners in the categories that should be swappable, the way NVIDIA’s white paper does for Kubernetes, storage and observability. Vendor Lock-In folds in both prior lessons at once: which layer stays closed, and what a Data Export Completeness check on that layer actually returns. A reader who fills in those three columns for every name on a landscape page has replaced the ranking with a comparison.

How Do You Verify a Partner Listing Is Real?

A name on a partner page is a claim, not proof of a working integration; a shortlist team should confirm the partner appears in a live marketplace listing with a current build, not just a logo in a slide deck, and ask the vendor for a reference customer running that specific integration in production.

Vendor Criteria for the Agent-Facing Layers: MCP Tool Access and Orchestration Protocols

Two criteria decide whether a vendor’s agent-facing layer actually works at scale: how much of its own API an MCP Server exposes to a connecting agent, and whether its orchestration engine speaks the protocols that let separate agents plan, enforce policy, and coordinate with agents built on a different vendor’s platform.

The Model Context Protocol (MCP) has become the standard interface through which LLM agents invoke external tools, but the first large-scale study of how vendors actually build MCP servers found most of them expose only a fraction of what their underlying API can do. Researchers Meriem Mastouri, Emna Ksontini, Amine Barrak and Wael Kessentini analyzed 116 official MCP servers and found 88.6% fully or partially backed by a REST API, with 92% implementing their tools as bare wrappers around that API rather than adding agent-specific behavior; the median server exposed just 19% of the operations available in its underlying specification REST API (Mastouri et al., 2025).

That census turns into a concrete question for every vendor on a shortlist: what share of your REST API does your MCP Server expose to agents, and does the wrapper add agent-oriented behavior, retries, structured error handling, permission scoping, or does it only pass operations through unchanged? A vendor that cannot answer the first half of that question with a number has likely never measured its own exposure, which is itself useful information about how mature its agent-facing layer actually is. A vendor whose MCP Server is a bare wrapper, per the study’s 92% figure, is passing its REST API’s own limitations, including whatever authorization gaps exist in the REST layer, straight through to the agent calling it.

Orchestration: Four Separable Functions and Two Protocols

An Orchestration Layer coordinating multiple AI agents decomposes into four functions that a mature platform keeps separable rather than fused into one monolithic control loop: Planning, Policy Enforcement, State Management and Quality Operations. Apoorva Adimulam, Rajesh Gupta and Sumit Kumar formalize this architecture and pair it with two complementary protocols: the Model Context Protocol, which standardizes how an agent reaches external tools and data, and Agent2Agent, which governs peer coordination, negotiation and delegation between agents themselves Model Context Protocol (Adimulam et al., 2026).

The evaluation question follows the architecture in two parts. First, can each of the four functions be replaced independently, can a team swap its Policy Enforcement engine without rewriting Planning, or add a new Quality Operations check without touching State Management, or does the vendor ship them as one inseparable module? Second, does the product speak both protocols, or only the one it happens to own? A vendor built around the Model Context Protocol alone can reach tools and data but has no native way to coordinate with agents built on a different platform; Agent2Agent is what makes that coordination possible without routing every interaction through a single vendor’s runtime.

The Four Orchestration Functions

Planning breaks a goal into an ordered sequence of steps and revises that sequence as intermediate results change the picture. Policy Enforcement checks each planned action against rules before it executes; what an agent is authorized to do, and for which tenant or user. State Management tracks what has already happened across a multi-turn or multi-agent interaction, so an agent does not repeat a completed step or lose context between calls. Quality Operations evaluates outputs against defined criteria before they reach a user or trigger a downstream action.

A platform that fuses these four into one component can still work, but it forces an all-or-nothing upgrade: improving Policy Enforcement means touching the same code that handles Planning, so a change made for compliance reasons risks breaking a planning behavior that had nothing to do with the policy update. Keeping the four separable is what lets a platform team patch one function without regression-testing the other three.

Model Context Protocol Versus Agent2Agent

The Model Context Protocol governs the vertical relationship between an agent and the tools or data it calls: the interface this article has already tested for exposure coverage. Agent2Agent governs the horizontal relationship between agents themselves: how one agent delegates a subtask to another, negotiates which agent should handle a request, and hands results back.

The distinction matters at shortlist time because the two protocols solve different integration problems, and a vendor that only implements one has only solved half of a multi-agent deployment. A platform with strong Model Context Protocol support but no Agent2Agent implementation can connect a single agent to many tools; it cannot let that agent delegate part of a task to a specialist agent running on a different vendor’s platform without a custom integration layer built outside the product.

Why the Two Criteria Measure Different Things

The MCP census and the orchestration architecture test two different points in the stack, and conflating them produces a misleading shortlist score. The MCP census measures reach through the integration layer; how much of a vendor’s own service an agent can actually touch once connected. The orchestration protocol test measures something upstream of that: whether an Agent Orchestration product can talk to agents and tools it does not own at all, independent of how complete any single vendor’s own API exposure happens to be.

A platform can score well on one and poorly on the other. A vendor whose MCP Server exposes 80% of its API has solved the exposure problem for its own service, but if that platform speaks only the Model Context Protocol and not Agent2Agent, it still cannot coordinate with an agent built on a competitor’s runtime. Score both, separately, rather than letting a strong result on one stand in for the other.

Where Tool Access and Protocol Coverage Sit in the Three-Tier Architecture

Tool access belongs to the integration tier of an agentic architecture: the layer where an agent reaches out to a specific vendor’s service through its MCP Server. Protocol coverage belongs to the orchestration tier: the layer that decides how multiple agents, potentially from multiple vendors, coordinate work. Keeping the two tiers distinct when evaluating a vendor prevents a common shortlist error: crediting an orchestration product for tool access it does not itself provide, or penalizing a tool vendor for an orchestration gap that belongs to a different product entirely.

Vendor Criteria for the Retrieval and Serving Layers: Isolation, Hybrid Indexes and Throughput on Your Workload Mix

Three criteria separate a retrieval and serving platform that only sounds capable from one that actually is: where it enforces tenant isolation, whether its index blends dense and sparse retrieval instead of forcing one method, and what throughput it delivers on your own workload rather than a vendor’s benchmark.

Retrieval Isolation: Where the Vendor Enforces Tenant Policy

Multitenant Isolation in a retrieval platform is not automatic, because retrieval systems rank documents by relevance, semantic similarity, keyword match or a hybrid of the two, not by authorization, which means a query from one tenant can surface another tenant’s confidential data simply because it scores highest on relevance alone. Francisco Javier Arceo and Varsha Prasad Narsing formalize this gap and propose a layered isolation architecture combining Policy-Aware Ingestion, Retrieval-Time Gating and Shared Inference, enforced through server-side agentic orchestration rather than left to whatever guardrails a client application happens to implement Policy-Aware Ingestion (Arceo and Narsing, 2026).

The retrieval isolation criterion this gives a shortlist is concrete: ask where the vendor enforces tenant policy; at ingestion, when data first enters the system; at retrieval time, when a query is scored; or only in the prompt, after retrieval has already happened. A vendor that enforces policy only in the prompt has already retrieved the wrong tenant’s data before any check runs: the leak happens before the guardrail does. Ask, too, whether that enforcement sits server-side, centralized where the platform controls it, or is left to each client application to implement correctly on its own; Arceo and Narsing’s architecture centralizes exactly these operations, tool execution authorization, state isolation, policy enforcement, on the server because distributing them to clients means every client has to get the isolation logic right independently.

Retrieval Accuracy: Native Hybrid Sparse-Plus-Dense Queries

Retrieval accuracy in a production RAG system depends less on which large language model sits downstream than on which retrieval method surfaces context for that model in the first place, and the strongest published evidence for this favors combining two retrieval strategies rather than choosing one. Kunal Sawarkar, Abhilasha Mangal and Shivam Raj Solanki’s Blended RAG method combines a Dense Vector Index with a Sparse Encoder Index under hybrid query strategies, setting new retrieval benchmarks on the NQ and TREC-COVID information retrieval datasets and surpassing fine-tuning performance on the SQuAD generative question-answering benchmark NQ and TREC-COVID (Sawarkar et al., 2024).

The retrieval accuracy criterion that follows: does the VectorDB or Retrieval-Augmented Generation (RAG) platform under evaluation support sparse-plus-dense hybrid queries natively, as a configuration option, or does its architecture force a single index type? A Dense Vector Index alone captures semantic similarity but misses exact keyword matches; product codes, error strings, named entities a user typed exactly. A Sparse Encoder Index alone captures those exact matches but misses paraphrase and semantic nuance. Blended RAG’s benchmark results held because the two methods cover each other’s blind spots; a platform that only offers one has a blind spot baked into its architecture, not just a configuration a team forgot to enable.

Serving Throughput: Named Mechanisms and Your Workload Mix, Not a Headline Multiplier

Inference serving vendors publish throughput multipliers that sound definitive and mean almost nothing outside the exact workload they were measured on. SGLang, built by Lianmin Zheng, Liangsheng Yin, Zhiqiang Xie and co-authors including Ion Stoica and Joseph E. Gonzalez, achieves up to 6.4 times higher throughput than prior state-of-the-art Inference Engines; but that figure was measured across a specific mix of tasks: agent control, logical reasoning, few-shot learning benchmarks, JSON decoding, RAG pipelines and multi-turn chat Inference Engines (Zheng et al., 2024).

The serving criterion this sets is a question about mechanism, not about the headline number: which of the mechanisms behind that result does the vendor’s platform actually implement, and what Token throughput and Request throughput does it reach on your own workload mix rather than on the benchmark suite a paper used? A vendor that cannot name its mechanisms, or that quotes SGLang’s 6.4x figure as if it applied to any workload, has not done the measurement work the criterion asks for.

RadixAttention and KV Cache Reuse

RadixAttention reuses the KV cache, the intermediate attention state a language model computes while processing a prompt, across requests that share a common prefix, instead of recomputing that state from scratch for every new request. Multi-turn conversations, agent workflows that repeat the same system prompt, and few-shot prompts that share a common set of examples all generate exactly this kind of shared prefix.

The mechanism matters most for workloads with high prefix overlap and matters far less for workloads where every request is unique; a serving vendor’s own throughput claim is only as relevant as how closely your traffic resembles the traffic pattern RadixAttention was designed to accelerate. Ask a vendor for a throughput number measured on a workload with your own ratio of repeated-prefix to unique requests, not the ratio in their benchmark suite.

Compressed Finite State Machines for Structured Decoding

Compressed Finite State Machines accelerate structured output decoding, generating JSON, function-call arguments, or any output that must conform to a fixed schema, by constraining which tokens the model can generate at each step to only those the schema permits, and doing so efficiently enough that the constraint itself adds negligible latency.

This mechanism matters specifically for agentic and tool-calling workloads, where nearly every model output needs to parse as valid structured data before an orchestration layer can act on it. A serving platform that implements Compressed Finite State Machines turns a source of retries and parsing failures, a model producing almost-valid JSON, into a much smaller failure surface, because the invalid token was never generated in the first place.

Embedding Model Portability: What Happens When You Change Models?

Switching an embedding model after a corpus is already indexed forces a full reindex, because vectors from two different models are not comparable to each other. Ask a vendor whether its platform supports reindexing a live corpus without downtime, and whether it lets a team run two embedding models side by side during a migration rather than taking retrieval offline until the reindex finishes.

How to Shortlist Vendors by Layer: Stakeholder-Weighted Criteria and the One Layer No Vendor Ships

Five steps turn the layer-by-layer criteria this article has already built into a shortlist an architecture team can hand to procurement, without repeating any of the tests already covered above.

Steps One and Two: Requirements by Stakeholder Group, Then the Non-Negotiables

A shortlist starts by naming who needs what, because AI Advisory Practice’s MLOps platform selection guide finds four distinct stakeholder groups pulling in different directions on the same purchase. Data scientists need usability, Experiment Tracking Tools and notebook integration. MLOps Engineers need CI/CD, serving and observability built to their operational standards. Governance and compliance teams need lineage, approval workflows, audit trails and Policy Enforcement they can point to during a review. Business stakeholders need outcome measurement and integration into the products the organization actually sells.

Step two turns those requirements into Weighted Scoring: document every requirement, weight it by business impact, then mark a subset as Non-Negotiables; requirements a vendor’s failure to meet removes them from consideration regardless of how well they score elsewhere. The controls that NIST AI RMF and ISO/IEC 42001 require, logging, traceability and documented risk mitigations, belong in that Non-Negotiables set rather than as scored preferences, because a governance or compliance stakeholder cannot trade a missing audit trail for a better user interface (NIST AI RMF 1.0). A vendor that cannot produce evidence against those two frameworks fails the Non-Negotiables check before Weighted Scoring ever runs.

Steps Three and Four: Criteria Rows and the Compound AI Blueprint as Matrix Skeleton

Step three fills in the rows of the comparison itself. One published RFP-style schema groups eleven criteria, experiment tracking, Model Registry, pipeline orchestration, Feature Store, model monitoring, data versioning, collaboration, CI/CD, infrastructure management, AutoML and scalability, under three headings: ML lifecycle coverage, technical fit and operational model. A second, CIOPages’ weighted criteria, emphasizes production monitoring, model registry and governance, deployment and serving, CI/CD, experiment tracking and LLMOps coverage, and specifically asks whether a candidate platform provides an Auditable Spine connecting serving, CI/CD, governance and LLMOps into one traceable chain rather than four disconnected tools.

Step four gives those rows a vendor-neutral skeleton instead of a vendor-authored one. Eser Kandogan and co-authors’ blueprint architecture for Compound AI Systems in the enterprise treats a “stream” as the key concept that coordinates data and instructions among agents and other components, with task planners and data planners breaking down, mapping and optimizing work against available agents and data sources Compound AI Systems (Kandogan et al., 2024). Use the blueprint’s components, not a vendor’s own product diagram, as the row headers of the matrix, then record which vendor products fill each row and which rows no vendor sells at all.

Blueprint component	Vendor products that fill it	Who owns the row
Model layer / foundation model hosting	AWS SageMaker, Azure ML, Google Vertex AI, Databricks	Cloud-native or platform-independent vendor
Experiment tracking and model registry	MLflow, Weights & Biases, Comet	Open-source stack or platform-independent vendor
Pipeline orchestration (task and data planners)	Kubeflow, Databricks	Open-source stack or platform-independent vendor
Retrieval and serving	Vendor-specific, test per the retrieval and serving criteria above	Varies; test before shortlisting
Enterprise data-semantics layer	No vendor product sells this row	The enterprise

Step Five: The Row the Enterprise Keeps, on LinkedIn’s Ablation Evidence

LinkedIn built an internal Text-to-SQL chatbot to let product managers, engineers and operations teams self-serve data insights from a large, dynamic data lake, and the team’s own ablation studies, removing one component at a time to measure its effect, found that the Enterprise Knowledge Graph (EKG) and the data-modeling components mattered most to the chatbot’s accuracy, not the underlying language model Enterprise Knowledge Graph (Chen et al., 2025).

That finding names the one row in the comparison matrix that stays empty on purpose. No vendor sells an organization’s own Enterprise Knowledge Graph (EKG), because it encodes that organization’s specific tables, product areas and historical query patterns: the exact material LinkedIn’s ablation identified as the accuracy driver. A shortlist that scores every other row against a vendor and leaves this one blank has not missed a step; it has correctly identified the one layer that stays internal no matter which vendors fill everything around it.

The output of these five steps is a by-layer shortlist: two or three vendor names per row, the Non-Negotiables recorded against each, ready to hand to a build-versus-buy decision and then to vendor due diligence. The shortlist evaluates vendors against the rows above: it is not a self-assessment of the reader’s own organization, and it does not become one.

Summary

Reading the enterprise AI vendor and tool ecosystem by architecture layer, instead of by brand ranking, is what turns a list of forty-five names into a set of decisions an architecture team can actually make and defend.

The Layer-First Read Replaces the Brand Ranking

A vendor name means little until it is placed against the three platform patterns, Cloud-Native Suite, Platform-Independent Product, Open-Source Stack, and against the specific layer it fills: compute, retrieval, serving, orchestration, agent-facing tool access, or the data-semantics layer no vendor sells at all. Once a name has a pattern and a layer, two vendors that looked identical on a ranking page often turn out not to compete for the same slot, and two that looked unrelated turn out to be direct alternatives.

The reading rule drawn from NVIDIA’s own partner map generalizes past that one example: any vendor’s partner or marketplace listing states, in its own structure, which layers it expects a customer to swap and which layer it intends to keep closed. Combine that with a Data Export Completeness check and the model-format question, which formats a platform ingests and which it exports, and Vendor Lock-In stops being a risk an organization discovers after signing and becomes a property it can test during a proof of concept, before a contract exists to renegotiate.

Where the Lock-In Actually Lives, and the One Row No Vendor Fills

The agent-facing and retrieval-and-serving criteria this guide built give that proof of concept its actual test questions, each anchored to a measured result rather than a vendor’s own claim: what share of a vendor’s API its MCP Server exposes, whether its orchestration product separates Planning, Policy Enforcement, State Management and Quality Operations and speaks both the Model Context Protocol and Agent2Agent, where it enforces Multitenant Isolation, whether its retrieval index blends dense and sparse methods, and what throughput mechanisms it implements against your own workload mix rather than a benchmark suite’s.

Every one of those tests produces a row a vendor can fill, score against, or fail. The Enterprise Knowledge Graph (EKG) row cannot be filled by any vendor, because LinkedIn’s own ablation evidence found that the organization-specific data-semantics layer, not the language model sitting on top of it, is what accuracy actually depended on. A shortlist built on the criteria above tells an architecture team exactly which rows to negotiate over and which one row stays theirs to build, no matter which vendors fill everything around it.

Anonymous. Counted, not tracked.

Where is your organisation with this right now?

What is the hardest part where you are?

agility at scale