Three weeks after launch, open the folder nobody looks at anymore. The press release still quotes the introductory price: $79. The product page moved to $89 on Tuesday. One retailer is showing the old price next to a new shipping estimate, the FAQ still promises the integration that slipped to next quarter, and the spokesperson one-pager, saved as FINAL_v7, would happily brief an executive into repeating three facts that stopped being facts this month.
Now ask an AI shopping assistant whether the integration is included. It answers immediately and confidently, from somewhere in that pile. Whether it picked the right somewhere is a coin flip your team didn’t know it was tossing.
Here’s the uncomfortable part: nobody made a mistake. Every one of those sentences was approved, and every surface is keeping its own time. The release records what was true on launch day, which is its job. The product page follows the catalog. The retailer feed updates on the retailer’s schedule. The FAQ is waiting on a web sprint that keeps losing to bigger tickets, and the brief in that folder was finished, in the fullest sense of the word, seven weeks ago.
That’s message drift. It used to be an embarrassment you caught eventually. Now there’s machinery that can retrieve any version of the story and repeat it to a buyer as the current one, which turns a filing quirk into a live communications question: when the product changes, who owns the public sentence about it?
The product story now has a live data layer
A press release and a product catalog were never the same kind of document. One tells a coherent story about a moment; the other has to survive everything that changed since the launch. What’s new is how directly the second kind now feeds the answers customers see.
Google’s announcement of the Universal Commerce Protocol describes an open standard meant to give agents and commerce systems a common language across the shopping journey, from discovery through checkout and post-purchase support, and the protocol’s core concepts include catalog search and product lookup. Shopify’s catalog documentation for agents is more concrete still: an agent can search a merchant’s catalog, look up a known product for fresh data, and pull variant-level detail with availability signals. On the search side, Google’s product structured data guidance explains that product facts can arrive from page markup, from a Merchant Center feed, or both, and that some experiences combine the two.
To be clear about what this doesn’t mean: not every AI answer is a live catalog read. Some answers come from crawled pages, cached indexes, third-party product copies, or a blend, each with its own refresh schedule. And none of it is the machinery misbehaving. Retrieving the current product fact and handing it to a buyer is the system working exactly as designed. The exposure comes from the other direction: when your own surfaces disagree, the machinery distributes the disagreement with perfect confidence.
There’s already first-party plumbing built for this. Commerce and Feedonomics describe their Agentic Catalog Exports as preparing and syndicating product catalogs for AI-driven discovery surfaces; it’s a vendor’s own example rather than market-wide proof, but it shows where product data is headed, and how little patience that pipeline has for a campaign document that stopped updating at launch. I’ve written before about how machine-curated gates now sit between brands and audiences; agentic shopping makes the gate unusually literal, because the same system that decides whether your story appears may also be quoting your product facts back to a buyer.
For comms, the practical takeaway is a distinction, not a technology: narrative assets are dated records, operational facts are live claims, and a launch pack contains both without labelling either.

