intellimetrics Learning
AI Engineering: After the Demo Works

Pathway · a route through lessons that already exist

AI Engineering: After the Demo Works

The part of an AI engineering roadmap that begins once the demo works: everything between a demo that impresses and a system other people depend on, ending in a release somebody signs and an action somebody authorized. It teaches no Python and no API integration, and says so first. Every lesson already ships inside live trainings in the Meridian sequence; this is the route through them.

  1. 1 The exits before the build
  2. 2 Retrieval as a contract, then grounding as a claim
  3. 3 Name the system before you judge it
  4. 4 Evaluate on your data, behind a gate
  5. 5 The pager and the record
  6. 6 Only now, let it act

6 stages · 8 whole modules · 32 existing lessons · ~9.5 hours · Engineers who can already build an AI demo and now have to make it something other people depend on

Every lesson on this route is free to read and needs no account. The only budget is the hours above.

Nothing in this route is new. Every lesson below already ships inside 4 live trainings in the Meridian sequence, and every link goes to the lesson where it already lives; no URL moves for this page. This route takes 8 of the 24 modules in those trainings, 32 of their 90 lessons. It is a sampler with an argument, not a substitute: each training's own page has the rest, and the boundary section at the end says what was left out and why.

What this route does not teach — and nothing in this catalog does

A roadmap you found elsewhere probably starts with these. They are stated here first so you can decide in the first minute whether this is the route you were looking for.

  • Python, or any programming language.

    This catalog teaches you to direct AI command-line tools, which is a different skill from writing the code yourself. If you also write code, nothing below assumes you do not: the stages are about what has to surround the code, in any language. A roadmap that starts with Python is not wrong; it is answering a different question, and nothing here answers that one.

  • Calling a model from your own code — SDKs, structured outputs, function calling, token budgets.

    No training here teaches it, and this route will not pretend otherwise. What it does teach is everything that has to be true around that code before anyone depends on it.

  • MLOps as the term is usually used — training pipelines, feature stores, model serving, and which vector database to pick.

    The flagship course, AI-Powered Development, says it in its first lesson: it never trains a model. The retrieval lessons in this route are about the contract — a question goes in, authorized passages with openable provenance come back — which outlives whichever index you choose. Module 1, lesson 1: which kind of AI work this is

Before you start

You drive an AI command-line tool already — installed, authenticated, used on real work. Nothing in this route teaches the tools themselves.

That floor is Module 6: CLI Tools Setup — 5 lessons, 70 minutes, and the link opens its first one. Every one of the 4 trainings this route walks lists it first among its recommended preparation, with the same note on each: “Every lesson drives an AI CLI - install one first”. It is not counted in the 32 above, because it is the floor this route stands on rather than part of it. Skip it if you already run one of those tools on real work and can authenticate it from a fresh shell without looking anything up.

The route

6 stages in dependency order: the question before the build, the proof before the claim, the register before the evaluation, the pager before the agent. Every stop is a whole module — you cannot take half of one here, because the lessons inside each assume the ones before them. Each stage names the test for skipping it: skip only if every line is true of you.

If your roadmap budgeted one "supporting skills" stage, this is what that stage decomposes into. Where a stage's training lists an earlier stage's training as what it builds on, the catalog's own field is printed under the stage, so the order is something you can check rather than take on trust.

  1. Stage 01

    The exits before the build

    1 module · 4 lessons · 71 min

    A roadmap's retrieval stage starts with a build. This one starts with four named ways to answer the question that need no build at all, and what it costs to take each. If the question survives that table, you write the evaluation questions — and name who knows the right answers — before anything retrieves.

    Skip this stage if all of these are true
    • you have written down the questions your system must answer and the ones it must refuse
    • you have named who scores them and what the pass bar is
    • you wrote all of that before the first retrieval ran
  2. Stage 02

    Retrieval as a contract, then grounding as a claim

    2 modules · 8 lessons · 152 min

    A question goes in; authorized passages with openable provenance come back — that contract outlives whichever index you pick. Then the part the demos skip: a citation proves where text came from, never that it supports the claim.

    Skip this stage if all of these are true
    • your retriever enforces permissions where the evidence is fetched
    • retrieval is evaluated on its own before any answer exists
    • you sample-check that each cited passage actually contains the claim
  3. Stage 03

    Name the system before you judge it

    1 module · 4 lessons · 75 min

    Evaluation cannot authorize a system nobody has named. The register, the consequence tier — how much harm a wrong output can do, and so how hard the system must be tested — that a second reviewer must be able to reproduce, and what a release decision actually is. The tier is also what sizes every test in the next stage.

    In the catalog, AI Assurance: System Risk and Release Decisions lists Grounded Answers From Documents under "builds on".

    Skip this stage if all of these are true
    • every AI system you run has a named owner and a version boundary
    • each one has a consequence tier a second reviewer could reproduce
    • a named signer was assigned before testing began
  4. Stage 04

    Evaluate on your data, behind a gate

    1 module · 4 lessons · 81 min

    The supporting skill every roadmap lists and few walk. Evaluation is chosen by system type — a classifier needs a threshold and slices, a generator needs planted facts and refusals, an agent needs trajectories — run on a set the provider has never seen, by a gate that exits non-zero.

    In the catalog, AI Assurance: System Risk and Release Decisions lists Grounded Answers From Documents under "builds on".

    Skip this stage if all of these are true
    • your evaluation runs as a gate that can fail a release
    • it runs on data your provider has never seen
    • the method was chosen by system type, not by whatever the demo happened to produce
  5. Stage 05

    The pager and the record

    2 modules · 8 lessons · 131 min

    The gap a roadmap's supporting-skills bullet hides: deployment, monitoring, on-call. Not tooling — the human system around a running service. Declare at a low threshold, decide honestly whether you can staff the response, keep one record several different readers can use, and page from a burn rate — how fast the service is spending the errors its service level allows — that has a unit test rather than from a chart.

    In the catalog, Operating in Production: On-Call, Incident Command, and Reporting Clocks lists AI Assurance: System Risk and Release Decisions under "builds on".

    Skip this stage if all of these are true
    • your service has a declared incident threshold
    • it has a rota (the on-call schedule) someone actually signed up for
    • there is one record per incident that every reader writes into
    • alerts derive from a service level, not from a CPU graph
  6. Stage 06

    Only now, let it act

    1 module · 4 lessons · 60 min

    The roadmap shape this route answers — agents as one stage, the supporting skills as the stage after — is reversed here, and the catalog says why in a field printed under this stage: Guarded Automation lists Operating in Production as what it builds on, because an agent cannot safely run an operation whose telemetry and recovery were never established by people first. What this stage adds is the distinction the field keeps blurring: the envelope — the limits an action is pre-approved to run inside — can stand, but the authorization cannot.

    In the catalog, Guarded Automation: Agents That Run Operations lists Operating in Production: On-Call, Incident Command, and Reporting Clocks and AI Assurance: System Risk and Release Decisions under "builds on".

    Skip this stage if all of these are true
    • every action your agent can take is classified by impact and reversibility
    • that classification is signed by a named owner
    • every action leaves a receipt in a store the agent cannot write to

What this route does not cover

This route walks the opening of each of Grounded Answers From Documents, AI Assurance: System Risk and Release Decisions, Operating in Production: On-Call, Incident Command, and Reporting Clocks and Guarded Automation: Agents That Run Operations, never the whole. What it leaves out is owned, and each owner is one click away:

Engineers who can already build an AI demo and now have to make it something other people depend on