← narwal.one/Second Brain
SecondBrain
Ask the Brain
Index/Conceptupdated Sun Aug 02 2026 08:00:00 GMT+0800 (Philippine Standard Time)

Designing for Ephemerality

ephemeralityplanned-obsolescencearchitectureagentic-transformationsystems-designwhittemoreai-daily-brief

Designing for Ephemerality

The sixth and least-developed of the questions in 6 Questions Shaping Enterprise AI (AI Daily Brief), and the one with the sharpest implication for enterprise architecture: build systems that assume their own obsolescence.

"If and as we are successful in designing new systems, how can we build dynamism into that — that has almost planned obsolescence and an appreciation of ephemerality built into it? The models are going to change. The harnesses around them are going to change. Interaction patterns are going to change. Customer expectations are going to change. Market expectations are going to change. Policy is going to change. And so whatever new that gets built has to assume and design for the fact that a few months down the line from whenever it is ready will likely require it to change all over again."

The six change vectors

Whittemore names six independently-moving things, which is what makes this hard — they don't move in sync, so there is no stable window to design against:

  1. Models — capability jumps land unpredictably (see the Nov–Dec 2025 Opus 4.5 / GPT 5.2 step change)
  2. Harnesses — the runtime container around the model (Harness (LLM Agents))
  3. Interaction patterns — chat → IDE → agent → tag/channel
  4. Customer expectations
  5. Market expectations
  6. Policy / regulation

Why this is the load-bearing constraint on the other five questions

Each of the other questions implies a build. Redesign implies new processes. Architecture implies a routing and harness layer. Cost provisioning implies observability systems. Enablement implies a curriculum. Business-case redesign implies new pricing and products.

Ephemerality is the tax on all of them. If any of those builds assumes a stable substrate, it depreciates faster than it pays back. The practical translation is that enterprise AI architecture should optimize for swap cost over peak fit — a slightly worse system you can replace in weeks beats an optimal system you've hard-wired.

This is the same architectural instinct Satya Nadella expressed from the vendor side in the same episode:

"You get to keep your harness separate from the model. That means any model at any given time is swappable."

Model-agnosticism is ephemerality-design applied to exactly one of the six vectors. The harder version applies it to all six.

Tension worth holding

There is an unresolved conflict between this and the vault's harness-investment thesis. Ryan Lopopolo's position (in Harness Engineering (Ryan Lopopolo, AI Engineer)) is that harness investment compounds across model releases — you build lints, evals, and reviewer prompts that keep paying. Whittemore's ephemerality framing implies much of what you build has a short half-life.

The reconciliation is probably a distinction between layers:

  • Encoded judgment (evals, quality gates, specs, taste captured in skills) compounds — it's about your domain, not the model.
  • Plumbing (integrations, routing tables, interaction surfaces, UI) is ephemeral — it's about the vendor's current shape.

Tyler Brown's note from the AI Engineer World's Fair (in 5 AI Engineering Trends That Non Engineers Should Know About (AI Daily Brief)) sits right on this seam — even the compounding layer needs re-cutting per model generation: "Each time there's a new model release… it's as if you have a kid that grows from middle school to high school. You have to change the curriculum for them to get the benefits of the new model."

warning Open question If encoded judgment also needs re-implementation every model generation, the compounding claim weakens considerably. Worth revisiting after the next frontier release.

Cross-references

Sources