Agentic commerce starts with your product data and permissions

A reseller gets in touch and asks whether your customer portal can accept an order that an AI service has prepared. The customer has already pasted an item number into a chat and wants the right contract price, the right stock status and an order that lands in the business system.

You have a product website, a customer portal and a business system. What matters is which data an agent is allowed to read, and which call it is allowed to make when someone needs to pay.

Agentic commerce starts with permissions and data sources. The chat itself comes later.

What agentic commerce means in practice

Agentic commerce is buying where a software agent interprets a need, searches and compares options and can carry out parts of the purchase. The customer or your company sets the task and the rules.

A chatbot answers a question. An agent carries out a task. It can find a spare part for a specific machine, check that the part fits and prepare the order at the customer's contract price.

Think of a purchasing manager who gives an assistant a list of requirements, a budget and a spending limit. The assistant does the work. No purchase happens outside those limits.

The industry has no shared definition. Different players use the term both for a recommendation and for a full payment. The agent can use permitted information such as previous searches, purchase history and account data, and make decisions within the limits it has been given.

Three levels are enough when you need to make decisions. At the first level, the agent suggests a product. At the second, the agent prepares a purchase that a person approves. At the third, the agent completes the purchase itself, within the amount, range and permissions you have set.

The rest of this post covers which parts of the business are affected. You will also see which decisions need to be made before anything is built.

How the customer journey changes when an agent buys

The main flow has five steps. The customer does one thing today. The agent does something else. The company has to be able to provide a specific kind of data, or the agent guesses.

The agent reads what is in your data. A polished product page helps a person. It is rarely enough when an agent needs to choose an item.

Say a maintenance manager types an open question about a pump in factory two. The agent has to find the right item through attributes, compatibility and documents. If the flow rate, the connection or the model the pump is fitted to is missing, the match becomes a guess.

The comparison needs the same thing in machine-readable form. Specifications that only sit in a PDF nobody has structured cannot be reliably matched against the customer's requirements.

Price is a step of its own. The customer logs in and sees their agreement. The agent has to fetch the price for exactly that customer segment, through a stable API. A price list that applies to everyone gives a contract customer the wrong quote.

At checkout, the customer fills in the form and approves. The agent may place the order within set limits, and only after an authenticated call. Many agents stop at a finished order that a person approves. For purchases under an agreement, that is often a reasonable way of working.

The step after the purchase is often forgotten. The customer asks about delivery status, returns and invoices. The agent needs order data it can read, or it will make up an answer.

The five steps are a main flow. A company with few customers and simple products can have a shorter route, with price and purchase in the same step.

Where agentic commerce already shows up in commerce

Product search through AI services is already a way in to your products. First, product data decides whether you appear in the answer. Then permissions decide what the agent is allowed to do.

Four situations already show up in commerce, and each one places its own demands on data and authority.

In a simple catalogue purchase, the agent compares products by dimensions, material and price. It needs attributes that can be filtered and a price that is current when the question is asked.

When reordering consumables, the agent uses customer-specific prices, minimum orders and delivery terms. If the minimum order quantity is missing, the agent can suggest a line that the business system later rejects.

In a spare parts portal, compatibility is decisive. The right part has to be identified from the model and serial number. Attributes for fit, replacement items and documents need to sit on the item, with the same permissions the customer has in the portal.

In support, the agent fetches order status and documents. The order, delivery note and invoice must be readable with the customer's permissions. Otherwise the answer becomes a guess.

What the situations have in common is that the agent's reach is set by what it may read and what it may write. A chat interface can be simple. The authority lies in pricing logic, attributes, order data and roles.

Why headless and composable platforms decide the agent's reach

Headless means the customer interface is separate from the commerce engine. The two talk through APIs. The same product data, pricing and order flow can then be used by the website, customer portal, app and an agent.

Composable architecture goes one step further. Product search, quote flow and order flow are separate building blocks. Each building block can be exposed on its own.

A website where product information only exists as HTML is hard for an agent to read reliably. The text can change order, and a campaign block can look like a specification. A stable API gives the same answer every time, with the same field names.

Ownership decides whether the answer can be trusted.

PIM owns copy, attributes, documents and relationships between items. How that information is modelled is described on the page about product information. The agent may read it during discovery and comparison. It may not invent an attribute that is missing from the source.

The business system owns price, stock, customer agreements and orders. The connections for those flows are described under integrations with the business system. A price fetched from a copy in the web system can give the wrong contract price in the agent's answer. The copy may be a day old, or apply to the wrong customer group.

