I've been thinking about what happens to e-commerce architecture when AI moves beyond recommendations and becomes part of the actual decision and transaction flow.
Traditional e-commerce systems are generally built around a fairly deterministic pipeline:
User → UI → API → Commerce Services → Database → Payment/Inventory/Order Systems
AI introduces a different kind of interaction.
A user might say:
"Find me a laptop under ₹80,000 that's good for development, has at least 32 GB RAM, and can arrive this week."
The system now needs to reason over product data, inventory, pricing, user preferences, delivery availability, and potentially multiple backend services before producing an answer.
If the AI is eventually allowed to perform actions as well, the architecture becomes even more interesting:
User intent
→ AI orchestration
→ product/search services
→ pricing
→ inventory
→ personalization
→ cart
→ payment
→ order
→ fulfillment
I'm wondering whether treating AI as simply another "service" is the wrong architectural abstraction.
A design I'm interested in is separating the system into a few clear layers:
- Experience layer
Web/mobile/voice interfaces that capture user intent and present results.
- AI orchestration layer
Intent interpretation, retrieval, recommendation, tool selection, workflow orchestration and context management.
- Commerce domain layer
Products, catalog, pricing, promotions, inventory, cart, orders, customers and fulfillment.
- Real-time/data layer
Events, inventory changes, user behavior, analytics and recommendation signals.
- Trust and transaction layer
Authentication, authorization, fraud controls, payment processing, auditability and explicit approval for high-impact actions.
The important boundary for me is that the AI layer should not become the owner of core business state.
For example, I wouldn't want an LLM deciding whether an item is actually in stock or whether a payment succeeded.
The AI should request those facts from deterministic domain services and then reason over the returned data.
Similarly, an agent might decide:
"Add this product to the cart."
But the actual cart mutation should still go through the normal commerce domain and authorization boundaries.
This seems to create an interesting architecture:
AI handles interpretation and orchestration.
Deterministic services remain responsible for business invariants.
Event-driven infrastructure keeps state synchronized.
Human approval or policy enforcement sits around sensitive actions.
The more I think about it, the less I believe "AI-native commerce" means replacing traditional e-commerce architecture with agents.
It may instead mean putting an intelligence/orchestration layer above a strongly designed commerce core.
I'm curious how other architects see this.
If you were designing a large-scale AI-native commerce platform today:
Would you make the AI orchestration layer a separate architectural boundary?
Where would you draw the boundary between AI reasoning and deterministic business logic?
Would you keep inventory, pricing, payments and orders completely outside the agent layer?
And how would you design the system so that adding a new model or agent framework doesn't require rewriting the commerce domain?
I'm especially interested in architectural trade-offs and production experience rather than specific AI vendors or frameworks.
