This article is written for architects, engineering leads, and the technical decision-makers responsible for designing the systems underneath AI commerce. It assumes familiarity with B2B commerce platforms, integration patterns, and data architecture.
AI in B2B commerce is often discussed at the feature level. Recommendation engines, conversational interfaces, agentic assistants. The features are the visible part. The architecture underneath is what decides whether the features deliver value in production or quietly fail at scale.
A reference architecture for AI-capable B2B commerce has six layers. Each one is a distinct concern with its own integration patterns, data contracts, and failure modes. The layers stack from the foundational data sources upward to the AI features themselves. The argument throughout is consistent with our broader AI-ready commerce thesis: the AI is rarely the bottleneck. The architecture underneath almost always is.
Layer 1: Systems of record
At the bottom of the architecture are the canonical data sources. ERP for products, pricing, inventory, customer accounts, and orders. PIM for product attributes and content. CRM for customer relationships and pipeline. OMS for fulfillment state. WMS for warehouse operations. Tax engines, payment processors, identity providers, and the rest of the supporting cast.
Two architectural decisions at this layer determine almost everything downstream. First, system of record per data domain has to be explicit. Products in PIM. Pricing in ERP. Customer relationships in CRM. Inventory in OMS or ERP depending on the architecture. Without explicit system-of-record assignment, data drift between systems becomes inevitable, and AI features inherit whichever system happens to be queried at the moment.
Second, data contracts between systems have to be versioned and observable. Schema changes in any system of record propagate to every downstream consumer. Without versioned contracts, a single ERP schema change can break integrations silently. Without observability, the breakage is discovered months later.
Layer 2: Integration and orchestration
Above the systems of record sits the integration layer. For enterprise B2B commerce, this is typically an iPaaS platform like Boomi orchestrating event-driven flows between systems. The architectural pattern that works at scale has four properties. Event-driven rather than batch where latency matters. Defined direction per data domain. Transformation in transit rather than in custom code on either endpoint. Observable, with retries, dead-letter queues, and audit trails. We have detailed this six-domain integration playbook separately.
The integration layer is where AI commerce projects most often fail in production. The reason is consistent. AI features assume freshness. Most enterprise integrations are not designed for freshness. The mismatch surfaces six months in, when the AI starts returning answers grounded in stale data, and no one can pinpoint why because the integration layer was never instrumented to make latency visible.
Layer 3: Unified data and identity
Between the integration layer and the commerce platform sits a unified data and identity layer. Customer Data Platform or Master Data Management for customer records. A unified product data layer for catalog. Identity provider for authentication and authorization. The purpose is to consolidate the views of customers, products, and entitlements that AI features need to reason over.
In B2B, the customer identity model is more complex than in consumer commerce. Accounts are hierarchical. Parent companies contain entities. Entities contain users. Users have different permissions, approval thresholds, and contract scopes. The unified data layer has to preserve those relationships and make them queryable in real time. Without this, account-aware AI features become either superficial or wrong.
Two architectural patterns are common at this layer. The first is a federated approach, where the unified view is computed at query time from underlying systems. Lower data duplication, higher query latency. The second is a materialized approach, where a CDP or MDM maintains a synchronized copy that AI features query directly. Higher data duplication, lower latency. The right choice depends on the AI feature’s latency requirements and the integration layer’s ability to keep the materialized view fresh.
Layer 4: The commerce platform
Above the unified data layer sits the commerce platform. Shopify Plus, Adobe Commerce, BigCommerce, Spryker, VTEX, or another. The platform handles transactions, renders the storefront, and provides the integration surface for AI features to interact with the buyer.
The architectural question at this layer is not which platform to choose. It is how the platform interacts with everything above and below it. Pricing logic should not live in the platform. It should be retrieved from ERP at query time. Product master should not live in the platform. It should be sourced from PIM. Customer records should not live in the platform alone. They should reflect the unified identity layer. The platform is the storefront and the transaction engine. It is not the system of record for anything strategic.
When the platform becomes the de facto master for any data domain, every other architectural decision gets harder. Migrations become impossible without rebuilding. AI features become locked to a specific platform vendor. Substrate decisions become entangled with platform-specific implementation details.
Layer 5: AI services and orchestration
Above the commerce platform sits the AI service layer. This is where the AI models, agents, retrieval systems, and orchestration patterns live. The layer is typically composed of multiple specialized services. A recommendation service. A conversational AI service. A search and retrieval service. An agentic orchestration service. Each one is a separate concern with its own data dependencies, latency requirements, and observability needs.
Three architectural patterns matter at this layer. First, AI services should be decoupled from the commerce platform through clean APIs, not embedded as platform plugins. Plugins create lock-in and make AI service substitution difficult as the AI landscape evolves. Second, retrieval-augmented generation patterns should be the default for any AI feature that needs to ground answers in real-time commerce data. Embedding RAG patterns at the architectural level prevents the temptation to use raw model output, which produces hallucinations. Third, AI services should be observable. Every model call, retrieval, and decision should be logged with sufficient detail to reconstruct what happened when something goes wrong.
Agentic patterns in particular require careful architectural treatment. Agents that can take action on behalf of buyers need explicit boundaries, observable decision-making, and human-in-the-loop checkpoints for high-stakes decisions. We have written separately about what works and what does not in agentic commerce for B2B.
Layer 6: Experience and presentation
At the top of the stack is the experience layer. This is where AI features show up to buyers. Chat interfaces, recommendation modules, AI-powered search results, predictive reorder prompts, and agentic assistants embedded in the buying flow.
The architectural concern at this layer is consistency and trust. Buyers need to know when they are interacting with AI and when they are interacting with deterministic logic. They need to know what the AI can do and what it cannot. They need to be able to escalate to a human reliably when the AI cannot help. These are not just UX concerns. They are architectural requirements that should be encoded into how AI features are surfaced.
Cross-cutting concerns
Three concerns cut across all six layers and are worth separate architectural attention.
Observability. Every layer has to be instrumented. Latency, error rates, decision logs, retrieval results, and substrate health metrics all need to be visible in production. Without observability, debugging AI failures becomes archaeology.
Governance. AI decisions need audit trails. Sensitive data flows need access controls. Compliance requirements vary by industry, but the architectural pattern is consistent. Every AI feature should have a controllable answer to where its inputs came from, why it produced its output, and how that output can be overridden.
Substrate health monitoring. The integration layer, the unified data layer, and the systems of record all need to be continuously assessed against the conditions AI features depend on. Data freshness, attribute completeness, record consistency, schema stability. When substrate health degrades, AI feature performance follows. Catching the degradation early is the difference between proactive maintenance and reactive crisis management.
Where this architecture comes from
The six-layer pattern above is not a theoretical model. It is the architectural shape we have arrived at across enterprise B2B commerce implementations over the past three years, refined by what has worked in production and what has broken. The specific technologies vary across engagements. The architectural shape does not. For technical teams assessing their current architecture against this pattern, the eCommerce technology assessment we run includes a layer-by-layer architectural review and gap analysis.
AI in B2B commerce is an architectural problem before it is an AI problem. The teams that recognize this build foundations that compound. The teams that treat AI as a feature integration discover the architectural debt the hard way.
FAQs
Q: What is the right architecture for AI-powered B2B commerce?
A: A six-layer reference architecture works well across enterprise B2B implementations. From the bottom up: systems of record (ERP, PIM, CRM, OMS) with explicit system-of-record assignment per data domain; an integration and orchestration layer (typically iPaaS-based) with event-driven flows and observability; a unified data and identity layer (CDP or MDM) that consolidates customer and product views; the commerce platform itself, treated as transaction engine rather than data master; an AI service layer decoupled through clean APIs with RAG patterns by default; and an experience layer that surfaces AI features with appropriate transparency and escalation paths. Cross-cutting concerns include observability, governance, and substrate health monitoring.
Q: Should AI services be embedded in the commerce platform or run separately?
A: Separately, through clean APIs. Embedding AI services as platform plugins creates vendor lock-in and makes AI service substitution difficult as the AI landscape evolves rapidly. Decoupled AI services can be swapped, augmented, or replaced without touching the commerce platform itself. The architectural cost is slightly higher integration complexity at the start. The benefit is significantly more flexibility as the AI tooling landscape continues to mature over the next 24 to 36 months.
Q: What is the most common architectural mistake in AI commerce implementations?
A: Letting the commerce platform become the de facto master for data domains that should live elsewhere. Pricing logic embedded in storefront code rather than retrieved from ERP. Product master maintained in the platform rather than in PIM. Customer records that drift between CRM, ERP, and the platform. When the platform becomes the master, AI features get locked to platform-specific implementations, future migrations become significantly harder, and substrate decisions get entangled with platform vendor choices. The architectural discipline is to keep the platform as transaction engine and storefront, not as system of record.