The Applied AI Handbook
A six-stage handbook for shipping applied AI — decide, design, build, evaluate, operate, cost — mapping the studio's entire knowledge base onto the decisions a real project actually meets.
109 entries across 10 sections: every insight, case study, comparison, pattern, failure mode, and reference page in one browsable index.
Showing all 109 entries
The five 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 — mapping the studio's entire knowledge base onto the decisions a real project actually meets.
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?
The questions InfoSec, Privacy, Risk, and Procurement ask before an AI feature ships — what passes, the control, and the evidence you hand over.
The operating model for running real software delivery with a fleet of coding agents, first-hand from the studio's own delivery system.
Six eval layers, 24 named checks, five ways an LLM judge lies, and the numbers worth putting on a dashboard — how to know an AI system actually works before it ships.
Six interface surfaces, 24 named design rules, and five named failures — how to design the tools and context an agent actually works through.
Dated articles on shipping applied AI — what breaks, what it costs, and how to design around it.
All insights →Prompt injection 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 one anyway.
A modeled, 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 suite 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're a tradeoff between flexibility and reliability. Here's how to tell which one your workflow actually needs.
Self-hosting an open-weight model looks cheaper on a per-token spreadsheet than it behaves in practice. Here's the actual tradeoff between running your own weights and calling a frontier API, and when each one is right.
Retrieval and fine-tuning solve different problems and get reached for interchangeably anyway. Here's how to tell which one your use case actually needs, and why we default to retrieval first.
A dedicated vector database is a bigger operational commitment than most retrieval workloads need on day one. Here's how to tell whether pgvector already covers your use case, and what actually forces the migration.
Engagement write-ups — the problem, what we built, and the measured outcome.
All case studies →A growth-equity firm had a term sheet out on an 'AI-native' SaaS target. A two-week technical readiness assessment surfaced $1.4M of undisclosed re-platform cost and a vendor dependency that would triple at projected volume, and repriced the deal.
A mid-market healthtech had a document-extraction model that dazzled in a notebook and hallucinated on real intake traffic. An eval harness and confidence gating took hallucinations from 12% to 3% and shipped it in 8 weeks.
A Series B fintech was scaling LLM spend faster than revenue on a single provider. A model-agnostic routing layer cut unit cost, killed vendor concentration risk, and met a data-residency requirement its incumbent couldn't.
A mid-market SaaS support platform replaced a keyword search widget with a tenant-isolated retrieval pipeline, cutting escalations and first-response time without a headcount increase.
Named, opinionated patterns for building AI systems that survive production.
All patterns →A cheap, fast classifier reads the incoming request first and routes it to one of several narrow, single-purpose agents — each holding only the tools, context, and instructions its job needs — instead of a single god-agent carrying every tool definition and every rule for every possible request.
An agent loop runs under an explicit budget — a maximum step count, a token ceiling, and a wall-clock limit — plus a termination contract that forces every run to end in one of a small number of named states: success, failure, or escalation.
Chunk boundaries follow the document's own structure — headings, table rows, list items, section boundaries — instead of a fixed token count, and each chunk carries its parent heading or identifying context in its own body.
A cheap, high-recall first pass — vector search, optionally fused with keyword search — pulls a wide candidate set of 50 to 100 documents likely to contain the right answer somewhere.
The ingest pipeline subscribes to the actual change events of the source system — a webhook, a CMS publish hook, a database trigger — instead of re-crawling on a fixed schedule.
Every tool argument is defined by a strict JSON schema — enums for known value sets, validated patterns for IDs, required fields wherever the tool genuinely needs them — with no free-text catch-all surface.
Every tool the agent can call is scoped to the narrowest permission the task genuinely needs, and any action that can't be cleanly undone — a refund, a delete, an external message — requires an explicit human confirmation before it executes, not just a plausible-looking model decision.
A fixed, human-labelled set of real cases — each with a specific, checkable expected property, not a vibe — 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 — logged with enough detail to reconstruct exactly what happened after the fact.
A cheap, fast model attempts every request first.
The prompt is ordered with everything invariant across calls first — system instructions, tool definitions in a fixed serialization order, few-shot examples — and everything that changes per request — retrieved chunks, user input, timestamps — placed last.
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, so the stale vector keeps scoring well and keeps getting served — confidently, and with no signal to the reader 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, and 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 — because 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 — and 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 — which 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 — self-preference bias — and 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, and 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, and prompt caching only pays off when the shared prefix is byte-identical across requests. 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, and 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.
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.
Insights and case studies 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, what we build, and how an engagement runs.
No entries match that combination. Clear a filter to see more.