free · outline published · 0 of 67 chapters written

The AI Engineer's Handbook

How to build systems on top of models that are wrong sometimes by design. Written for the engineer who has a model behind an API and a product that has to work on Monday — not for researchers, and not for people collecting prompt tricks.

Nothing is written yet. Here is the whole map anyway.

Publishing the outline before the chapters is the honest version of “growing”: you can see the real territory now and decide whether it is worth coming back for, instead of discovering the shape one post at a time. Every chapter link below is a permanent address from today, so anything that references a chapter keeps working when that chapter lands. Two rules the book is held to — no figure written from memory, and every technique carries its failure mode and the eval that catches it.

Why this is separate from the Cost Handbook.

The Cost Handbook owns what it costs. This book owns whether it works. Neither repeats the other; each links across at the seam. If you are here to work out what something costs, that book is the one you want — it re-derives its numbers from vendor pricing feeds and carries the provenance. This one assumes you have decided to build the thing and now have to make it actually work.

67 chapters across 11 parts · 0 written · first chapters in progress

Part 1Foundations — what the job actually is0/4

An AI engineer is not an ML researcher who ships, and not a backend engineer who calls an API. The job is building reliable products on an unreliable component. Everything else in this book follows from taking that sentence literally.

1.1What an AI engineer actually doesplanned

The role against ML engineer, researcher, and data scientist — and what you are accountable for when it breaks at 2am.

1.2The stack in one pageplanned

Every layer from token to product, who owns each, and which layer your bug is actually in.

1.3Engineering with a component that is wrong sometimesplanned

Why the habits that make deterministic software reliable — unit tests, exact assertions, retries — mislead you here, and what replaces them.

1.4When not to use a model at allplanned

Regex, a lookup table, and a form still win a surprising share of the time. The cheapest correct answer is the one to beat.

Part 2The model layer — what you are actually calling0/8

You cannot debug what you do not understand one level down. This part is the minimum mechanical model of an LLM needed to explain a bad output, not enough to train one.

2.1How LLMs work, to the depth you needplanned

Next-token prediction, attention, and the handful of mechanics that explain most production surprises.

2.2Tokenizationplanned

BPE, why non-English and code cost more per unit of meaning, and the off-by-one bugs that come from counting characters.

2.3Context windows and what fits in themplanned

Advertised length against effective length, position effects, and why the middle of a long prompt gets ignored.

2.4Sampling, temperature, and determinismplanned

Why the same prompt gives different answers, which knobs actually change that, and why temperature 0 is not determinism.

2.5Embeddings and what a vector meansplanned

Similarity is not relevance. Dimensionality, normalisation, and the cases where cosine distance confidently lies.

2.6Choosing a model per call siteplanned

Why public benchmarks do not transfer to your task, and how to run the only comparison that counts.

2.7Reasoning modelsplanned

What extended thinking buys, where it hurts latency and quality, and deciding per call site rather than per app.

2.8Images, audio, and documents as inputplanned

How non-text inputs are processed, where they silently degrade, and why a PDF is the hardest one.

Part 3Prompting and context engineering0/6

A prompt is source code that happens to be written in English. It gets versioned, reviewed, and tested, or it rots. Context engineering — deciding what enters the window and in what order — is the larger half of the discipline and the less discussed one.

3.1Prompting as engineeringplanned

Version control, review, and regression tests for text. The workflow that separates a prompt from a lucky guess.

3.2Writing instructions a model can followplanned

Specificity, ordering, negation failure, and why most 'the model ignored me' bugs are ambiguity bugs.

3.3Examples, few-shot, and when to show rather than tellplanned

The tasks where three examples beat three paragraphs, and how badly chosen examples poison a distribution.

3.4Chain of thought and step reasoningplanned

What it measurably improves, what it only appears to improve, and the tasks it makes worse.

3.5Structured output and output contractsplanned

Schemas, constrained decoding, validation, and repair loops — turning free text into something a type system can hold.

