I can describe the failure precisely, because I have watched each part of it.
The provider SDK goes straight into a controller, because that is what the tutorial did. Six weeks later the provider changes a field name and the failure surfaces in four unrelated features at once, because there is no single place where the provider is described.
Nobody caps output tokens, so a response is truncated mid-sentence. There is no check on why it stopped, so the half-sentence renders as though it were a complete answer, and a user reads a confident, wrong, unfinished reply.
The request runs in the web process, because it worked in development. In production it takes ninety seconds, holds a PHP worker the whole time, and dies at the load balancer with a 504 — after the model has been paid for.
The browser calls the AI service directly, because that was one fewer hop. The credential is now in the client, the endpoint accepts anything, and your provider spend is limited only by the patience of whoever finds it.
And somewhere in the middle of all this, a model that has been told "only create one site per user" creates two — because it was asked twice, politely, and nothing but the instruction stood in the way.
Not one of those is an exotic failure. Every one is a Tuesday.
How I Learned This
The first version of our agent worked on the first try, which was the problem.
It was a chat box. You told it what your business was, and it built you a website. In the demo it was genuinely delightful. It asked good questions, it made reasonable choices, and about a minute later there was a real site at a real URL. We showed it to everyone.
The first thing that broke was time. A turn where the model used several tools took well over a minute, and the whole thing ran inside the HTTP request. Users watched a spinner until something upstream gave up, and then saw nothing at all — no error, no partial answer, no site, despite the fact that we had already paid for every token. The work had been done. We just had nowhere to put it.
So we moved it to the queue, and the second thing broke: the job had a timeout, and a long turn hit it. The job was killed mid-turn, having written nothing, while the widget politely polled a cache key that would never appear. The user sat in front of a chat that had simply stopped talking.
Then a turn came back truncated. We had capped output tokens, sensibly, but we never looked at why the model stopped. A cut-off reply fell through the same branch as a finished one and rendered as an answer. It read fine. It was wrong.
Then a user pressed the button twice.
The tool that creates a site had been told, in its own description, to only ever do this once. And that instruction was honoured perfectly, right up until two requests arrived close enough together that "once" was ambiguous. We got two provisioning runs for one person. The fix was not a better instruction. The fix was a unique index.
None of these were problems with the model. The model was fine. Every single failure was in the code around it, and every fix was something I already knew how to do — I had just never thought to do it here, because this part had a costume on.
That is why the chapters in this book look the way they do. They are not about prompting. They are about queues, deadlines, unique indexes, trust boundaries and structured logs, applied to a component that happens to be non-deterministic.
What "Thinking Fast" Actually Means
The title is not about latency, and it is not about how quickly the model responds.
It means the same thing "shipping fast" meant in the last book: making a decision once, at the right level, so you never have to make it again. Where the provider lives. Where prompts live. What a turn is allowed to cost. What happens when the model is wrong. Decide those once, apply them everywhere, and adding your fifth AI feature costs a fraction of what your first one did.
The alternative is a codebase where every AI feature is a special case with its own retry policy, its own idea of a timeout, its own credential handling and its own failure mode. That is not fast. That is four features and four outages.
Boring scales. Clever decays. That was true before there was a model in the loop, and the model did not repeal it.