AI commerce platform architecture: from conversation to transaction

An AI commerce platform is the system that turns a customer conversation into a transaction and a durable customer record. Describing it as “a chatbot with an LLM behind it” is not a simplification, it is a category error: the model is one layer of eight, and in most deployed systems it is not the layer that fails.

This guide sets out a reference architecture for the category — a model for reasoning about how these systems are put together and for comparing two of them honestly. It is deliberately abstract. It is not a description of any vendor’s production topology, including ours, and it deliberately avoids infrastructure specifics that would be of more use to an attacker than to a buyer.

Why a chatbot is not an AI commerce platform

The distinction is not model quality. It is whether the system can act, and whether it knows who it is acting for.

A chatbot maps inputs to pre-authored responses. It is a script with a text interface, and its failure mode is visible and honest: outside the script, it deflects. An AI commerce platform interprets the request, retrieves what it needs to answer correctly, takes a constrained action in a business system, and records the outcome against a customer identity that persists after the conversation ends.

Four differences matter operationally:

	Scripted chatbot	AI commerce platform
Handles the unscripted request	No — deflects or breaks	Yes, within its permitted scope
Source of truth for an answer	Whatever was written into the script	Retrieved per answer from catalogue, order, and policy systems
Can change something	Rarely, and brittlely	Yes, through a defined and constrained tool set
What persists after the chat	A transcript	A customer record, an action history, and an outcome

The plain-English version of this distinction, with the operational tests behind it, is covered in AI agents for commerce. The rest of this guide assumes it and looks at how a system that can do the right-hand column is actually assembled.

Reference architecture overview

Eight layers, each with one job. The value of separating them is that it makes failure diagnosable: when a commerce agent misbehaves, the cause is almost always a specific layer that is missing, collapsed into another one, or unowned.

The stack is drawn top-down because that is the order a customer turn travels. It is worth reading bottom-up once as well: layer 08 is what tells you whether layers 01–07 are earning their place, and it is the layer most often added last.

Layer 1 — Channels

The channel layer accepts and sends messages on the surfaces customers actually use, and normalises them into one internal representation so the layers above do not have to care which one a message arrived on.

Channels are not interchangeable, and pretending otherwise produces bad experiences. WhatsApp has message categories, template approval, and a service window that governs when a business may message first — the mechanics are covered in WhatsApp Business API: how it works. A web widget has none of those constraints and no persistent identity unless you give it one. Instagram sits somewhere between.

Two architectural decisions live here:

• Normalisation without flattening. The agent should reason about one conversation model, but channel-specific capabilities — interactive lists, catalogue messages, templates — must remain reachable rather than being reduced to plain text.
• Identity resolution at the boundary. Every channel supplies a different identifier. Turning that into a stable customer identity is layer 2’s job, but the channel layer is where the raw identifier is captured and where losing it becomes irreversible.

Layer 2 — Identity and customer context

This is the layer that separates a commerce agent from a support bot, and it is the one most commonly missing.

Conversation history is a transcript. A customer record is an identity that persists across conversations, channels, and time, and carries order history, preferences, consent state, and whatever the customer has told you before. An agent working from a transcript alone restarts at zero on every new thread — which is why a system can appear to work in a demo and fail in month two.

What belongs in this layer:

• A durable identifier and a resolution rule. In WhatsApp-first commerce the phone number is usually the key. What matters more than the choice is the rule for merging a web session, an order, and a chat into one person, and what happens when the rule is uncertain.
• Consent and messaging permission as first-class state. Whether you may send a marketing message is a property of the record, not a campaign setting.
• Structured context, not raw scrollback. What the customer said should become attributes the agent can retrieve cheaply — size, budget, intent, prior issue — rather than a growing transcript stuffed into every prompt.

The last point is also an economic one. Context assembled from a record is bounded and stable. Context assembled by concatenating history grows without limit, gets more expensive per turn, and gets less accurate as the relevant detail drifts further from the model’s attention.

Layer 3 — Knowledge and grounding

Grounding is the set of things the agent may treat as true, and where it goes to check. It is a separate layer from the model because the correctness of an answer is a property of the source, not of the generation.

The useful distinction here is between retrieval and memory. Retrieved knowledge is looked up at answer time from a system that owns it: current price, current stock, the actual return policy, this customer’s last order. Model memory is whatever the model absorbed in training or was told earlier in the conversation. Only the first is safe for anything a customer will act on, because only the first can be wrong in a way you can fix.

Practical consequences:

• Volatile facts must be retrieved per answer, never cached into a prompt. Price, stock, order status, and delivery estimates go stale between the moment a prompt is written and the moment a customer reads the reply.
• Policy content should be authored once and retrieved, not paraphrased into instructions. If the returns policy lives in three prompts, it will diverge in three directions.
• Grounding failure must be a distinguishable state. “I could not find this” has to be representable, or the system will fill the gap with fluent invention. This is the mechanism behind most confident wrong answers in commerce agents.