3.6Context engineeringplanned

Assembly, ordering, compaction, and eviction. The discipline of deciding what the model sees on this turn.

Part 4Retrieval and memory0/8

Retrieval is how a model touches facts it was not trained on and cannot be trusted to remember. RAG is not a product feature, it is a search problem with a language model attached — and it fails for search reasons far more often than for model reasons.

4.1Why retrieval, and what it does not fixplanned

Grounding, freshness, and provenance — plus the failure classes that retrieval cannot touch.

4.2Chunkingplanned

The quiet decision that sets a ceiling on everything downstream, and how to choose it from the query shape rather than a default.

4.3Vector databasesplanned

What the index actually does, the operational cost of one more datastore, and when a Postgres extension is the correct answer.

4.4Hybrid searchplanned

Why pure vector search underperforms on names, codes, and exact phrases, and how lexical and dense retrieval get combined.

4.5Rerankingplanned

The cheapest large improvement available in most RAG systems, and how to measure that it worked.

4.6Retrieval as a tool the model callsplanned

Letting the model search, refine, and search again — against fetching once and hoping.

4.7A taxonomy of RAG failuresplanned

Missed retrieval, distracting retrieval, correct-but-ignored context, and stale ground truth. Diagnosis before treatment.

4.8Memoryplanned

Short-term against long-term, what genuinely needs to persist between sessions, and why most memory features are a retrieval problem wearing a costume.

Part 5Tools and agents0/8

An agent is a loop that calls tools until it decides to stop. Almost every hard problem in this part is a consequence of those two words: loop, and decides.

5.1What an agent isplanned

A definition tight enough to build against, and the line between an agent and a workflow with good marketing.

5.2Tool use and function callingplanned

How a model calls code, what the schema actually does, and where the round trip breaks.

5.3Designing tools a model can use correctlyplanned

Tool descriptions are prompts. Granularity, naming, error messages, and the interfaces that cause silent misuse.

5.4The agent loopplanned

Termination conditions, step budgets, progress detection, and stopping a loop that believes it is nearly finished.

5.5Agent architecturesplanned

ReAct, plan-and-execute, reflection, and router patterns — what each is good at and how each fails.

5.6Errors, retries, and self-correctionplanned

When a model can fix its own mistake, when retrying makes it worse, and how to tell the two apart at runtime.

5.7Code execution as the universal toolplanned

Why writing code beats a hand-built tool for open-ended work, and the sandbox that makes it survivable.

5.8MCP and tool interoperabilityplanned

Standard interfaces between models and tools, what they standardise, and the trust boundary they introduce.

Part 6Orchestration — planning, multi-agent, and control0/5

The most consequential architectural decision in this book is how much autonomy to hand over. Most systems shipped as agents should have been workflows, and most of the rest needed a human in one specific place.

6.1Workflows against agentsplanned

The decision that determines your reliability ceiling before you write a line of it.

6.2Decomposition and planningplanned

Breaking work into steps a model can finish, and replanning when step three invalidates the plan.

6.3Multi-agent patternsplanned

Supervisor, pipeline, and parallel fan-out — and the honest case that one good agent usually beats five.

6.4Human in the loopplanned

Approvals, interrupts, and resumability — placing the gate where it catches damage without destroying the point.

6.5Durable executionplanned

Long-running agents that survive a deploy, a crash, and a rate limit, without starting over.

Part 7Evaluation — the spine of the whole book0/7

Every technique in every other part is unfalsifiable without this one. Teams that cannot measure quality do not improve it; they change it and hope. This part comes seventh but should be started first.

7.1Evaluation firstplanned

Why nothing else here works without it, and the smallest version that is still real.

7.2Building your first eval setplanned

Twenty examples you wrote yourself beat a public benchmark. Where they come from and how to grow them.

7.3LLM as judgeplanned

Making a model grade a model without fooling yourself — calibration against human labels, and the biases that survive it.

