Architecting Agentic Commerce on Adobe Commerce

Agentic systems don’t live inside Magento. They wrap around it.

Most teams get this backwards. They look at their Adobe Commerce installation and ask, “Where do I plug in the AI?” That’s the wrong question. Agentic systems require an architecture that Magento was never designed to host.

Why This Pattern Keeps Failing

Adobe Commerce is a transaction engine. It stores catalogs, manages carts, processes orders, and runs checkout. It does this well — and has done it well for over a decade.

But agentic systems need something fundamentally different: persistent memory across sessions, reasoning over behavioral signals, autonomous decision-making, and the ability to act across multiple systems simultaneously.

Trying to build that inside Magento creates a familiar trap: observer chains that run inference calls, plugins that hit external APIs synchronously, cron jobs pretending to be orchestration layers. You end up with a fragile system that slows down checkout and breaks on upgrades.

The architecture has to invert. Magento becomes a data source and action target — not the orchestration layer.

What “Agentic” Actually Means in a Commerce Context

Before architecting anything, the distinction matters.

An AI feature is a point enhancement: personalized product recommendations, smart search, predictive chat responses. It plugs in. It helps. It doesn’t make autonomous decisions across sessions and systems.

An agentic system maintains context, pursues goals across time, takes actions on behalf of users, and adapts its behavior based on outcomes. It’s a decision layer that sits above individual interactions.

In commerce terms:

• An AI feature suggests “customers also bought.”
• An agentic system notices a B2B buyer’s weekly replenishment pattern, pre-stages a requisition list, and alerts their procurement manager when inventory drops below their usual order volume.

The difference is not complexity. It’s architectural scope.

Where Agentic Systems Connect to Commerce

Agentic systems are external orchestrators with deep API integration into your commerce platform. They don’t run inside it.

The integration model looks like this:

Customer/User Layer
        ↓
Agentic Orchestrator  ← Context Store (session memory, behavior history)
        ↓
  AI Services Layer   ← LLM inference, recommenders, scoring models
        ↓
Middleware / API Layer
        ↓
Adobe Commerce / Shopify  ← Source of truth for catalog, orders, pricing

Every agentic capability you want to build flows through this stack — not inside the commerce layer.

On Adobe Commerce

Adobe Commerce’s API surface is actually well-suited for agentic integration, if you use it correctly.

What the agent reads from Magento:

• Customer order history (REST /V1/orders, /V1/customers)
• Product catalog with attributes and pricing (REST or GraphQL)
• Cart state in real time (GraphQL cart queries)
• Customer segment and group data
• Quote data for B2B flows

What the agent writes back to Magento:

• Cart modifications (add/remove items, apply coupon rules)
• Customer attribute updates (AI-inferred preferences, segment scores)
• Quote creation and pre-population for B2B buyers
• Custom customer segment assignment

The critical rule: the agent never runs inside PHP. It calls Magento through APIs. Synchronous plugins and observers are not agentic integration points — they’re bottlenecks.

Where Adobe Commerce falls short:

Real-time event streaming is weak. Magento’s message queue system (RabbitMQ/Amazon MQ) is built for internal operations, not external event consumption by AI systems. There are no native webhooks for granular frontend signals — a user hovering on a product for 8 seconds, abandoning a search query, comparing two SKUs. You need a separate frontend event layer.

Checkout is also a synchronous flow. Injecting real-time inference into checkout creates latency you cannot afford on your conversion funnel.

Practical pattern: Pre-compute agent decisions asynchronously. Don’t ask the AI what to recommend at checkout time. Run the agent on user behavior between sessions, cache the outputs, and read from cache when the session starts. The experience feels real-time. The inference isn’t.

On Shopify

Shopify’s architecture is more constrained than Adobe Commerce — and that constraint turns out to be a feature for agentic integration.

Shopify’s model forces everything external. There is no “inside Shopify” for custom business logic. App extensions, webhooks, and Storefront API are your only integration surface. That maps naturally to the external orchestrator pattern that agentic systems require.

Agentic integration points on Shopify:

• Storefront API — read catalog, cart, customer context in real time
• Admin API — write decisions back: metafields, discounts, product recommendations surfaced via custom sections
• Webhooks — react to order events, customer creation, checkout abandonment
• Shopify Functions — edge-executed logic for discounts and delivery customization (stateless, fast, but limited in scope)
• Hydrogen/Vite — custom storefront gives you full control over the experience layer where agents surface decisions