The website or customer portal owns login, roles and permissions. The agent should work in an authenticated session for that specific customer. A general role sees ranges and prices the customer should not see.

The order call is a decision of its own. It runs after approval, once, with an idempotency key. A repeated call with the same key should return the same order.

Those boundaries are what the architecture depends on.

Who is responsible when an agent places an order

Sweden's central bank, Riksbanken, describes how AI agents can be given the right to make payments according to rules or preferences, without the consumer approving each transaction. At the same time, Riksbanken warns that users may not understand which powers they have handed over, and that the agent may carry out incorrect or unwanted transactions.

For purchases under an agreement, the agent has to follow the customer's purchasing policy. It should check spending limits, approval, credit terms, agreements and who is allowed to place orders.

An audit trail can look like this. The agent suggests an order based on the customer's task. The system checks the contract price, stock and permissions in the business system and the customer account. Amounts below the limit go through. Amounts above the limit require approval from a person. The order call is made once with an idempotency key, so a repeated call does not create a duplicate. Every step is logged.

The log matters as much as the function. When an order goes wrong, you need to be able to show what the agent read, which price applied and who approved it. Without that chain, a complaint becomes one word against another. How an order should move from the portal to the business system is described in order management in e-commerce.

The agent you can stand behind is the one that can show why an order was allowed, stopped or escalated. How autonomous the agent is otherwise is a separate question.

What this approach requires and when you should wait

Four things need to be in place before anyone builds an agent. Product data with attributes, documents and relationships should be complete for your best-selling products. The integration with the business system should have a defined update frequency for price and stock. Roles and permissions in the customer portal should be clear. A named person should own the rules for what the agent may do.

Much of the work lies in data and processes. The AI function is a smaller part of that work. The cost of ongoing management is often left out of the calculation. Version changes in the platform and the business system change fields and permissions. Glanser Care is a contracted responsibility at a fixed monthly cost that covers version tracking, compatibility through upgrades, maintenance of the integrations with the business system and bug fixing.

Wait if the catalogue is small and customers order by phone or through sales reps. Wait if the data in the business system is unreliable. Wait if nobody has the authority to decide on rules for orders. An agent on top of uncertain stock levels gives wrong answers quickly.

In that case, one step at a time is a better way to work. Start with product information and self-service in the portal. Build the agent layer once the data holds up.

This approach gives you less to show in the short term. It lowers the risk of incorrect orders, and it gives you time to set spending limits before anyone can place an order on a customer's behalf.

Test whether an agent finds and describes your products correctly

You can run a test this week, before you build anything.

Put together 20 to 30 neutral needs-based questions in Swedish, the kind your customers actually ask. One question might be which pump suits a factory with a specific flow requirement. Another might be which spare part fits a specific machine model.

Ask the same questions to the AI services your customers use. For each answer, three columns in a simple spreadsheet are enough: whether the service found the right product, whether it described the product correctly with specification and price, and whether it recommended it.

Note briefly what was wrong in each answer. "Right product, wrong price" and "missing entirely" need different fixes.

The result is your own measure of how well agents find you. If a product never shows up, there is usually a data error: attributes are missing, the item name is unclear, or the document has not been published.

Compare the answers with the reference data in PIM and the business system, following the split between enriched content and transaction data described in the section on platform reach. Start with the products that account for the most revenue and expand from there once the matches are right.

Which answers to demand from the supplier

Three questions are enough to see whether a setup holds up.

How does an agent read your price for the right customer segment, and does the price come directly from the business system or from a copy? The answer shows whether you can guarantee the right contract price at purchase. A copy that updates overnight is not enough when the agreement changed this morning.

Which events are logged when an agent places or stops an order, and can you show why the decision was made? The answer reveals whether traceability exists or is only promised. Ask to see an example of a stopped order, with the time, rule and user.

What happens to the agent's connections when the platform or the business system gets a new version? The answer shows whether the supplier takes responsibility for compatibility through upgrades, or whether that responsibility stays with you. Ask who tests that the price, stock and order calls still respond after a release.

Answers that only mention AI tools and skip data sources and logs are a warning sign. The answers give you a better basis than a demo. A demo shows the best case, with an item that is already perfectly described.

Start with what the agent will read

We take responsibility for product websites, PIM, customer portals and the connection to the business system, so product data, prices and stock levels stay in sync between the solution and the business system.

In a 72-hour analysis, you set aside two hours, and within 72 hours you get an inventory of functions and integrations, a functional specification, a prototype and a complete cost picture with a timeline, free of charge.