Most ecommerce teams try to improve AI output by writing better prompts. That works for a while -then it stops. The reason isn't that the prompts are bad. It's that prompting is the last mile. The failures that persist after good prompting are almost always failures in the information environment the agent is working in: undefined terms, no single source of truth, no record of where a number came from, and no way for the agent to look things up the way the question actually requires.

This guide addresses those structural failures, ordered by leverage. Step 1 will fix more output quality than steps 4–6 combined, and it costs the least.

A note on scope: this is written for teams where humans are still in the loop and one person (or one agent session) works on a task at a time. That describes almost everybody right now. Step 6 covers what changes when that stops being true, and can be skipped until it applies to you.

An agent will faithfully use whatever term you give it - and quietly treat two words for the same thing as two different things. This is the single most common cause of output that looks complete and is wrong.

The failure shows up everywhere: one person's brief says "revenue," another's says "net sales," a third says "shipped revenue." The agent summarizing all three produces a number that reconciles to nothing. Or "conversion rate" means sessions-to-orders on your DTC site, glance-views-to-purchases on a marketplace, and clicks-to-purchases in an ad platform. Same phrase, three denominators, no warning.

The problem isn't that the agent lacks intelligence. It's that nothing in its inputs tells it these terms are the same concept - or that they're different concepts wearing the same name.

Create one plain-text file. Call it whatever you like - vocabulary, entity glossary, definitions. Load it into every project, skill, or agent context where analysis or reporting happens.

It needs three sections:

Entities - the things that exist in your business, with one canonical name each and their aliases. For example, "Product" maps to your internal SKU as canonical, with ASIN, GTIN, variant ID, catalog item ID, and MPN as aliases.

Metrics - every metric with its formula, and explicitly, its denominator. State which metrics are not comparable across channels. When a term like "revenue" could mean gross or net, declare the default.

Relationships - what connects to what, so the agent knows which paths exist. Product is sold on a Channel. Campaign promotes a Product. Creative belongs to a Campaign. This section looks trivial. It is not. It is what lets an agent answer "why did this product's performance drop" by walking the chain from product to campaign to creative to keyword, rather than searching prose and guessing.

Ask an agent, using only this file, to define your three most-used metrics. If it produces the same definitions your finance lead would, you're done. If it hedges or offers alternatives, the file is ambiguous - fix it there, not in the prompt.

This is the step most guidance skips, and it's where ecommerce diverges from the software examples these architectures are usually designed around. In software, a person is a person and a deploy is a deploy - identity is obvious. In commerce, identity is contested, and deciding it is the work.

The same physical product may exist as a manufacturing SKU, several marketplace listings across regions (each with its own identifier and parent-child structure), a catalog item in one or more ad platforms, a variant on your own store that might be bundled differently, a case pack at wholesale with its own barcode, and a retailer's own internal item number.

If your agent doesn't know these are one product, every rollup is wrong. If it wrongly merges things that aren't the same product - a 30-count and a 60-count, say - every unit economic is wrong in the opposite direction. The failure mode is invisible: the analysis completes, the numbers look plausible, and the error only surfaces when someone reconciles against a real system.

Pick your spine - the one identifier everything else maps to. Usually your internal SKU or a product-family ID. Never a channel-specific ID, because channels change and the spine shouldn't.

Build a mapping table. A spreadsheet is fine. One row per channel identifier, all pointing at the spine. Each row captures the spine ID, channel name, channel-specific ID, pack size, and any notes like parent ASIN relationships.

Then write down the rules you chose, in the same file:

The rules matter more than the table, because the table will be regenerated and the rules won't.

Ask an agent to total revenue for one product across every channel, using only the mapping. Reconcile against a system you trust. If it doesn't match, the mapping is wrong - and better to find that now than in a client deck.

Agent output ages badly and silently. A competitor pricing analysis from six weeks ago reads exactly like one from this morning. A market sizing built on a half-remembered number reads exactly like one built on a filed report. When that output feeds the next task - and it always does - stale and unsourced facts propagate as though they were fresh and verified.

The question that exposes this: where did this number come from, and when? If nobody can answer it in under a minute, you don't have a knowledge base. You have a pile of confident text.

Every artifact an agent produces carries a provenance header. Not optional, not sometimes:

For any claim inside the artifact that came from a different source than the header, mark it inline.

The Expires field carries more weight than it looks like it should. It converts "is this still true?" from a judgment call into a lookup. Suggested defaults: competitor pricing expires in 7 days, ad platform performance in 30 days, category and market data in 90 days, brand positioning and ICP in 180 days or on strategy change.

Pick a random claim from a recent deliverable. Trace it to source in under a minute. If you can't, the practice isn't in place yet.

Effort: Near zero once it's in a template. The discipline is in never letting an artifact through without it.

Agents are wrong sometimes. That's fine and manageable - right up until wrong output lands in the same place as verified knowledge, at which point it becomes an input to everything downstream and there's no way to tell it apart from the good stuff.

The principle stated plainly: an agent never approves its own work into shared truth. Not because agents are untrustworthy in general, but because verification and generation should never be the same act by the same actor.

For the rest of this guide - including how to set up review states, match your retrieval to your question type, and handle multi-writer coordination - here's the full SOP, a free gift from me :)

🖥️ Gamma - Generate polished presentations, docs and sites from a prompt.

🎨 ImagineArt - All-in-one image, video and audio generation workspace.

⚙️ Magnific - AI upscaler and enhancer that adds realistic detail to images.

🌐 Lovable - Build full-stack apps from a prompt with clean React code and GitHub sync.

🗣️ Sierra - Voice-first AI agents that automate enterprise customer support.

😍It was great, all I needed

🙂Good, not great

🙄It sucked