Learn / Platforms
Adobe Commerce agent readiness
Adobe Commerce stores usually have rich catalogue data and complex storefronts, and the agent readiness problem is almost always the join between them. Attributes exist, variant pricing is modelled properly, and the served page carries a fraction of it because the theme was built for a person looking at a screen.
Configurable products are the main risk
A configurable product whose children only resolve once the storefront has run looks, to anything reading the markup, like a single item with no options. The agent cannot choose a variant, cannot confirm a specific size is in stock, and cannot proceed.
Publish the variant matrix into the page or as structured data, with price and availability per child. See how to make variant pickers agent accessible.
Choose the attributes that answer questions
A large attribute set is an advantage only where the attributes match how shoppers ask. Most catalogues are organised around merchandising and procurement, so the useful subset is small and does not look like the top of the list.
Take the five ways customers describe what they want, and make sure each maps to something published. See how to write product copy an agent can parse.
Watch the storefront layer
Whether you run the standard storefront or a decoupled front end, the question is the same: what does an anonymous cold request receive. Rich data in the platform that stops before the served page is data an agent does not have.
See headless storefronts and AI agents.
Then the checkout
Adobe Commerce checkouts are frequently customised, which means the guest path, the required fields and the payment step are all decisions somebody made rather than defaults. Walk it cold, signed out, on a narrow viewport, and stop at payment. See custom checkouts and AI agents.
Questions
We have hundreds of attributes. Which matter?
The ones that answer how shoppers describe what they want, which is usually a small subset and rarely the ones the catalogue is organised around. Start from the five ways customers ask and work backwards.
Does this apply to Magento Open Source too?
Yes. The catalogue model and the storefront gap are the same. The difference is who maintains the storefront layer, not what an agent needs from it.
What about configurable products?
They are the main risk. A configurable product whose children only resolve client side looks like a single item with no options, so an agent cannot choose a variant or confirm the size it wants is in stock.