Design for Wobble: Compute Reliability Is Becoming a Customer Experience Surface
A France heatwave warmed nuclear reactors enough that operators throttled output. RTE said the grid was secure. Both statements were true, and the contradiction felt like a preview: “always-on” AI agent promises lean on assumptions that capacity can stop guaranteeing. Marketing and customer-facing…

Last week the Rhône ran warm enough that EDF had to throttle output at several of its nuclear reactors. The water that cools the cores was too close to the discharge limit, so the reactors stepped down. RTE, the French grid operator, told the public the system overall was secure. Both statements were true at the same time. The aggregate held. The specific units wobbled.
I kept reading that line about a secure grid while a tab in the next window was open to a vendor deck promising always-on, hyper-personalized AI agents for every customer touchpoint. The contradiction did not feel academic. My read is that the second promise leans entirely on assumptions the first one has stopped guaranteeing.
This is the gap I want to sit in for a minute, because I think it is becoming a design problem for anyone building customer-facing AI, not an energy story.
The macro is fine. The micro is where you live.
If you run a marketing org, you do not actually need the grid to be secure on average. You need the specific inference call powering your onboarding agent to return inside the latency budget at 9:47 on a Tuesday for a customer who is two clicks away from churning. Averages do not pay rent on that interaction.
What we are watching, in slow motion, is the unwinding of an unstated assumption that compute is invisible plumbing. For a long time it more or less was. You bought tokens, you got tokens. Capacity wobble was a backend story. Now the wobble is starting to leak into customer-facing surfaces: rate-limit errors mid-conversation, model swaps that change tone halfway through a thread, regional latency spikes during heatwaves and cold snaps, capacity that gets allocated to whoever signed the bigger contract last quarter.
This is not a bug in any one provider. It is the physical layer reasserting itself. Reactors throttle on heat. Transformers have lead times. Water rights get litigated. The promise of frictionless always-on agents was built on a curve of cheap, abundant compute that the physical world is now openly negotiating with.
The market noticed before most marketing teams did
The clearest signal that capacity itself is becoming a product, not just a backend cost line, is the Google and Blackstone AI cloud venture targeting surging demand against major 2026 infrastructure spending. Read the announcement for what it is: a hyperscaler and a real-asset financier productizing reliable compute as a thing you can buy with terms, tiers, and a service contract attached. That is the macro market saying out loud that capacity is a first-order product now, not plumbing.
This matters for marketing leaders even though no one in the announcement is talking to us. The productization of capacity at the wholesale layer will eventually trickle into the application layer as reliability tiers, priority lanes, and explicit failure modes. Vendors will start selling against each other on uptime guarantees and graceful-degradation patterns the way CDNs once did. The teams that build for this early will look prescient. The teams that assumed always-on will look careless.
I have written before about how compute geography is becoming the routing layer for agentic workloads. That piece argued the macro case. This is the marketing-team counterpart: if compute is geography and capacity is product, then reliability is a customer experience surface, and someone on your side of the org chart has to design for it.
What designing for wobble actually looks like
I keep coming back to a small set of primitives that any team building customer-facing AI should be able to articulate. Not as a checklist. As a vocabulary.
Promise tiers. Not every customer moment carries the same cost of failure. A first-time onboarding agent should sit on your most reliable lane with explicit fallbacks. A nice-to-have creative recommendation in an email digest can wait, reroute, or degrade to a static asset without anyone noticing. Right now most marketing stacks treat both calls the same way. They use the same model, the same provider, the same retry logic. That is not a stack. That is a vibe.
Workload routing. The interesting agentic systems being built today route requests across providers and model sizes based on the actual task, not the brochure. Cheap calls go to cheap models. Latency-sensitive calls go to the closest region. High-stakes calls go to the model whose failure mode you understand best. This is the design layer the hyperscaler venture quietly assumes. The market is going to sell you reliability. You still have to wire it into your customer flows.
Graceful degradation as voice. This is the one most teams miss. When the agent cannot do the thing, what does it say? Silence is the worst answer. A confused hallucination is worse. A clean, branded sentence that names the limitation and offers a useful alternative is the actual craft work. It is also the moment your customer learns whether your brand has internal coherence or just a personality layer painted over whichever model is up.
Promise language calibrated to the layer underneath. I notice marketing copy is still writing checks the infrastructure increasingly cannot cash. "Instant." "Always." "Every time." These words used to be cheap because the infrastructure absorbed the variance. They are getting expensive. Teams that quietly soften the absolutism in their commitments, while increasing the specificity of what they do guarantee, will end up with more trust, not less.
The discipline underneath the design
There is a clean separation worth holding. The grid is not in your control. Heatwaves are not in your control. Whether Chinese labs continue narrowing the cost-capability frontier and reshaping token economics is not in your control. Whether your hyperscaler honors its priority tier next Tuesday is partially in your control and largely not.
What is in your control: which workloads you route where, what promises you make in copy, how your agents speak when they cannot complete the task, which customer moments you refuse to let fail, and which ones you let degrade visibly and gracefully.
The teams I respect right now are the ones quietly mapping that boundary. They are not building for a hypothetical world of infinite reliable compute. They are building for the one where capacity is variable, costs reset on the upstream geopolitics, and customer perception is shaped by the worst minute of the worst day, not the average.
What this opens up
If you take this seriously, reliability stops being a backend KPI and starts becoming a marketing differentiator. The brand that keeps its smaller promise during a capacity event beats the brand that breaks its bigger promise. The agent that says one clean true sentence under load beats the agent that hallucinates a confident wrong one. The funnel that has a designed fallback for every AI-mediated step beats the funnel that assumes the happy path.
This is the move I would watch. Not which model is on the leaderboard this week. Which teams are building customer experiences where the underlying compute can wobble and the customer perception stays steady. That is a real moat. It compounds. It survives the next heatwave, the next price war, the next provider outage that the press release will call a transient incident.
The constraint is not a problem to route around. It is the shape of the territory. The reactors will throttle when the rivers warm. Capacity will tier. Costs will move on news cycles a marketing team cannot influence. The work is to design promises proportional to what the layer underneath can actually deliver, and to make the moments when it cannot deliver feel like craft instead of failure.
That is the design brief. Not always-on. Always coherent.
Sources
Reader account
Join the conversation
Sign in with a private email link to manage preferences and leave a comment.

Comments