The book moves outward from the single call.
The early chapters build the boring foundation: one endpoint, one provider, structured output you can trust, prompts that live in version control, and caps on what any of it can cost you. The middle chapters give the model hands — tools, agent loops, side effects, and the trust boundaries that keep an agreeable model from becoming an expensive one. The later chapters deal with everything that happens after it works: testing something that never answers twice, deterministic rescue when the model is wrong, observability, degradation, and shipping.
Each chapter is built on code that runs in production today. Where a pattern exists because something broke, the book says what broke.
Conventions Used In This Book
Code follows the same conventions as the rest of my work and the previous book: strict types, explicit return types, FormRequests for validation, Response Wrappers for JSON, DTOs for typed data, and the Manager-Facade-Driver pattern at integration boundaries. Examples target Laravel 13 and PHP 8.4.
The term "provider" means whoever runs the model — the company you send a request to and get tokens back from. "Driver" means your class that talks to one provider. "Tool" means a function you have exposed to the model, and "turn" means everything that happens between a user pressing enter and the feature going quiet again.
Provider APIs change faster than framework APIs. Where this book shows a request shape, treat the shape as the lesson and the field names as a snapshot: check the current documentation before you copy it.
The Four Principles
Everything in this book follows from four ideas. They are not opinions about architecture. They are what is left after the outages.
1. A model is an unreliable network call wearing a costume.
It is a third-party HTTP endpoint with high latency, variable output, occasional 429s, and a bill attached. Every instinct you have about integrating a flaky payment gateway is correct here. Timeout it. Cap it. Retry the failures worth retrying and none of the others. Assume it fails, and decide now what the user sees when it does.
2. Prompts are code.
A prompt determines behaviour. That makes it code, and code belongs in version control, in review, and in a deploy — not in a database row somebody edits on a Friday, and not in a config file nobody diffs. When a prompt changes, behaviour changes, and you should be able to point at the commit.
3. Cap everything: tokens, wall-clock, iterations, money.
An uncapped AI feature is an uncapped invoice. Every loop needs a maximum number of turns. Every job needs a deadline shorter than its timeout. Every tenant needs a ceiling. Every response needs a token limit chosen by you on the server, not implied by the client. You will not notice the missing cap until the month you do.
4. The model is an untrusted caller.
It can be persuaded. It will be persuaded. Anything you enforce by asking the model nicely is not enforced. Verification, ownership, quotas and permissions live in your database and your middleware, behind the tools — never in the instructions.