Native & Embedded: Classification Methodology
The Arion Enterprise AI Atlas | Version 1.0 | September 2026 | Arion Research
1. Purpose and Scope
The Arion Enterprise AI Atlas is a curated map of enterprise AI solutions organized around the Native & Embedded framework. This document defines the framework, the criteria used to classify every solution on the map, and the process for handling ambiguous cases. It is published so that classification decisions are transparent, contestable, and consistent across editions.
The Atlas maps products and solutions, not vendors. A single vendor can, and often will, appear in multiple cells and in both panels.
The category structure into which classified solutions are placed is defined in a companion document, the Category Taxonomy. This methodology governs how a solution is classified; the taxonomy governs where it lands, giving every category in both panels a boundary statement, in-scope and out-of-scope notes, and representative members. The two documents are published and maintained together.
2. The Framework
The framework recognizes two structural types of enterprise AI solutions and one deployment pattern.
AI Native. A solution whose core architecture and primary value depend on AI models. The model is not a feature of the product; it is the reason the product exists. Remove the models and the product either stops functioning or loses its reason to exist. AI Native solutions span the full stack, from compute infrastructure and foundation models through agent platforms to native applications.
AI Embedded. AI capability delivered inside a pre-existing enterprise software product or category. The host product predates its AI capability and functions without it. The AI augments established workflows, data, and user bases rather than defining the product. Examples of the pattern: an AI assistant inside a CRM suite, agents operating on an established workflow platform, generative features inside a collaboration suite.
AI Enhanced (a pattern, not a panel). AI Enhanced describes solutions and deployments created by composing AI Native tools with existing enterprise systems, typically on the buyer side or through integrators. Because AI Enhanced outcomes are built from the two mapped populations rather than existing as a separate vendor population, the Atlas does not map it as a panel. The methodology names it because the term is part of the original framework and describes how most enterprise value is realized in practice.
3. Unit of Analysis
The unit of analysis is the product or solution, defined as a distinctly named, separately adoptable offering. Suites are decomposed when their components are sold, deployed, or architected separately. This choice follows from the framework itself: classification tests examine architecture and value delivery, which are properties of products, not companies.
Consequences of this choice:
Large vendors appear multiple times. A hyperscaler's AI development platform can sit in the Native panel while its productivity copilot sits in the Embedded panel.
Company history does not determine classification. Founding date, funding era, and prior pivots are signals at most, never decisive.
The map stays honest as vendors converge. When an embedded suite vendor ships a separately architected native product, the product is classified on its own merits.
4. Classification Tests
Every solution is evaluated against five tests, applied in order. Test 1 is decisive when the answer is clear. Tests 2 through 5 resolve ambiguous cases by weight of evidence.
Test 1: Dependency (decisive). Does the product deliver its core value proposition if the AI models are removed? If no, the product is a Native candidate. If yes, it is an Embedded candidate. This is the heart of the framework: it asks what the product is, not what it advertises.
Test 2: Architecture. Where does the model sit in the execution path? In a Native product, models sit in the primary execution path of core workflows. In an Embedded product, models sit in an assistive or optional path alongside deterministic workflows that carry the core load.
Test 3: Origin. Was the product designed around model capabilities from its first release, or was AI added to a product that already existed? This is a supporting signal, not a decisive one. It guards against two errors: treating every startup as Native by default, and treating every established vendor as Embedded by default. An established vendor can ship a genuinely Native product; a startup can ship a conventional product with AI features.
Test 4: Commercial. Is AI capability the headline value proposition and the basis of pricing, or is it a feature, SKU, or add-on attached to an existing license? Follow the money: how a vendor charges reveals how it thinks about what it is selling.
Test 5: Interface. Is the primary interaction paradigm model-mediated (conversational, agentic, generative) or a conventional interface with AI assists? This is the weakest test, used only as a tiebreaker, because interface fashion changes faster than architecture.
Decision rule. A clear answer on Test 1 settles classification. When Test 1 is ambiguous, classify by the majority of Tests 2 through 5, and record the case as an edge case with written rationale and a confidence rating (see Section 7).
5. Edge Cases and Precedents
These recurring situations are resolved as follows. New precedents are added as the Atlas encounters them, so classification stays consistent across editions.
Pivots. Classify the current product architecture, not the company's history. A company founded in 2018 that rebuilt its product around models in 2024 is evaluated on the 2024 architecture.
Platform extensions. AI agents or assistants that ride on an established platform (workflow, CRM, ERP), inherit its data model, and are sold as extensions of it are Embedded, even when the AI capability is sophisticated. The test is whether the AI capability stands alone.
Agent control planes. A product whose whole purpose is to discover, register, secure, observe, govern, or orchestrate AI agents — especially across multiple vendors' agents — is Native, even when a suite vendor ships it and it runs on that vendor's platform. Test 1 is decisive: remove the AI agents and there is no underlying product left to govern, so the value depends entirely on AI. This is the line against the Platform extensions precedent above. A platform extension augments an established non-AI product (a CRM, an ITSM suite) that still delivers value without it; a control plane has no such host product beneath it. Being delivered on the vendor's platform, sold to existing customers, or presented in the host UI are Test 3 (origin) and distribution signals, not Test 1 dependency, and do not override it. Founding precedents: Salesforce Agent Fabric, Microsoft Agent 365, ServiceNow AI Control Tower, and Workday Agent System of Record are all Native (Model & Agent Gateways), each governing first- and third-party agents. Distinguish from agent build platforms that ride an iPaaS or suite (for example Boomi Agentstudio, Workato AIRO): those remain Embedded because their primary job is building agents within the host platform, not governing a multi-vendor agent estate. Agentic-level convention for control planes: score Level 1 when the product only registers, governs, or observes agents; score Level 2 when it also orchestrates, routes, or brokers agent actions. Because a control plane's cross-cutting governance, security, and observability value is not captured by a single map cell, it is also tagged on the demand-side lens under agent control-plane and lifecycle management, agent security and governance, and evals, observability, and AI governance, as applicable.
Acquired native products. A Native product acquired by a suite vendor stays Native while it remains separately sold and separately architected. When it is absorbed into the host suite as a feature, it moves to Embedded, and the change is recorded in the edition delta.
Data and analytics platforms. Platforms that predate the model era and have added substantial AI capability (lakehouse platforms, cloud data warehouses, BI suites) are Embedded: the host platform functions without the AI, and the AI capability rides the platform's data gravity. A separately adoptable AI infrastructure product from the same vendor is classified on its own merits.
Models inside applications. Using models internally does not make a product Native if the customer-facing value proposition survives without them. Nearly every enterprise product now touches a model somewhere; the framework classifies what the product delivers, not what its plumbing includes.
6. Attributes
Attributes describe capabilities that cut across the taxonomy. They are recorded per product and rendered as visual tags on the map, never as categories. The first release defines one primary attribute; others (deployment model, target segment) are stored in the database for analysis.
Agentic capability is scored on a four-level scale:
Level 0, None. No agentic capability. May still include generative or predictive AI.
Level 1, Assistive. Responds to prompts within a single turn or task: drafting, summarizing, answering. No multi-step execution.
Level 2, Agentic. Plans and executes multi-step work using tools, with human checkpoints. Operates under supervision within a bounded scope.
Level 3, Autonomous. Accepts goal-level delegation and executes with minimal supervision, including initiating work. Bounded by policy rather than by per-task approval.
Products at Level 2 or above carry the agentic tag on the map. The level itself is stored in the database and reported in category analyses. For agent control planes specifically, apply the Level 1 vs Level 2 convention in the Agent control planes precedent (Section 5).
7. Inclusion Criteria
The Atlas is curated. Inclusion reflects an editorial judgment that a solution matters to enterprise buyers, backed by the following bar. A product must meet all of the first four criteria:
Enterprise-grade. Sold to enterprises with a credible security, compliance, and administration posture. Consumer-only products are excluded.
Generally available. Shipping and adoptable today. Waitlist-only, private-beta-only, and announced-but-unshipped products are excluded.
Demonstrated traction. Evidence of real enterprise adoption: named customers, meaningful revenue or funding signals, or clear category presence.
Active. Shipped meaningful product updates within the trailing twelve months.
Exclusions: pure consulting and services firms, hardware-only offerings, and products in stealth. Systems integrators and service-led AI practices are acknowledged in the methodology as the primary builders of AI Enhanced deployments but are not mapped.
Target scale for the first edition is roughly 300 to 500 products. The constraint is deliberate: the Atlas's value is judgment, not census.
8. Governance and Process
Rationale and confidence. Every classification records a written rationale and a confidence rating (high, medium, low). Low-confidence classifications are flagged for re-review before each edition.
Evidence. Each product entry cites the public evidence used: documentation, pricing pages, architecture descriptions, customer references.
Re-review cadence. All entries are re-verified before each annual edition. Products involved in acquisitions, major re-architectures, or repositioning are re-reviewed when the event occurs.
Vendor challenges. Vendors may challenge a classification by providing evidence against the tests in Section 4. Challenges are decided against the published criteria, and the decision and reasoning are recorded. The criteria themselves change only between editions, with changes documented in the version history.
Deltas. Each edition publishes what changed: products added, removed, reclassified, or moved between categories, with reasons. The delta is a first-class output of the Atlas, not a footnote.
9. Version History
v1.0 (September 2026). First published, out-of-draft edition. Finalizes the definitions, five tests, edge-case precedents, agentic levels, inclusion criteria, and governance process, and incorporates the Agent control planes precedent and the control-plane agentic-level convention added during the September 2026 review.
v0.1.1 (September 2026). Added the Agent control planes edge-case precedent (Section 5): vendor-platform agent control planes that govern multi-vendor agent estates are Native (Model & Agent Gateways), distinguished from Embedded agent-build platforms, with a Level 1 vs Level 2 convention and demand-side tagging guidance.
v0.1 (August 2026). Initial draft of definitions, tests, edge-case precedents, agentic levels, inclusion criteria, and governance process. Companion Category Taxonomy published alongside.