Guardrails belong adjacent to this layer: the rules about what the agent must never assert, discount, promise, or improvise. AI agent guardrails covers how to write them so they hold up.

Layer 4 — Agent reasoning and orchestration

This is the layer people mean when they say “the AI,” and it is the one that should be doing the least surprising work.

Its job per turn is narrow: interpret what the customer wants, decide whether that is answerable from retrieved knowledge or requires an action, select the action, check it against policy, execute or escalate, and compose a reply. Everything it needs to make that decision comes from layers 2 and 3; everything it is permitted to do is defined in layer 5.

Two design principles carry most of the weight:

• Deterministic where a rule exists, generative where judgement is needed. Whether a return is inside the window is arithmetic, not a judgement. Push it into a rule the agent invokes, and reserve generation for interpreting the request and explaining the answer. Every rule moved out of the model is one fewer thing that can be argued with by a customer who phrases the question cleverly.
• Confidence should route, not just annotate. A confidence signal that only decorates a log is decoration. It earns its place when low confidence deterministically changes behaviour — retrieve again, ask a clarifying question, or hand off.

The distinction between an agent’s confidence and a deterministic policy control is worth stating plainly, because vendors blur it: confidence is a probabilistic property of one answer, and a policy control is a rule that holds regardless of confidence. A system that has the first and not the second has no floor under it.

Layer 5 — Tools and business actions

Tools are the finite, named set of things the agent may do outside of talking: look up an order, check stock, create a cart, apply a permitted discount, create or update a customer record, schedule a follow-up, open a ticket.

Three properties separate a sound tool layer from a risky one:

• Enumerated, not open-ended. The agent chooses from a defined set. “It can call our API” is not an architecture; it is an unbounded permission.
• Permissioned per action, with a blast radius you can state. Read-only lookups and state-changing actions are different risk classes and should be governed differently. Anyone evaluating a platform should be able to get a straight answer to “what is the most consequential thing this agent can do without a human?”
• Auditable by default. Every invocation, its inputs, its result, and the conversation it belonged to. This is the input to layer 8 and the thing you will want at 2am.

The most common architectural mistake here is granting write access to keep a demo impressive, then discovering that nothing in the system distinguishes “the agent created this order” from “a person did.”

Layer 6 — Commerce

The commerce layer is what makes this a commerce platform rather than a well-integrated support desk: catalogue, cart, order creation, payment handoff, fulfilment status, and the post-purchase sequence.

The load-bearing architectural question is which system is the source of truth, and the honest answer is that there should be exactly one. For a merchant on an existing commerce platform, that platform holds catalogue, price, inventory, customers, and orders, and the conversational layer reads from it and writes orders back to it. For a merchant without one, the conversational platform has to supply that backbone itself. Both are legitimate; a system that is vague about which one it is doing will produce two divergent versions of the truth, and the customer will find the disagreement first.

Payment deserves a specific note. Handing off to a payment rail is a boundary worth keeping clean: the agent’s job ends at producing a correct, attributable payment request and resuming the conversation once the rail reports back. Architectures that try to hold payment state inside the conversation take on reconciliation problems that have nothing to do with AI.

Layer 7 — Human escalation

Escalation is a designed feature of the system, not evidence that it failed. Architecturally it needs three things, and most implementations ship one.

• Triggers that are explicit. Low grounding confidence, a requested action outside the permitted set, an explicit customer request, a detected complaint or vulnerability signal, and any policy exception. Written down, not emergent.
• Context that travels. The person picking up should see the conversation, what the agent retrieved, what it did, and why it stopped — without asking the customer to repeat anything. A handoff that loses context is worse than no automation, because the customer has now explained themselves twice.
• A defined return path. What happens after the person resolves it: does the agent resume, does the record get updated, does the case teach the knowledge base anything. Systems without this leak every escalation out of the loop.

Designing clean AI-to-human escalation covers the operational design of the seam in more depth.

Layer 8 — Evaluation and observability

Observability is not logging prompts. Logging prompts tells you what was said; observability tells you what was done, on what basis, and whether it was right.

A sound layer 8 answers four questions about any past conversation without a developer: what did the agent tell this customer, what did it retrieve to justify that, what actions did it take in which systems, and where and why did it escalate. And it answers one question about the system as a whole: is quality getting better or worse than last month.

That second question requires evaluation, which is distinct from analytics:

• Analytics counts what happened — volumes, resolution rates, escalation rates, conversion.
• Evaluation scores whether what happened was correct, against a fixed set of cases you re-run when anything changes: the prompt, the knowledge base, the model, the tool definitions.