Figure 1. Operational product facts and PR materials travel on separate paths with separate clocks, and a public answer can draw on either. Sources: Google UCP announcement, Google Search Central, Shopify catalog documentation, Commerce/Feedonomics. Original diagram.
Audit the five places one claim can split apart
Resist the urge to audit everything. An inventory of every asset the company has ever published is how a fixable problem becomes a 14-tab spreadsheet with no owner.
Pick one material claim instead. Price is the best first candidate, because when two numbers disagree there’s no interpretive wiggle room, but availability, a return window, or a delayed feature all work. Then trace that single claim outward from the system that governs it, in order, and stop at the first place its meaning changes. The order is the point: it tells you whether you’re looking at a wrong source or a slow destination, and those need different fixes.
Start with the operational source of truth
Ask the product owner one question: which field, in which system, currently governs this claim? “The website” is not an answer. Which record holds the price? For which variant, which region, which currency? When did the last change take effect, and was there an approved exception for a retailer, a loyalty tier, a launch cohort?
It’s the least glamorous step and the one that saves you from correcting the wrong thing. A page can be right for US buyers and wrong for Canada. A feature can exist on one plan and be delayed on another. A promotion can end at midnight in the billing system while its landing page timer runs on until someone clears a cache. Record the current value, the owner, the effective date, and the exceptions before you compare a single piece of public copy. And if the source itself turns out to be disputed, stop; publishing a faster version of an unresolved fact just gives the confusion better distribution.
Follow the claim through pages, feeds and agent catalogs
Now compare outward. The visible product page. The structured data underneath it, which can carry a different offer than the headline shows. The Merchant Center or retailer feed. If the business exposes a catalog to agent surfaces, run the actual lookup for the product and variant rather than assuming the page and the catalog say the same thing; Shopify’s documentation notes that catalog lookups return current pricing and availability and warns against reusing cached results, which is a polite way of saying that “we checked last month” is not a fact about today.
The question at each stop is narrow: what value does this surface expose for this exact variant, region and moment? Each surface can look perfectly reasonable alone. The drift only becomes visible when you put them side by side.
Check the PR-controlled story last, and don’t call it low-risk
Finally, open the materials comms actually controls: the release, the newsroom page, the FAQ, the media kit, campaign copy, the support script, the spokesperson brief. Sort every statement into one of two piles: dated historical record, or undated current claim.
The distinction does real work. A release that was accurate on launch day should usually stay as written; it’s a historical record, and silently rewriting history creates a credibility problem worse than the one you’re fixing. If a material statement in it has become misleading, the answer is a dated correction or update note pointing to the current fact. An undated FAQ or a live spokesperson brief gets no such grace. If it still promises the old price or the delayed feature, it isn’t historical. It’s just wrong, and it’s wrong in the exact place a journalist, a support agent or an AI system might look for the official version.
End the audit with a small record: claim, current value, source of truth, surface, observed value, timestamp, owner, status. That’s enough to show where the story first split and who can pull it back together.

Figure 2. A one-claim audit worksheet: trace a single material claim from its source system across commerce and PR surfaces. Sources: Google Search Central, Shopify catalog documentation, Agility launch-monitoring guidance. Original worksheet.
Give product changes a communications owner before they ship
“Keep comms in the loop” has ended a thousand meetings and prevented almost nothing, because a loop isn’t an owner.
The obvious objection deserves a straight answer first: comms doesn’t own the product database. True, and it doesn’t own search results or social platforms either, yet nobody concludes that brand representation there is someone else’s problem. Owning the product fact and owning the public sentence about it are different jobs. The fact belongs to product and commerce. The sentence, in every place a customer or journalist will meet it, belongs to comms. The failure mode is the gap where each side assumes the other has it.
The tool for closing that gap is deliberately boring: a claim register. For each material claim, record the approved public wording, the underlying fact, its authoritative source, the comms owner, the affected surfaces, the effective date, and the trigger that forces a review. It can live in a spreadsheet or a release workflow; the format matters far less than the guarantee that a product-side change opens a comms-side task.
If I had to pick the one field teams skip and then regret, it’s the trigger. “Review quarterly” works for slow corporate boilerplate and is useless for a price that can change on Tuesday afternoon. Tie reviews to events the business already tracks:
- Price or promotion changes, including the quiet end of an introductory offer.
- Availability shifts: a region opening or closing, a variant going out of stock, a waitlist starting.
- Feature delays or removals, especially anything named in the launch materials.
- Bundle, loyalty, shipping or returns changes that alter what a buyer actually receives.
- Discontinuations, where every surface still carrying the claim becomes wrong at once.
Walk one through. Product decides Monday that a launch-promised capability moves to next quarter. The product owner updates the roadmap with an effective date. Commerce checks whether the feature appears in catalog attributes or product copy. Comms pulls the register and finds the release, FAQ, campaign email and spokesperson brief that name it. Support gets an approved explanation before customers start asking where the button went. That’s five teams moving from one trigger, and none of it requires new software.
It does require triage. A typo in descriptive copy is not a wrong safety statement, and treating them identically guarantees the process gets abandoned by October. Give high-consequence claims, anything touching price, availability, legal or safety language, a same-day route with a named approver, and let low-risk copy follow once the operational surfaces agree.
When channels disagree, fix the most consequential answer first
Say the introductory price ended last night. The source system says $89, the product page says $89, a retailer still shows $79, a paid social ad is repeating the $79, and an AI answer is citing the launch release. Which one gets fixed first?
The tempting answer is whichever wrong answer an executive saw. The visible mismatch feels urgent precisely because it’s visible. But visibility is the wrong sort criterion, and the fastest edit, usually the release, is rarely the one that matters most.
Sort by customer consequence instead. First, confirm the current fact with its owner, including regions and any retailer exception; correcting surfaces to a disputed value is drift with extra steps. Then contain the surfaces that can change what a buyer pays or receives: pause or annotate the ad, push the corrected feed, check the page’s structured data as well as its visible text, and hand support a sentence that acknowledges the mismatch without inventing a discount policy on the spot. Only then work through the newsroom and FAQ, leaving the dated launch record intact and adding a dated correction where a reader could mistake the old price for a live offer.
Then retest, because correction isn’t propagation. Retailer pages and AI answers can lag, and some third-party copies will stay outside your control entirely. Log what each surface shows and, where a platform exposes one, the source it cites; a citation pointing at an outdated page is more useful than a screenshot, because it tells you exactly where the next correction request goes.
A stale lifestyle description is embarrassing. A wrong price, availability promise, return condition or safety claim changes what a customer pays or receives. Embarrassing waits. Consequential doesn’t.

