AI-Native Product Architecture
Designing a system around a component that can be wrong
A product with a probabilistic component needs bounded uncertainty, reversible actions, visible confidence, honest escalation and a per-interaction economic model — and the interaction shape decides all of them.
Most AI features fail for reasons that have nothing to do with the model. They fail because nobody decided whether the system suggests, drafts or acts, and so nobody designed the undo, the abstention, the escalation or the cost ceiling that each of those shapes implies. This book makes the interaction shape the first decision and derives the rest from it: reversibility, confidence display, routing, unit economics, latency budgets, caching that cannot serve a wrong answer faster, and the evidence that tells you to cut the feature.
Written for: Founders, product leads and architects deciding what shape an AI feature should take.
No chapter is published yet. The full contents below is the finished outline; chapters go live as they are written, and none of them will sit behind a signup.
What it makes operable
Outcomes, not topic coverage.
- 01Choose between suggest, draft and act before designing anything else
- 02Design reversibility, abstention and escalation into the product surface
- 03Model the unit economics of one interaction, including its failures
- 04Decide on evidence when to cut the feature
Complete contents
12 chapters, in order.
Each chapter settles one decision, so it can be read on its own. Read in sequence to build the argument the book is making.
- 01In writing
A Component That Can Be Wrong
What a probabilistic dependency does to everything downstream of it.
- 02In writing
Deciding Where AI Belongs and Where It Does Not
A test for whether the model is load-bearing or decorative.
- 03In writing
Suggest, Draft, or Act: Choosing the Interaction Shape
The one decision that fixes reversibility, latency and cost for everything after.
- 04In writing
Designing Reversibility Into the Product
Undo, preview and staging as product features rather than engineering afterthoughts.
- 05In writing
Confidence, Abstention, and Escalation
Letting the product decline, and making a decline useful to whoever reads it.
- 06In writing
Routing: Capability, Cost, Fallback
A routing table derived from per-step eval results rather than from instinct.
- 07In writing
The Unit Economics of a Feature
Cost per successful interaction, counting retries, review and failure.
- 08In writing
Latency Budgets and Perceived Speed
Streaming, optimistic state, and the gap between fast and feeling fast.
- 09In writing
Caching Without Serving the Wrong Answer Faster
Cache identity that includes the principal, the policy and the corpus revision.
- 10In writing
Data Flywheels That Do Not Poison Themselves
Feedback loops that improve the system instead of laundering its errors.
- 11In writing
Failure UX: What the User Sees When It Is Wrong
Designing the wrong answer, because you are going to ship one.
- 12In writing
Deciding to Cut the Feature
The evidence and the threshold for stopping without a political fight.
Evidence
What this book is arguing against.
Third-party sources behind the book's premise. Every figure in them belongs to the party that published it and is attributed to them in the text.
- AI Project Failure Statistics 2026: The Complete Picture
Pertama Partners · 2026-02-08 · Industry report · reported
- LLM inference prices have fallen rapidly but unequally across tasks
Epoch AI · 2025-03-12 · Industry report · reported
- Small Language Models are the Future of Agentic AI
arXiv · 2025-06-02 · Research paper · reported
Continue through the library
Adjacent operating manuals.
Shipping With Agents
Merge rate goes up, cycle time does not move, and everyone blames the tooling. The tooling is fine; the operating model is not. This book redesigns the functions that authorship used to absorb: what a specification has to contain now, how to triage review by risk, what PR size and queue discipline actually buy, who owns code nobody typed, how tests become the contract with the agent, and which delivery metrics still mean anything once most committed code is machine-written.
Read the full book
System Design for Developers
Design is not drawing boxes. It is deciding, in order, what load the system has to absorb, where state lives and what consistency it needs, and how the thing behaves when a dependency is gone — then recording the constraint that forced each answer and the signal that would reverse it. This book works through that order using the decisions that actually cost money later: data model, service boundaries, caching, queues and backpressure, timeouts and idempotency, observability, capacity, and how to migrate a system that cannot stop running.
Read the full book