TL;DR — Four pieces this week about the same quiet problem: technical wins that nobody can prove. GraphQL adopted but used like REST, unification migrations with no operational metric to defend them, agents retuned at the prompt layer when the harness is the actual problem, and B2B AI features that ship but do not move a number.
The theme
The uncomfortable pattern across this week's reading is that the industry keeps winning technical arguments and then losing the decision the technical argument was supposed to inform. GraphQL won the API debate, but the teams using it are still paying REST latency. Unified commerce won the platform debate, but the people who bought it cannot prove it worked eighteen months later. Prompt engineering was the discipline for two years, and now the agents that actually ship are the ones whose authors stopped tuning prompts and started designing a harness. AI in B2B is pitched as a transformation story, and the features that earn their keep are two unsexy ones nobody puts on a keynote slide.
The through-line is that shipping is not the same as proving, and most of the value in a senior engineer's week comes from closing the gap. Pick metrics you can defend. Rewrite the screen-level query instead of the schema doc. Add a checkpoint and a scope fence before you tune another system prompt. Say no to the AI feature that nobody can attach to a number. All four of this week's pieces are variations on the same move.
1. GraphQL Won. Enterprise Commerce Teams Still Get It Wrong. (original)
Overview
The GraphQL versus REST debate is over in enterprise commerce. Shopify, BigCommerce, Salesforce Commerce Cloud, Adobe Commerce, and the composable crowd have all converged on GraphQL as the primary query API for new development, and Shopify's Admin and Storefront APIs are actively deprecating their REST surface. The interesting question stopped being "which API style?" two years ago. The interesting question is why so many teams that nominally adopted GraphQL are still hitting REST-shaped walls on their highest-traffic screens.
The gap between teams that use GraphQL and teams that use it well is wide and widening, and it is invisible until you open the network tab on a slow product detail page and count seventeen queries that should have been one.
Technical
Four anti-patterns come up again and again in mid-market and enterprise audits. First, GraphQL routes shaped like REST routes — each screen fires a single-entity query, then fires another for reviews, then another for inventory, then another for related products. You pay the tooling cost of GraphQL and collect none of the composition benefits. Rewrite the screen-level query to fetch everything the screen needs in one round trip.
Second, N+1 inside resolvers. A products-with-reviews query triggers one database call per product. The fix is DataLoader or an equivalent batching layer, it is mechanical, and it typically cuts p95 latency on affected screens by half. Third, schemas that grow without pruning. Fields get added every quarter, marked deprecated, and never removed. Three years in, the schema is a graveyard, and nothing can be refactored because every removal might break an unknown client. Treat pruning as a quarterly ritual with a deprecation window and a hard removal date.
Fourth, persisted queries skipped until "later." Later never comes. Apollo APQ or a homegrown equivalent cuts payload size, removes parse overhead on the server, and lets you allowlist exactly which queries production will accept. Skip it long enough and the security team eventually mandates a full audit, which is its own multi-month project. Underneath all four is the cultural piece: teams that ship fast treat the schema as a product surface owned by a small design group with frontend, backend, and platform representation, not as a backend artifact.
Takeaway
Spend an afternoon on the network tab of your three highest-traffic screens. Count the GraphQL requests and the cumulative response size. More than two requests on any screen is anti-pattern one. More than 200KB on any single response is a schema design problem. If you cannot tell whether you are using persisted queries, you are not. Each of these is a sprint of work, and each one compounds across every screen. GraphQL is a powerful tool that rewards teams who treat the schema as a product. The teams that do are shipping enterprise experiences at startup speed.
2. The Metrics That Actually Prove Unified Commerce Worked (original)
Overview
Eighteen months after a unified commerce migration, somebody on the exec team asks the question nobody wants answered: did this actually work? The vendor brings a slide showing 14% conversion lift, 23% fewer support tickets, and 8% more repeat purchases. The numbers are confident. They are also unverifiable, because the baseline is either pre-replatform (and the platform is not the only thing that changed) or a control region (and there isn't one).
Vendor ROI calculators are not built to answer this question honestly. They are built to justify the project after the fact. Proving unification requires a different metric set — one that measures the operational signals unification was supposed to fix, not the lagging financials that move for a hundred reasons.
Technical
The metric set splits into five categories. Cross-channel transaction completion covers BOPIS completion rate (target 95%+, integrated stacks live at 75-85%), cross-channel return time-to-refund (unified: under an hour; integrated: 24-72 hours with a manual queue in the middle), and order-not-found rate at the POS. Inventory truth covers audited SKU-store accuracy, web inventory truth latency (unified under five seconds; integrated five to sixty minutes), and phantom oversell rate — anything above 2% means inventory truth is broken regardless of what your accuracy report says.
Customer state consistency covers the loyalty balance consistency window (under 30 seconds or you have a double-redemption problem) and profile attribute drift — sample 100 customers, query five attributes across every system that stores them, count the disagreements. Operational tax measures reconciliation job count, reverse-ETL pipeline count, and mean time to ship a cross-channel feature (unified: two to four weeks; integrated: eight to sixteen). That last one is the single best predictor of whether your stack is actually unified, because it measures the friction directly. The fifth category is ops headcount per million in revenue — the metric nobody wants to measure, and the one that tells you whether license consolidation translated into the fewer-reconciliation-queues savings that were actually promised.
Takeaway
Pick three metrics this month: BOPIS completion rate, web inventory truth latency, and mean time to ship a cross-channel feature. They cover customer experience, data integrity, and operational velocity — the three things unification was sold on. Measure them this month, measure them again next quarter, and track the trajectory. If the numbers improve, your unification is real. If they don't, you have integration wearing a unified label, and it is time for a hard conversation with your vendor about which features you actually bought. The financial slides at the QBR are not the answer. The operational metrics are.
3. Harness design beats prompt engineering for long-running agents (original)
Overview
Prompt engineering content dominated the AI eng feed for two years. Tweaks, templates, prompt libraries — useful for chat, close to irrelevant for an agent that has to run for an hour unsupervised. Anthropic's engineering team caught on earlier than most and quietly retitled the discipline. They now talk about harness design: the layer around the model that handles context management, summarization, retries, restart, scope control, and recovery. Their two recent posts on the topic are the best writing on agent engineering I have read this year, and the claim underneath both is blunt — prompt engineering is local optimization on a problem that is globally about plumbing.
Technical
The longer you read the Anthropic piece, the more you notice it is mostly about state, not text. State across context windows, across crashes, across handoffs. Four concrete pieces of the harness carry most of the weight. First, context resets. Long-running agents need to start a fresh window when the current one fills, carrying a structured handoff document forward. In my Mission Control PR worker I write a checkpoint every few turns — task, plan, files touched, test status, and a one-paragraph "where I am" summary written by the model. When I hit 80% of the token cap I spawn a fresh subagent with only the checkpoint visible. That single mechanic doubled the length of tasks I can reliably run.
Second, retries that classify before retrying. A naive harness reruns the same prompt. A real harness asks whether the failure was a transient model error, a tool error, a scope violation, or a budget exhaustion, then picks a matching recovery. I added a small Haiku classifier for this and my "retry succeeds" rate jumped from about 40% to 75%. Third, scope fences — a pre-pass that records the files the task is allowed to touch, a post-pass that diffs the changes against the allowlist, and a revert-plus-feedback loop when the agent drifts. This was the single biggest reduction in unreviewable PRs I have ever shipped. Fourth, independent budgets — tokens, dollars, wall-clock, and turns, each stopping the agent on its own. "Ran out of dollars" is a different problem from "ran out of turns," and each one suggests a different fix.
Takeaway
Stop tuning your prompt this week. Open your agent and add four things to the harness layer: a checkpoint file written every N turns, a fresh-context restart at 80% of the token cap, a retry classifier that picks a recovery based on failure type, and a scope fence that diffs changed files against an allowlist. Read the two Anthropic posts back to back with your harness code open. Then, and only then, look at your prompt. The bet I am willing to make is that you find the prompt was never the problem.
4. AI in B2B Ecommerce: Forecasting Wins, Most of the Rest Is Vaporware (original)
Overview
Most of the AI features being added to B2B commerce platforms in 2026 are vaporware. Not bad-intentioned vaporware — real engineers shipping real code — but features that will not produce a measurable business outcome for the customers who turn them on, and that will be quietly de-emphasized inside twelve months. I have watched this movie three times: personalization engines, chat bots, now general-purpose generative AI layered onto B2B portals. The pattern is consistent enough that operators can tell ahead of time which features will pay back and which will not, if they know what to look for.
There are two real wins, both unsexy and both dramatically underweighted in the marketing: demand forecasting and document parsing. The rest is mostly a feature in search of a customer.
Technical
Demand forecasting is the capability I will defend without caveat. The math is well understood — autoregressive models trained on order history, enriched with seasonality, holidays, marketing calendar, even weather. What changed is that the tooling has gotten much better in the last two years (TimesFM, Chronos, Lag-Llama on the open-source side; Anaplan, o9, RELEX on the commercial side), and the commerce integrations have gotten smoother. B2B inventory mistakes are catastrophically more expensive than DTC mistakes — a DTC stockout costs a $40 refund, a B2B stockout costs a $40,000 PO from an account you may never get back — so forecast accuracy is a margin lever, not a nice-to-have.
Document parsing is the second win. Turning unstructured B2B documents — PDF POs, Word RFQs, emailed orders, faxed reorder lists — into structured order data is exactly where general-purpose LLMs earn their keep, because the long tail of weird formats defeated every rule-based parser. A model that hits 95% accuracy on line items, ship-to address, requested ship date, and PO number is a real productivity tool, and brands running it in production talk in concrete numbers like "we cut order entry time by 60%" rather than in vibes.
The vaporware list is specific. Personalized product recommendations in B2B solve a problem the buyer does not have — wholesale buyers are reordering or filling a known need, not browsing for inspiration. Buyer-facing AI chat assistants get low usage and quietly disappear, because buyers want to do their job and leave, not type a sentence when a search field works. AI-generated product descriptions make sense for a DTC catalog of ten thousand SKUs; for a few hundred B2B SKUs where the spec sheet matters and the copy doesn't, they are noise. Predictive lead scoring fails in B2B because the reps managing the accounts have richer signal than any model trained on the sparse input data. The pattern: AI wins on high-volume, structured, currently-manual tasks, and loses when it tries to replace human judgment in low-volume, high-context ones.
Takeaway
When a vendor pitches an AI feature this quarter, ask one question: what is the high-volume, structured, currently-manual task this automates? If the answer is clean — parses inbound POs, forecasts SKU demand at the regional level, matches incoming payments to open invoices — buy it, measure it, expand it. If the answer is fuzzy — personalizes the buying experience, surfaces insights, assists the buyer's journey — pass. There is a 90% chance the feature does not produce a measurable outcome, and the 10% chance it does is not worth the opportunity cost of the team that built it instead of fixing your reorder UX. Real AI in B2B is small, focused, and unsexy. The sexy version is the one that does not work.
Original sources
- GraphQL Won. Enterprise Commerce Teams Still Get It Wrong. — originally published 2026-03-03
- The Metrics That Actually Prove Unified Commerce Worked — originally published 2026-03-04
- Harness design beats prompt engineering for long-running agents — originally published 2026-03-06
- AI in B2B Ecommerce: Forecasting Wins, Most of the Rest Is Vaporware — originally published 2026-03-08