Without a fixed evaluation set, every change is a guess, and quality drifts silently because nothing in the analytics distinguishes “fewer escalations because the agent got better” from “fewer escalations because it stopped recognising when it was stuck.” How to measure AI agent quality sets out which numbers are worth reporting and why deflection is not one of them.

Security and privacy considerations

Security in this architecture is not a layer; it is a property of the boundaries between layers. Four are worth naming at the level a buyer should ask about — the specifics of any given deployment belong in a vendor’s own documentation, not in a public reference model.

• Channel transport versus platform storage. End-to-end encryption protects a message in transit. It says nothing about what the receiving platform stores or who can access it. Those are separate questions with separate answers, and conflating them is the most common way a security claim gets overstated. Is the WhatsApp Business API secure? separates the two.
• Access boundaries around the customer record. Layer 2 is the highest-value data in the system. Who can read it, who can export it, and whether that access is reviewable are reasonable review questions for any vendor.
• The tool layer as a privilege boundary. Layer 5 is where an AI system gains the ability to change things. It should be the most constrained and most audited part of the architecture, not the least.
• Data flowing to model providers. Which content leaves the platform to be processed, and under what terms, is a legitimate question at review time.

How bitbybit approaches these operationally — including data export, access management, and incident response — is set out on our security and trust page.

Common architecture mistakes

Six failure patterns account for most of what goes wrong, and none of them is a model problem.

1. Grounding fused into the prompt. Catalogue and policy pasted into instructions instead of retrieved. Answers go stale the day a price changes and nobody notices for a month.
2. No customer record. Conversation history stands in for identity, so the agent cannot recognise a returning customer and the “personalisation” is limited to the current thread.
3. Unbounded tool access. The agent can call anything, so nobody can state what it is capable of doing wrong.
4. Escalation added after launch. Built reactively after a complaint, so triggers are implicit and context does not travel.
5. Logging mistaken for observability. Prompt logs exist; action history does not. Post-incident review takes a developer and a guess.
6. Two sources of truth for commerce. The conversational system and the commerce platform both believe they own inventory. The customer discovers the disagreement.

Build versus buy

The right answer depends on where your differentiation actually lives, and the honest framing is a cost-of-ownership one rather than a capability one — most of this is buildable.

Building makes sense when the agent’s behaviour is the product, or depends on proprietary logic a vendor cannot express; when you have engineering capacity to own channel integrations, grounding pipelines, evaluation, and on-call indefinitely; and when the commercial case survives that indefinitely, not just the first quarter.

Buying makes sense when you need the commercial outcome rather than the system, and your differentiation is catalogue, brand, price, and service quality; when channel and commerce integrations are undifferentiated work you would rather not maintain; and when the alternative is a project that ships in nine months instead of an outcome you can test next month.

The reliably underestimated cost of building is not the agent. It is layers 1 and 8: channel integrations that change under you, and the evaluation harness without which quality drifts invisibly.

An architecture checklist

Use this against your own design, or against a vendor’s. Each item is answerable in a sentence; vagueness on any of them is itself the finding.

1. Which channels are supported natively, and which channel-specific capabilities survive normalisation?
2. What is the durable customer identifier, and what is the merge rule when identity is ambiguous?
3. Is consent state held on the customer record and revocable?
4. Which facts are retrieved per answer, and which are baked into prompts?
5. Can the system represent “I could not find this” as a distinct state?
6. Which decisions are deterministic rules, and which are left to the model?
7. What is the complete list of actions the agent can take, and which of them change state?
8. What is the most consequential action the agent can take without a human?
9. Which system is the source of truth for catalogue, inventory, and orders?
10. What are the explicit escalation triggers, and what context travels with a handoff?
11. Can you reconstruct what the agent said, retrieved, and did for any past conversation?
12. Is there a fixed evaluation set that is re-run when the prompt, knowledge, or model changes?

How bitbybit approaches the category

For transparency about our own position: bitbybit is built around layer 2. The customer record is created at the first conversation rather than imported at checkout, and the same record serves support, marketing, and sales rather than each having its own. AI Studio is the agent engine, bitChat is the conversation surface, and bitCRM is the customer record; the agent skills — Product Recommendation, Create Order, Order Tracking, Data Collection, Follow-up, and Escalation — are the tool layer, enumerated rather than open-ended. For merchants on Shopify, Shopify stays the source of truth and the agent reads live catalogue, price, inventory, and order data and records agent-created orders back to it. For merchants without an existing commerce backbone, bitbybit Commerce supplies one. AI Studio keeps logs of what the agent said and did, and customer records, conversations, and tags can be exported in full.

That is one set of architectural choices, not the only defensible one. If you are comparing systems in this category, the AI commerce agent buyer checklist turns the layers above into questions you can put to any vendor, including us — and the Indonesia WhatsApp Commerce Report 2026 sets out the market argument these choices are a response to.