TL;DR — Four pieces this week, one shared argument: the teams that win the next 18 months of AI-flavored commerce are the ones who take the boring work of data shape and interface ergonomics seriously. The flashy layer changes quarterly. The substrate does not.
The theme
Every piece this week is about the layer under the AI layer. Shopify argues that agents will buy from catalogs they can parse cleanly and skip the rest. The unified-commerce piece argues that the customer profile goes to whichever system is in the runtime request path, not the one with the prettiest dashboard. Anthropic argues that a tool's name and docstring are part of the prompt, so tool design is prompt engineering. The B2B post argues that a spreadsheet still beats most portals because power users measure in seconds-per-line, not feature counts.
Put those together and you get a clear thesis. The moat is no longer the model, the platform, or the headline feature. It is the shape of your data, the locus of your runtime state, the legibility of your tool surface, and the keyboard ergonomics of the interface a power user actually touches for eight hours a day. These are all unglamorous substrate problems, they all take 12 to 24 months to fix properly, and they all compound. That lead time is the moat: a team that starts now is buying a head start that no vendor shortcut can collapse later, because the shortcut does not exist.
1. Agentic-Ready Product Data Is the Quiet Moat for 2026 (original)
Overview
Shopify's agentic-ready product data piece argues that once buying agents are real, they will transact against brands whose catalogs are legible to a machine and skip everything else. Humans tolerate ambiguity in a product listing and squint at the photo if the dimensions are fuzzy. Agents do not. They parse the field or drop the SKU, and there is no "well the image looked right" fallback in an automated purchase flow.
The interesting claim underneath is that catalog quality is path-dependent. You cannot buy it from a vendor on Monday and have it on Friday. You build it by installing operating discipline around how new SKUs enter the catalog, how attributes get normalized across regions, and how every team that touches a product record leaves it cleaner. That discipline takes 18 to 24 months to install at a real brand, which is exactly why it becomes a durable advantage.
Technical
The concrete definition of "agentic-ready" comes down to six things. Every attribute uses a controlled vocabulary, so "dark gray" and "charcoal" do not collide. Dimensions and weights are structured with explicit units, no smart quotes, no "approx." Compatibility is a queryable field, not a sentence buried in the description. Returns and shipping policies are machine-readable per product, not marketing copy pointing at a footer link. Variant trees have no ghost SKUs or inconsistent naming. Alt text describes the product literally — "white short-sleeved cotton crew-neck t-shirt" — rather than "model wears top."
None of this is exotic. All of it is grinding work, and most of it lives in the reconciliation gap between the PIM, the ERP, the commerce platform, the warehouse system, and the marketplace listings — each with its own field names and its own change cadence. The ecommerce data integration companion post reads, between the lines, as a tour of that reconciliation problem. The first job of agentic-ready data is not enrichment. It is agreement: one source of truth that downstream systems actually honor.
Takeaway
If you run a brand and want one investment that compounds for three years, hire a permanent catalog ops lead this quarter. Not a PIM consultant on a six-month engagement, a full-time role owned by merchandising with a mandate to define the controlled vocabulary, audit every existing SKU against it, and enforce the schema on every new product that enters the catalog. The ROI is invisible until the first agent integration goes live, at which point it is the whole game. The brands that start now get a year of compounding schema discipline; the ones still debating whether it matters will be hiring cleanup contractors while their competitors ship integrations.
2. CDP vs Commerce Platform — Who Actually Owns the Profile (original)
Overview
Five years ago, CDPs existed because no single system could plausibly own the customer record end to end. The commerce platform had orders, the ESP had email state, support had tickets, and the CDP stitched them together. That architecture is under pressure now because modern commerce platforms have absorbed a lot of the CDP's job — loyalty, browsing, purchase history, support context — with first-class APIs and real-time writes. Meanwhile CDPs have moved upmarket and started pitching themselves as the customer-360 layer above every system regardless of platform capability.
The result is a fight retailers did not sign up for. Two vendors each claim to be the writer of record for the profile. Picking wrong means five years of reverse-ETL between systems that should have been one. Picking neither — letting both claim authority per use case — is the default outcome and the worst option.
Technical
The real answer depends on three questions. First, how many systems write customer state in your business? If the honest count is eight or more — commerce, POS, ESP, loyalty, support, app, in-store CRM, wholesale, call center — a CDP earns its keep because no platform realistically writes from all eight surfaces. If the count is two to four and you are consolidating toward a unified commerce platform, the CDP is buying you much less than its line item suggests.
Second, how much do you depend on identity resolution across anonymous and known sessions? CDPs have years of investment in deterministic and probabilistic matching. If your business hinges on resolving cookies to logged-in customers — high-consideration retail, B2B, long cycles — that is the CDP's best case. If most transactions happen logged in, the commerce platform is enough.
Third, and most important, how real-time are your decisions? CDPs are batch-oriented even when they claim otherwise. That is fine for campaigns. It fails at runtime personalization at checkout, or at clienteling where an associate needs the current cart state in under two seconds. The unified commerce API post makes the right structural point: the system whose data sits in the request path wins runtime, regardless of how good an analytics layer you bolt on next to it.
The default trap is running both as writers of record for different attributes and syncing via reverse-ETL. The classic failure: a customer unsubscribes in the ESP, the CDP rebuilds the profile, six hours pass, and during that window the commerce platform sends a transactional email with a marketing module because its copy of the subscription flag is stale. Nobody can name who owned the state at the moment of the violation.
Takeaway
List every customer attribute your business touches. For each one, write down which system writes it, which reads it, how often, and the cost of latency. Sort by latency cost. High-cost attributes — cart state, loyalty balance, opt-in — belong in the commerce platform because they live in the request path. Low-cost attributes — LTV decile, churn score, audience segments — belong in the CDP. The table is politically painful because it tells one team they are not the source of truth for something they thought they owned. Write it anyway. The alternative is the reverse-ETL purgatory most retailers already live in.
3. Writing tools for agents is its own discipline (original)
Overview
Anthropic's writing effective tools for agents post makes a claim that sounds obvious after you read it and reframes how you design an MCP server once you accept it. A tool's name, docstring, parameter list, and result shape are all part of the prompt. Every word lands in the model's context as authoritative instruction about what the tool does and when to call it. Treat the spec like API documentation — terse, jargony, assumes context — and the model treats it as exactly that, which means it ignores or misuses the tool. Treat the spec like a help message a junior teammate could follow, and the call rate and correctness jump.
If you came at MCP from a REST background, as I did, your instincts are wrong in specific ways. Plural nouns for collections, resource-oriented naming, strict schemas — all of it makes the tool harder for a model to reach for, not easier.
Technical
Four things matter in practice. Names come first. I had a Shopify MCP tool called productsList that the agent kept ignoring in favor of writing raw GraphQL. Renaming it searchShopifyProducts and starting the description with "Use this when you want to find products in the merchant's store, by name, SKU, status, or vendor" fixed the behavior in one session. Same call, same parameters, same return, different name and one sentence.
Parameter shape is second. Models struggle with deeply nested objects, cryptic abbreviations, and boolean flags whose default behavior is not obvious from the name. They are good at flat parameter lists with verbose names that read like English. A Klaviyo tool I shipped originally took filter: { since, until, profileIds, limit }. The flat version — since, until, profileIds, limit as top-level parameters — gets called correctly roughly 80 percent more often against the same tasks.
Result shape is third and the one I fought hardest. A 2,000-token JSON blob burns 2,000 tokens of reasoning budget. Return a tight default summary — count, a minimal field set, a pagination cursor, and an opaque ID the agent can use to fetch the raw result if it actually needs it. Images, variants, metafields, and descriptions stay out of the default. Anthropic's advanced tool use post formalizes this with a configurable result-size threshold, but you should bake the instinct into tool design before relying on platform fallbacks.
Fourth, iterate with the agent in the loop. Show it the spec, watch it call the tool against a real task, see where it gets confused, rewrite the docstring. Three or four passes and the success rate converges. The feedback signal is not your taste, it is whether the model used the tool correctly. And while you are in there, add a no-op think tool. It costs nothing, the model reaches for it before hard multi-tool decisions, and the failure rate drops measurably.
Takeaway
This week, pick the most-called tool in your agent system and audit four things: name, description, parameters, result shape. Rename it for clarity even if it breaks your naming convention. Rewrite the description as if explaining to a new hire. Flatten nested parameters. Cap the default result size. Run ten real tasks and watch where the agent gets confused — that confusion is the next iteration. Tool design is prompt engineering wearing a different hat, and the hat does not change the rules.
4. Why Spreadsheets Still Win at B2B Order Entry, and What Replaces Them (original)
Overview
Most B2B ops directors I have met in the last five years still run their primary order entry workflow from a spreadsheet, and not because they have not heard about modern portals. The Excel sheet has been refined since 2014. It has macros that auto-fill SKUs, lookup formulas that pull current pricing, a paste-friendly layout that absorbs a buyer's order in twenty seconds, and a CSV export the warehouse already ingests. It does not crash, does not redesign itself quarterly, and does not require a login. Every "modern" portal they try is slower, more rigid, and missing the macros. After a quarter they quietly go back to the spreadsheet and tell the vendor they are using the portal.
Shopify's uncomfortable realities of B2B commerce post has rare candor about this adoption gap. It stops short of asking why the spreadsheet keeps winning, though, which is the more useful question.
Technical
The spreadsheet wins on five dimensions, and a portal has to beat it on all five before adoption sticks. Speed per line: a practiced user enters a line in under three seconds, while the fastest portals measure at five to seven because of SKU round-trips and cart reflows. Over 200 lines a day that gap is ten minutes of friction the user feels every time. Paste tolerance: a spreadsheet absorbs any pasted shape and cleans it up with Find and Replace. Portals fail loudly on format mismatches and force manual fixes. Bulk CSV import is a different workflow from paste-into-textarea-and-go, and B2B order management tooling often conflates them.
Error forgiveness: a bad SKU in a spreadsheet shows #N/A inline and the rest of the work is intact. A bad SKU in a portal often nukes the cart or silently drops the line. Offline capability: the spreadsheet works on a plane, in a warehouse without wifi, at a trade show. Most portals do not, and the B2B furniture post is honest that the trade-show-to-order workflow needs offline tools. Composability: a user can pull data from one tab, transform it in another, and feed it into order entry in a third. Portals are fixed-shape, so they cannot be reshaped this way.
What replaces the spreadsheet is not a portal that looks more like a spreadsheet. It is a paste-tolerant bulk-entry surface that accepts messy input, parses best-effort, shows a confirmable preview, and lets the user fix errors inline. Plus a keyboard-driven order entry mode with shortcuts for add, edit, remove, and note. Plus an import path robust enough to handle the real spreadsheets ops people actually maintain — merged headers, hidden rows, notes in column G — which is one of the few B2B problems where an LLM-backed parser genuinely earns its place instead of being a line item in a deck. The customer account extensions runtime gives platform teams the primitives to build this. The work has to be actually done.
Takeaway
Tomorrow morning, sit next to the most prolific spreadsheet user on your ops team and watch them place a real order. Time it. Count the dimensions where the spreadsheet beats your portal — speed, paste, forgiveness, offline, composability — and pick the one that hurts most. Fix that one before shipping another feature. If your portal cannot beat Excel on at least three of those five for a power user, your portal is a reporting interface that pretends to be a tool. Your competition in this category is not other portals. It is a thirty-year-old spreadsheet app with a head start on every UX problem you are trying to solve, and the only way to win is to be measurably faster at the workflow the user actually runs.
Original sources
- Agentic-Ready Product Data Is the Quiet Moat for 2026 — originally published 2026-02-24
- CDP vs Commerce Platform — Who Actually Owns the Profile — originally published 2026-02-25
- Writing tools for agents is its own discipline — originally published 2026-02-26
- Why Spreadsheets Still Win at B2B Order Entry, and What Replaces Them — originally published 2026-02-27
