The Applied AI Handbook
A six-stage handbook for shipping applied AI: decide, design, build, evaluate, operate, cost, each linked to the reference material behind it.
142 entries across 11 sections: every insight, case study, comparison, pattern, failure mode, and reference page in one browsable index.
Every entry below has a Markdown twin. Add .md to its URL to read the plain version. See /llms.txt for the full rule.
Showing all 142 entries
The twelve flagship guides. Read one front to back before diving into the reference material below.
A six-stage handbook for shipping applied AI: decide, design, build, evaluate, operate, cost, each linked to the reference material behind it.
Should we build this with AI at all: build, buy, or skip?
What shape is the system: pipeline, agent, retrieval, or none of the above?
How do we get from a working notebook to a deployable service?
How do we know it works, and how do we keep knowing after every change?
What breaks in production, and how do we see it before the user does?
What will this actually cost to run, and where does the spend hide?
What InfoSec, Privacy, Risk and Procurement ask before an AI feature ships, and the control and evidence that gets you through each gate.
The operating model for running delivery with a fleet of coding agents: six control surfaces and 22 practices, measured by the metrics that catch review debt early.
How to know an AI system works before it ships: the eval layers, plus the ways an LLM judge can quietly lie to you.
Agents fail at the tool interface more often than at the model. The design rules for building an interface that holds up in production.
How to interrogate any AI delivery partner, us included, across every gate that matters. It ends with the cases where we're the wrong call.
Where AI spend actually goes, the levers that move it, and the ways a cost estimate can already be wrong before you commit budget.
The standing regime that has to hold a year after the security review passes. Who is accountable, and how to prove the system behaves.
How to ship a change to an AI system and ramp it safely. Reverse it fast if it turns out to be wrong.
The pilot worked. How the rest of your engineers actually start using it, and the numbers that separate real adoption from seat activation.
MCPMCP is an open standard for connecting LLM applications to tools and data sources. standardizes the wire format. Identity, the catalog and the trust boundary are still yours to build, plus a ten-question gate for a new server.
What occupies a context windowThe context window is the maximum text, measured in tokens, a model can consider at once. at every step of a long run, and how to budget, compact, isolate and measure it before it fails.
Six reference architectures for the systems we actually build, one level up from the patterns below.
All architectures →Answer questions from your own documents, with a citation, instead of from whatever the model learned during training.
An agent that works a queue of cases end to end, inside a bounded loop with a human checkpoint on anything it cannot cleanly undo.
Turn inbound documents into structured records, with a person reviewing only the cases the model is actually unsure about.
An assistant embedded in a product you already ship, scoped to that signed-in user's own data and permissions.
One call site in front of every model provider, so a price change or an outage is a config change, not a rewrite.
A control plane for running many coding agents at once without them colliding on the same files or losing track of what any of it costs.
Dated articles on shipping applied AI. What breaks and how to design around it.
All insights →Regulation (EU) 2026/1744 pushed the AI Act's high-risk deadline to December 2027. What moved, what didn't, and why the old schedule still pays off.
Prompt injectionPrompt injection is untrusted input crafted to override a model's system prompt or task. can't be filtered away: the model can't reliably tell instructions from data. Here's the actual threat model and the controls that hold up.
An agent that nails the demo stalls in production because reliability compounds across steps. Here's the math, the real failure modes, and how to ship anyway.
A reproducible benchmark of cost per successful outcome across four common AI workloads, with every token assumption, price, and overhead multiplier shown.
Models change under you every few months: price, quality, and capability. Here's why we never hardcode a single provider into a client's feature.
Retrieval that looks flawless on ten clean PDFs falls apart on a real corpus. Here's why, and what evaluating retrieval quality actually requires.
Token costs that look trivial in a demo compound fast at scale. Here's how to make cost a first-class metric instead of a surprise on the invoice.
Shipping an AI feature without an eval suiteAn eval suite is a versioned set of test cases that measures whether outputs are good. in CI means every prompt tweak is a guess. Here's what an eval suite actually needs to cover.
A technically honest framework for deciding whether an AI initiative should be built in-house, bought off the shelf, or skipped entirely this year.
The gap between a working AI demo and a production feature is auth, latency, cost and fallbacks. Here's how we close it without a rewrite.
Decision guides for the architecture calls that come up on every engagement.
All comparisons →Agentic autonomy and deterministic pipelines aren't a spectrum of ambition. They trade flexibility against reliability, and here's which your workflow needs.
Self-hosting an open-weight model looks cheaper on paper than it behaves in practice. The real tradeoff against a frontier API, and when each one is right.
Retrieval and fine-tuningFine-tuning trains a model's weights on your own examples, changing its behavior directly. solve different problems but get reached for interchangeably. How to tell which one your case needs, and why we default to retrieval.
A dedicated vector database is a bigger commitment than most retrieval workloads need on day one. Here's how to tell if pgvector already covers your case.
Engagement write-ups: the problem, what we built, and the measured outcome.
All case studies →A growth-equity firm's term sheet on an 'AI-native' SaaS target got repriced after a two-week check found $1.4M of hidden re-platform cost.
A healthtech's extraction model dazzled in a notebook, then hallucinated on real traffic. An eval harness cut hallucinationsA hallucination is a confident, fluent output that is factually wrong or unsupported. from 12% to 3% in 8 weeks.
A Series B fintech's LLM spend outran revenue on one provider. Model-agnostic routing cut unit cost, vendor risk, and closed a data-residency gap.
A SaaS support platform swapped a keyword search widget for a tenant-isolated retrieval pipeline, cutting escalations and response time with no new headcount.
Named, opinionated patterns for building AI systems that survive production.
All patterns →A cheap, fast classifier reads each request and routes it to one narrow specialist agent, instead of one god-agent that carries every tool.
An agent loop runs under an explicit budget: a maximum step count, a token ceiling, and a wall-clock limit.
Chunk boundaries follow the document's own structure: headings, table rows, list items, section boundaries, instead of a fixed token count.
A cheap, high-recall first pass pulls a wide candidate set of 50 to 100 documents likely to contain the right answer.
The ingest pipeline subscribes to the actual change events of the source system, such as a webhook, a CMS publish hook, or a database trigger.
Every tool argument is defined by a strict JSON schema: enums for known value sets, validated patterns for IDs, required fields where genuinely needed.
Every tool the agent can call is scoped to the narrowest permission the task genuinely needs.
A fixed, human-labelled set of real cases runs automatically in CI on every prompt or model change.
One trace ID follows a single request across every hop it takes: retrieval, every model call, every tool call.
A cheap, fast model attempts every request first, and a validation signal decides whether that attempt is good enough to return.
The prompt is ordered with everything invariant across calls first: system instructions, tool definitions, few-shot examples.
Concrete ways production AI systems break, each with symptoms, root cause, and a fix.
All failure modes →Your retrieval index was built once at ingest and never told the source changed. When a document is edited or deleted, nothing re-embeds the new version or tombstones the old chunk. The stale vector keeps scoring well and keeps getting served with confidence, giving the reader no signal that it is out of date.
The answer exists in the source, but a fixed-size chunker cut it in half at ingest time: a table row split from its header, a procedure split from its trigger condition. Each half scores weakly on its own, the ranker drops both, and retrieval reports nothing when the document plainly contains the answer.
Cosine similarity rewards topical resemblance, not correctness. It can rank a document about the wrong product, the wrong date, or the negated version of a claim above the one that actually answers the query, because embeddings represent "about the same thing" far more reliably than they represent identifiers, negation, or numbers.
The agent has no step budget, no token budget, and no way to recognize it is stuck. A failing tool call stays in its context and keeps looking like a reasonable next thing to try, so it keeps trying variations of the same failed approach until something external (a timeout, a bill, a human) stops it.
Loose tool schemas (free-form string IDs, everything optional) give the model room to fill a gap with something plausible-looking instead of something real. With no server-side validation catching the mismatch before execution, a confidently invented ID reaches a system that expects a real one.
The tool returned HTTP 200 with an error message in the body, or an empty result set, and the agent read the absence of data as evidence rather than as a failure. Nothing in the response forced a distinction between "nothing matched" and "something broke."
As the conversation grows, a naive truncation strategy drops the oldest messages to stay under the context window. The oldest messages are exactly where the system prompt and the original task state usually live, so the agent keeps running with no memory of what it was actually supposed to do.
Without a labelled eval set, the change was graded against whatever two or three examples the author happened to have open. That is not a test. It's an anecdote. A regression anywhere outside that narrow, unrepresentative sample ships straight to production undetected.
A judge from the same model family as the generator tends to rate that family's output favorably. This is self-preference bias. A single vague rubric ('is this good?') collapses almost everything to a passing score, so the eval suite stops being able to tell a real regression from noise.
The estimate priced the happy path: one clean call per outcome. Production reality includes retries on malformed or rate-limited calls, fallbacks to a larger model when the first attempt fails, and agent loops that make several calls per completed task. Every one of those multiplies calls per successful outcome without multiplying the original per-token estimate.
A dynamic prefix (a timestamp, a per-user greeting, a reordered tool list, retrieved chunks placed before the static instructions) changes the start of the prompt on every call. Prompt caching only pays off when the shared prefix is byte-identical across requests, and one volatile token near the front is enough to bust the whole cache.
Yes. Retrieved content arrives on the same channel as instructions, so a document, ticket, or webpage crafted (or compromised) to contain commands can have the model execute them with its real tool permissions. The system has no built-in way to tell 'instruction from us' apart from 'text we retrieved.'
Free, self-serve tools and fixed-scope diagnostics for scoping AI work before you commit budget.
All tools →What AI actually costs to run in production — not the sticker price.
A fast, honest read on whether your data, infra, and process are ready to ship AI.
Which system shape you should actually build, from seven questions about the problem.
A fixed-scope, fixed-fee read on whether you’re actually ready to ship AI.
An investor-grade read on a target’s AI claims, before you commit capital.
Guides, architectures, comparisons, insights, case studies, patterns, failure modes and tools grouped by the six themes that recur across engagements.
All topics →Plain-English definitions for the AI engineering vocabulary that matters.
All glossary terms →Who we are and how an engagement runs.
No entries match that combination. Clear a filter to see more.
Source: https://customlabs.io/library/