06-reference

stratechery muse walmart expedia google

2026-09-23·reference·source: Stratechery·by Ben Thompson
stratecherymuseamazonwalmartexpediagoogleagentic-commerceaggregation-theoryai-strategy

More on Muse, Amazon, and Walmart; Muse and Expedia; Whither Google? (Stratechery Update, 2026-09-23)

Why this is in the vault

Direct continuation of yesterday's Amazon/Muse piece ([[2026-09-22-stratechery-amazon-blocks-muse-aggregator-moat]]), adding two more structural test cases — Walmart's Instant Checkout retreat and the Expedia/Google-aggregator precedent — plus Thompson's read on why Google hasn't shipped its own Muse; together they sharpen RDCO's "which layer survives agentic disintermediation" question beyond yesterday's single Amazon data point.

The core argument

Three connected threads, all extending yesterday's Muse-vs-Amazon piece:

  1. Muse/Amazon/Walmart. The fast fix to Amazon blocking Muse is extending the existing 2023 Meta-Amazon ad deal so Muse becomes an Amazon ad surface instead of an ad-avoidance path. The slow road is Walmart signing onto Muse the way it jumped into OpenAI's now-abandoned Instant Checkout — which converted at a third of Walmart's own site/app rate, with smaller carts. Thompson bets Walmart does it anyway: Meta, unlike OpenAI, won't charge a per-transaction fee, and every non-Amazon purchase thins the fixed-cost leverage behind Amazon's logistics buildout.
  2. Muse/Expedia. Expedia signed onto Muse, and Thompson runs the parallel to Expedia/Booking's long, profitable coexistence with Google search — both own the supply-side grunt work (lodging onboarding, payments, fraud) Google never wanted, and both became some of Google's biggest ad customers rather than getting disintermediated. He argues agents make that middleware position more fragile going forward: Muse can in theory crawl hotel sites directly once compute is cheap enough, and unlike a human, won't develop site loyalty an Aggregator can monetize with repeat visits.
  3. Whither Google? Replying to M.G. Siegler's SpyGlass post asking why Google hasn't shipped its own Muse, Thompson argues the real blocker isn't Google's obvious data moat (Gmail, Calendar, Android) — it's business model. Agents remove the human from the loop, which removes the ad surface, which produces institutional foot-dragging on Gemini Spark. He ties this to his own "Google Capital Company" thesis — protect search's cash flow as long as possible while it funds compute buildout — and flags that an agent-driven world makes Google an Aggregator with no physical-world anchor, unlike Amazon's logistics.

Mapping against Ray Data Co

Where yesterday's note mapped to Amazon's physical-fulfillment moat as "the resource an agent can't fake," today's Expedia and Google threads sharpen that into a harder question for RDCO's own Channels agent ([[project_channels_agent_setup]]): Channels has neither Amazon's fulfillment network nor Google's ad-business gravity well — its position is closer to Expedia's, doing the boring grunt work (iMessage delivery, contact sync, calendar reads) a generic agent would otherwise have to rebuild. Thompson's point that Expedia's moat erodes once an agent's own crawl/compute cost falls low enough to bypass the middleware is exactly the risk profile worth watching for Channels' own integrations over time — not a live threat today, but the same mechanism that could make any bespoke integration RDCO builds redundant once a general-purpose agent's tool-use gets cheap enough to route around it. The Google thread is a second, distinct data point for [[project_l5_north_star_strategic_direction]]'s "bets are downstream of agent capability" framing: Google's paralysis is presented as business-model-driven, not capability-driven, a reminder that RDCO's own build decisions should weight incentive alignment (who benefits if the agent works) as heavily as raw technical feasibility.

Related