The customer systems manual / September 2026
Design, ship, and operate AI systems in customer environments.
The demo works. Now the customer needs tenant isolation, a recovery path for failed writes, and a deployment their team can run. This is the engineering work that follows the architecture diagram.
95-page PDF + runnable Python companion. Included with active Premium access.
Already a member? Sign in to download
16 chapters / 4 engagements / 5 clinics
For an FDE, system design starts with a customer promise and ends with evidence that another team can operate the result. A retrieval benchmark cannot tell you whether a revoked document will still reach a user. An architecture box labelled “human review” cannot tell you whether the queue fits the available staff.
Work through the decisions that close those gaps. Write acceptance tests. Calculate the memory and review budgets. Bind approval to the exact proposed action. Define what the service does after a timeout, during an outage and when the original engineer leaves.
Use it as a deployment reference or to strengthen the production reasoning behind an FDE, FDSE or Forward Deployed AI Engineer system design interview.
Open the book
These are complete pages from the downloadable PDF. Open any preview to read the diagrams and annotations at full size. Each preview includes a reading note explaining what to look for.
Page 8 / Sample
Trace a promise through the control that enforces it and the evidence that proves it.
Open the page at full size ↗
Page 38 / Sample
Follow the state transitions when the provider may have succeeded but the response is lost.
Open the page at full size ↗
Page 72 / Sample
Make code retrieval use a coherent generation, including unchanged artifacts and deletions.
Open the page at full size ↗
The design changes with the customer
Follow each original teaching scenario from the customer brief into architecture, capacity and failure handling. Names, workloads and numerical inputs are synthetic; they are not reports of real deployments.
Engagement A / Industrial operations / pages 55–58
The right manual can still be the wrong evidence.
A technician needs instructions for a specific equipment variant. Design ingestion and retrieval around document versions and current permissions, then carry those constraints through citations and the final response.
You work through: Evidence-generation architecture, retrieval scope and release checks.
Engagement B / Document workflows / pages 59–62
Extraction accuracy has to fit the review team's capacity.
Connect packet extraction to evidence review, immutable approval and a durable registry write. Work through the staffing arithmetic and the recovery path when a write succeeds but its response disappears.
You work through: Review-capacity calculation, approval boundary and write-recovery design.
Engagement C / Restricted networks / pages 63–66
The site must keep working when the network stops.
Define what a local evidence package contains, how long its authorization remains usable and which actions the disconnected mode permits. Reconcile versions and conflicts when the connection returns.
You work through: Package lifecycle, access-lease policy and reconnection rules.
Engagement D / Batch processing / pages 67–70
A completed job is a manifest you can reconcile.
Plan a 96,000-record teaching workload against an eight-hour window. Calculate worker and token demand, preserve per-record versions, and account for retries and unresolved items before declaring completion.
You work through: Capacity worksheet, record-state model and completion criteria.
Inside the 95-page guide
Sixteen core chapters lead into the engagements, five focused engineering clinics and a workbook. Each chapter connects a customer obligation to a mechanism and a way to check it.
Pages 7–18
Acceptance criteria, observable evidence and assumptions that still need an owner.
Prompting, retrieval, model selection and when adaptation earns its cost.
Versions, tombstones, connector repair and live index changes.
OCR, tables, source regions and the human review queue.
Pages 19–30
Lexical and dense retrieval, reciprocal rank fusion and evidence eligibility.
Token reservations, memory, citations and context failure modes.
Routing, asynchronous task APIs, streaming and reconnection.
Weight memory, KV cache, concurrency and cost per accepted task.
Pages 31–42
Bursts, queueing, deadlines and retry allowances.
Cache scope, permission generations and revocation before delivery.
Durable intent, approval binding, unknown outcomes and reconciliation.
Task slices, forbidden effects, confidence bounds and release gates.
Pages 43–54
Identity, tenant isolation, generated SQL and independently enforced policy.
Customer-hosted infrastructure, restricted networks and offline modes.
Observability, service-level objectives, incident diagnosis and containment.
Rollout, rollback, source repair and an operator who can run the system.
Pages 71–80
Publish coherent snapshots, retain code provenance and decide whether graph structure improves the task.
Turn a parts request into a constrained query plan and examine ranking with NDCG.
Separate preparation, review and delivery; calculate when the approved-item queue needs refilling.
Recheck authority on resume, constrain tool protocols and reason about circuit breakers and retries.
Put LoRA, QLoRA, runtime reproducibility and artifact provenance inside a release contract.
The workbook adds acceptance and failure worksheets, a lab route, a glossary and links back into the learning library. Nine pages of references record the technical sources.
Included / Python companion
Nine lab tracks let you inspect revisions and tombstones, scope a cache, reserve context, budget queue deadlines, reconcile durable actions and test snapshot completeness. Ranking and release gates make their assumptions executable.
The distributed ZIP passed 78 tests and detected nine deliberately broken implementations. Run it locally with Python 3.10 or later. No API keys, paid model calls or GPU are required.
A useful lab has a failure it can catch
These are deterministic teaching models. Passing them does not verify a real provider, a model's answer quality or a concurrent production deployment.
The PDF links directly to concepts, interview questions and courses. Use this same reading path online when a design exposes a gap. Each resource keeps its displayed access level.
Chapters 01–04
Chapters 05–07
Chapters 08–10
Chapters 11–13
Chapters 14–16
Clinics A–E
It is the work of turning a customer requirement into a system that can be accepted, deployed, operated and repaired in that customer's environment. For an AI deployment, that spans data contracts, retrieval and inference, permissions, external actions, evaluation, capacity, incident response and handoff. This guide follows those responsibilities through one lifecycle.
Software engineers, AI engineers and Forward Deployed Engineers who can already read code and want to reason about customer deployments. It also supports FDSE and Forward Deployed AI Engineer interview preparation when you need to defend how an architecture behaves under production constraints. It assumes basic familiarity with APIs, databases and Python.
The Agentic System Design Round is a compact collection for rehearsing ten worked design scenarios. Systems Engineering for FDEs is a 95-page engineering manual organized around the deployment lifecycle, with 16 chapters, four extended customer engagements, five engineering clinics and nine executable lab tracks. Both are included with Premium.
Yes. It covers permission-aware retrieval, context budgets, routing, KV-cache memory, scoped caching, durable agent actions, evaluation and deployment. Those mechanisms sit alongside data ingestion, review capacity, security, offline operation and handoff, so you can connect a model decision to the surrounding system.
The 95-page PDF and a separate Python companion ZIP. The PDF contains 22 original technical figures, four worked engagements, five clinics, worksheets and 34 primary technical references. Clickable links connect the material to the site's concepts, interview questions and courses. Existing Premium members do not need a separate purchase.
Yes. The companion uses Python 3.10 or later and the standard library, with no model calls or API keys. Its nine lab tracks cover contracts such as revisions, retrieval and caching, context arithmetic, evaluation gates, queues, durable actions, snapshots and ranking. The distributed archive passed 78 tests and detected nine deliberately introduced defects.
No. Customer names, workloads and numerical inputs are synthetic teaching examples. The executable checks validate selected arithmetic and modelled contracts; they do not establish real provider behavior, LLM quality or production concurrency. Primary references are cited for the technical mechanisms.
Yes. Three complete sample pages, the chapter outline, engagement summaries and the online study path are public. Sign in with active Premium access to download the complete PDF and companion. You may retain your downloaded copy for personal study under the site's terms.
AI tools assisted drafting, research organization, illustration and verification. The publisher reviewed the guide. Checks covered source links, worked calculations, the extracted companion archive, PDF links and page layout. These checks are evidence about this educational artifact, not certification of a production system.
