AI Architect Roadmap: From AI Engineer to Expert

What you'll learn: what an AI architect is responsible for, how the 15 pages of this course are organised into four parts, how to read a lesson, a case file and an "Under the hood" section, and where to start based on a 10-question self-assessment.

An AI engineer makes a feature work: a prompt, a retrieval step, a tool call. An AI architect decides whether the feature should exist in that form, what it must achieve, what it may cost, how it fails, and how the next team will understand the choice. The skills overlap, but the output is different. The engineer's output is a working component. The architect's output is a design that other people can build, review, operate and change, plus the written reasons for it.

This course is for engineers with two or more years of backend experience who have called an LLM API but have not designed a whole system, and for tech leads and engineering managers who sign off on such designs. It names the mechanism behind each recommendation so you can defend a design in a review and not only copy one.

What an AI architect owns

• Requirements. Turning "make support faster" into a quality bar, a latency target, a cost ceiling and a risk limit that can each be tested.
• Structure. Choosing the components and drawing the trust boundaries between them.
• Tradeoffs. Build, buy or configure; large model or small; queued or synchronous; automatic or approved by a person.
• Failure behaviour. Deciding in advance what the user sees when the provider is down or retrieval is wrong.
• Evidence. Evaluation sets, traces and cost records that show whether the system meets its requirements.
• Communication. Diagrams, decision records and design reviews, so the reasoning survives staff changes.

The roadmap: four parts, 15 pages

Figure 1. The four parts and 15 pages of the course

How to read this: follow the arrows left to right, each part builds on the one before, and the capstone uses every earlier page.

Read page 2 next: AI Architect mindset.

How to use the course

Every lesson from page 2 onwards has the same shape, so you always know where to look: problem, measurable outcomes, concepts, case files, decision framework, options table, failure scenarios, worked example with stated assumptions, code sample, common mistakes, exercise, takeaways, self-check and further reading.

Figure 2. How a lesson is built

How to read this: the diamond marks the one optional detour, and the self-check loops back to the concepts when an answer is wrong.

Case files

A case file is a short page about one design problem with fixed headings, from context and constraints through options, architecture, a step-by-step request, failure modes and results to tradeoffs and reusable design rules. Each carries one of two labels at the top.

• Composite scenario, not a real company. Assembled from common industry patterns. Every number is illustrative and the assumptions are listed at the end.
• Public case (sourced). Based on an organisation's own published post or paper, with every fact attributed to it. A public case is written only after the primary source has been read. If the source is too thin, the case becomes a labelled composite instead.

Under the hood

Technical lessons explain how a mechanism works in three layers: Intuition (a plain picture), Mechanism (a diagram and, where useful, a small calculation with the formula shown) and What this means for architects (the consequences for latency, cost, accuracy and failure modes).

Self-check and exercises

Each lesson ends with five questions whose answers are folded away, so you commit to an answer before you look. The "Try it" exercise takes 20 to 40 minutes and has a clear "Done when" line.

The design-review loop

The habit this course builds is one loop: requirements first, then a design with its decision records, then a review, then measurement against the original requirements.

Figure 3. The design-review loop

How to read this: no arrow leaves the review without a recorded outcome, and every miss in production re-enters the loop as a new decision.

Prerequisites

You should read Python or Java comfortably, know what a REST API and a message queue are, and have called a hosted LLM once. If a background topic below is new, read it first.

• How inference works: LLM inference explained
• Retrieval basics: RAG systems explained
• Tool protocols: Anthropic MCP introduction
• Tracing basics: LLM observability guide

Where should you start?

Answer yes or no. A "yes" means you have done it, not that you could look it up.

Part A, foundations

1. I have written a latency or quality requirement for an AI feature as a number with a stated way of measuring it.
2. I have written or reviewed an architecture decision record, and presented a design to reviewers.
3. I can draw the same system as a context view, a component view and a runtime sequence.

Part B, building blocks

4. I can estimate the latency and cost of one request from its token counts.
5. I can explain how a retrieval pipeline finds passages and how I would measure whether it found the right ones.
6. I can trace a tool call from the model to the tool and back, and say what happens when the tool fails.

Part C, production

7. I can say which prompt version and model produced any given answer in production.
8. I have designed behaviour for a provider outage or a rate limit, including what the user sees.
9. I can name two controls against prompt injection that do not rely on the model behaving.

Part D, mastery

10. I can map one AI design onto a cloud platform's networking, identity and logging.

How to score it. Start at the first part that contains a "no". If every answer is yes, skim the case index below and go to the capstone. The later pages assume you can write down what "good" means, so do not skip page 2 if statement 1 or 2 was a stretch.

Case File Index

All 41 planned case files are listed below. Titles that are links are already published; the rest are added as their lessons ship. Cases marked "Public" are based on an organisation's or researchers' published material, with every fact attributed to its source; the others are labelled composite scenarios.

The capstone (page 15) holds two full designs inside the lesson and adds no case files of its own.

Key points

• An AI architect is judged by decisions and their evidence, not by components shipped.
• Start at the first part where the self-assessment shows a gap.
• Composite case files carry illustrative numbers, never measurements.
• The design-review loop is the habit the whole course reinforces.

Last verified: 2026-10-21