The agent architecture looks similar to Adobe Commerce, but the coupling is cleaner by default. Shopify enforces the boundary you have to enforce manually in Magento.

Where Shopify’s constraints bite:

Shopify Functions are sandboxed and stateless. Complex reasoning doesn’t belong there. API rate limits are strict — high-volume agentic systems need aggressive caching and request batching. Metafields are the primary mechanism for persisting agent-computed state per customer. Workable, but you’re working around the platform rather than with it.

Use Cases That Actually Deliver

Not every agentic idea is worth building. Two that generate measurable ROI on both platforms:

Intelligent bundling: The agent analyzes purchase history and product co-occurrence to pre-compute personalized bundle offers per customer segment. It updates these nightly (or near real-time for high-traffic shops). At session start, the frontend reads agent-computed recommendations from cache. No synchronous inference in the checkout path.

On Adobe Commerce, store bundle recommendations in customer attributes or a Redis cache keyed by customer ID. On Shopify, write to customer metafields or use an App-hosted recommendation endpoint that the storefront queries on load.

Dynamic checkout flow modification for B2B: The agent detects that an account is approaching their credit limit, or that a product in the cart is backordered past the buyer’s stated lead time. It surfaces a friction point before checkout, not after the order is placed.

This requires: an event stream from the storefront, agent evaluation logic running asynchronously, and a write-back mechanism to surface warnings in the cart — without blocking the checkout flow. The agent is advisory. The platform executes.

What You Actually Need to Build This

No sales pitch. A readiness checklist.

Infrastructure you need:

• Event pipeline: Kafka, RabbitMQ, or cloud pub/sub for behavioral signals from the frontend
• Context store: Redis or a vector database for user and session state across visits
• Inference layer: self-hosted or API-based LLM plus retrieval infrastructure
• Caching layer: pre-computed decisions with TTL management

API and data requirements:

• Full API access to your commerce platform (Magento REST/GraphQL, Shopify Storefront/Admin)
• Behavioral event stream from the frontend — server-side events alone are not enough
• Historical order and session data (90 days minimum for meaningful pattern signals)

Team skills you need now:

• Backend engineers comfortable with async systems and message queues
• API integration experience — not plugin development
• ML/AI engineering capability, or a managed inference service to abstract it
• A product owner who can define what “a good decision” looks like for your business

Without that last person, the agent has no goal and no way to measure success.

What to skip in the first iteration:

• Custom-trained models. Start with a capable foundation model plus retrieval augmentation.
• Real-time inference in hot conversion paths. Pre-compute everything you can.
• Deep Magento customization. The agent works around Magento, not inside it.

Decision Framework

Build the agentic layer when:

• You have meaningful behavioral data (100K+ sessions per month minimum)
• Your team can maintain an external service without it becoming abandoned middleware
• The use case maps to a measurable outcome: conversion lift, AOV increase, support ticket reduction
• Your platform’s API surface covers what the agent needs to read and write

Don’t build it when:

• Your catalog and order data are incomplete or unreliable
• You have no event stream from the frontend
• The “agentic” use case is really just a better recommendation widget
• You lack engineering capacity to maintain an additional service

The Adobe Commerce-specific red flag: If your plan involves extending Magento PHP classes to add AI decision logic, the architecture is wrong. Stop and redesign before writing a line of code.

The Leadership Angle

The cost of getting this right is real: a separate orchestration service, infrastructure for context storage and inference, and engineering time to build API integration in both directions.

The cost of getting it wrong is higher: AI logic embedded in observers and plugins that degrades page performance, breaks on upgrades, and cannot be isolated, replaced, or measured independently.

The team conversation worth having is not “how do we add AI to Magento?” It’s “what does the agent actually decide, and how do we measure whether those decisions are improving business outcomes?” That question is harder than the architecture question. It determines whether you’re building something that earns its maintenance cost.

Agentic systems require a product owner who thinks in outcomes, not a backlog of AI features. Architecture follows from that clarity.

Conclusion

Agentic commerce on Adobe Commerce is achievable today. The architecture is not exotic: external orchestrator, API integration with the platform, pre-computed decisions surfaced at the right moment in the user journey.

The hard part is not the AI layer. It’s the discipline to keep the agent outside the platform and design integration points stable enough to evolve as the models improve.

Magento gives you the data and the action surface. The agent provides the intelligence layer. Keep those concerns separate and you build something maintainable. Blend them, and you’ve built yourself a very expensive observer chain that no one will want to touch in twelve months.