7.4Offline and online evaluationplanned

Two different questions, two different instruments, and the gap between them that catches teams out.

7.5Regression testing non-deterministic systemsplanned

CI for a component that legitimately returns different text each run, without a suite that flakes.

7.6Tracing and observabilityplanned

Spans, replay, and the recorded state you need to explain a decision a week later.

7.7Turning production into eval dataplanned

Capture, triage, and labelling — the loop that makes the system improve rather than drift.

Part 8Production engineering0/6

Everything that separates a working demo from a service other people depend on. Nothing here is specific to AI except the ways it is: latency you cannot bound, capacity you do not own, and failure that returns 200 OK.

8.1Where the model runsplanned

API, managed endpoint, or your own serving stack — and what each choice forces on everything above.

8.2Latencyplanned

Streaming, time to first token, speculative UI, and the difference between fast and feeling fast.

8.3Reliabilityplanned

Timeouts, fallback models, degraded modes, and designing for the provider incident rather than around it.

8.4Rate limits and someone else's capacityplanned

Backoff, queueing, and admission control when the constraint is on a vendor's side of the wire.

8.5Cachingplanned

Exact, semantic, and prefix caching — what each is safe for, and the staleness each one hides.

8.6Shipping a change safelyplanned

Version pinning, canaries, and rolling back a prompt — because a model deprecation is a breaking change you did not schedule.

Part 9Safety, security, and governance0/6

Agents introduce a vulnerability class that has no clean fix: instructions and data arrive on the same channel. Anyone shipping an agent that reads untrusted content and holds real permissions is operating a security system, whether or not they know it.

9.1Prompt injectionplanned

The defining vulnerability of tool-using systems, why input sanitisation does not solve it, and what actually reduces the blast radius.

9.2The lethal trifectaplanned

Private data, untrusted content, and an exfiltration channel. Any two are survivable; all three is an incident waiting for a trigger.

9.3Permissions and least privilege for agentsplanned

Capability scoping, irreversible-action gates, and giving a probabilistic system credentials responsibly.

9.4Validating what comes backplanned

Schema checks, groundedness checks, and refusing to render or execute output you have not verified.

9.5Data, privacy, and retentionplanned

What leaves your boundary, what a vendor keeps, training opt-outs, and reading the terms that govern it.

9.6Governance and auditplanned

Logs that answer 'why did it do that' months later, and the record an auditor or a regulator will ask for.

Part 10Adaptation — changing the model itself0/5

The last resort, not the first. Almost everything attributed to a model limitation is a context, retrieval, or eval problem. This part is for the minority of cases where it genuinely is not — and for doing it properly when it is.

10.1When to fine-tune, honestlyplanned

The specific conditions under which training beats prompting, and the far more common ones where it does not.

10.2The dataset is the workplanned

Collection, cleaning, labelling, and holdouts. The nine tenths of a fine-tune that is not training.

10.3SFT, LoRA, and parameter-efficient tuningplanned

The techniques, what each changes, and what each costs to serve afterwards.

10.4Preference tuning — RLHF, DPO, and reward modelsplanned

What reinforcement learning from feedback is actually for, and why it is rarely the tool an application team needs.

10.5Evaluating a fine-tuneplanned

Proving it improved the target without silently regressing everything else — the suite that keeps a trained model honest.

Part 11Patterns that ship0/4

Worked architectures for the shapes that recur, each with the failure mode that kills it and the eval that catches that failure early.

11.1Assistants and copilotsplanned

In-product help that has to be right often enough to be trusted, and what to do on the turns it is not.

11.2Document and data pipelinesplanned

Extraction, classification, and enrichment at volume — where accuracy is measurable and the economics are real.

11.3Coding agentsplanned

The most mature agent category, why it works there first, and which of its lessons generalise.

11.4The anti-patternsplanned

The designs that reliably fail, collected in one place so they can be recognised before they are built.