Figure 3. Correction order by customer consequence and propagation reach, not by which surface is easiest to edit. Sources: Google Search Central; Agility launch-monitoring guidance. Original matrix.
Measure drift the way you measure reach
Launch reporting asks how far the story travelled. Almost nobody asks whether it stayed true while travelling, which is odd, because the second question has a cleaner metric.
The discipline already half-exists. Agility’s guidance on post-launch monitoring for ecommerce recommends a pre-launch baseline and stable tracking topics across product promise, price, promotions, shipping and availability. Extend exactly that habit past the recap deck: keep the launch-day value of each material claim, then re-check whenever one of its triggers fires.
Three clocks tell you whether the system works. Time to detection: how long a mismatch lived before anyone noticed. Time to correction: how fast the owning team fixed what it controls. Time to agreement: how long until the surfaces a customer actually encounters showed the same current fact. The third is the slowest and the only one the customer experiences, which makes it the honest headline number.
For AI and retailer surfaces, use a small, stable query set: the same product, price, availability and feature questions, for the same variant and region, on a schedule. Record the answer, the timestamp, and the cited source where one is shown. And don’t score an answer wrong until you’ve checked the operational fact first; occasionally the “outdated” AI answer is faithfully reporting an internal disagreement nobody had noticed yet. AI visibility needs repeatable measurement precisely because platforms, prompts and citations shift; claim-level tracking narrows that broad problem to facts with owners and consequences.
One honest caveat: you will never get every surface to agree instantly, and chasing total agreement is its own trap. Third-party copies, old coverage and cached answers are partially outside anyone’s control. The goal is a short, known time-to-agreement for the claims that matter, not a perfectly synchronized internet.
Treat launch language like maintained product data
Go back to the launch folder. Nothing in it needs to be deleted. The release, the approved quotes, the day-one story everyone worked to make true: that’s a legitimate archive, and archives should stay put.
The problem was never the archive. It’s that the archive was doing a second job nobody assigned: serving as the current product story, unowned and unwatched, while the product moved on. If a material claim can change without waking the person responsible for the release, the FAQ and the spokesperson brief, that’s the actual gap, and no amount of launch-day discipline closes it.
So close it small. Pick one live product claim this week. Trace it across the five surfaces, name the owner of the public sentence, and set the trigger that wakes them next time the fact moves. If the surfaces disagree, fix the highest-consequence answer first and time how long the rest take to follow.
For PR teams, that’s the real shift agentic commerce brings: the story no longer ends when coverage peaks. Launch day is when ownership starts.



