Before you start
- Working knowledge of Python or TypeScript
- Basic understanding of HTTP APIs
- Vector search
What you will be able to do
- Decide between retrieval, fine-tuning and prompting for a given task, and state what each actually changes.
- Build a retrieval pipeline and measure its recall, rather than assuming an approximate index returns what an exact one would.
- Identify where a language model feature processes personal data, including the places that are not obvious.
- Apply the distinction between controls that reduce prompt injection success and controls that bound its blast radius.
- Assess whether a deployment has crossed from model-as-component into model-as-actor, and what obligations follow.
- Write an evaluation for a specific task that would catch a regression a benchmark would miss.
Concepts covered
Skills
- Retrieval design
- Recall measurement
- Threat modelling for LLMs
- Privacy analysis
- Evaluation design
Prove it to yourself
Poison a small corpus with a handful of documents and measure how few it takes to change the answer.
Compare an HNSW index against exact search on the same queries, and quantify what the approximation costs.
AI engineering is mostly systems engineering applied to a component that is non-deterministic, has no schema, and will confidently produce a plausible wrong answer. Almost every failure that reaches production is a systems failure, not a modelling failure: unvalidated output, unbounded cost, an agent given a credential it did not need.
This path assumes you are an engineer, not a researcher. It does not train models. It teaches you to build systems around models that behave predictably enough to run, and to know what they will do when they misbehave. Model training and fine-tuning appear only where they are the right tool, which is later and less often than most curricula suggest.
Each stage states its prerequisites, the capability you should end up with, what to read, and the check that tells you to move on.
Stage 1 - How the model behaves, and what it costs
Prerequisites. Working Python, comfort with HTTP APIs and JSON. No machine-learning background.
Outcome. You can explain, for a request you sent, how it was tokenised, what the context window constrained, why the same prompt gave two different answers, and what the request cost. You can also predict all four for the next request before sending it.
What to read and do. Call a model API directly with an HTTP client before touching a framework. Frameworks hide exactly the things you need to see at this stage. Read the reference documentation of whichever provider you are using. The OpenAI API reference and Anthropic API documentation are both complete on request and response shape, streaming, and token accounting.
Then take the parameters apart empirically. Set temperature to zero and observe that output is still not guaranteed identical. Fill the context window and observe what degrades. Count tokens for a realistic prompt and multiply by your expected request rate - most teams discover their cost model is wrong by an order of magnitude at this point, not after launch.
Ready to move on when. You can estimate the token count and cost of a feature from its prompt template and expected traffic, and you can state the latency contribution of prompt length versus generated length.
Stage 2 - Retrieval: embeddings, chunking and RAG
Prerequisites. Stage 1. Some database experience helps; see the Database Engineering path if you have none.
Outcome. You can build a retrieval pipeline over a real corpus and diagnose a wrong answer by determining whether the retriever failed to return the relevant chunk, or returned it and the model ignored it. These have different fixes and are routinely confused.
What to read and do. Read RAG architecture here for the pipeline shape and the trade-offs at each stage. Then build one over documents you know well enough to grade the answers.
The parts that actually determine quality:
| Decision | What it controls | Common failure |
|---|---|---|
| Chunk boundaries | Whether a retrieved chunk contains a complete idea | Fixed-size splitting cuts a table or a clause in half; the model then answers from a fragment |
| Chunk size and overlap | Recall against context budget | Chunks so large that three of them exhaust the window |
| Embedding model | What “similar” means for your corpus | A general model that cannot separate your domain’s near-synonyms |
| Retrieval method | Which candidates the model ever sees | Pure vector search missing exact identifiers, part numbers and error codes that keyword search would find |
| Reranking | Ordering within the retrieved set | None; the right chunk is retrieved at rank 9 and truncated away |
Instrument retrieval separately from generation. Log the retrieved chunks with every answer. Without that log you cannot tell the two failure classes apart, and you will spend weeks tuning prompts to fix a chunking problem.
Read vector and embedding weaknesses at this stage, not later. A retrieval corpus is an untrusted input path into your prompt, and multi-tenant vector stores leak across tenants when filtering is applied after the similarity search instead of within it.
Ready to move on when. You have a small labelled question set for your corpus, you can report retrieval recall separately from answer correctness, and you can attribute any given wrong answer to one of the two.
Stage 3 - Evaluation, or you are not engineering
Prerequisites. Stage 2, and a system that produces output worth grading.
Outcome. You can change a prompt or a retrieval parameter and state, with a number, whether the system got better or worse, and detect a regression before a user does.
What to read and do. This stage is the one most often skipped and the one that determines whether everything after it is engineering or guesswork. Without evaluation, a prompt change is a superstition.
Build, in order:
- A dataset of real inputs with expected outputs or grading criteria. Fifty carefully chosen cases beat five thousand scraped ones. Include the cases that already failed in production.
- Deterministic checks first: schema validity, required fields present, forbidden strings absent, citations resolving to real retrieved chunks. These are cheap, fast and catch most regressions.
- Model-graded evaluation only for what deterministic checks cannot cover, and validate the grader against human labels before trusting it. An unvalidated LLM judge is a second unreliable component measuring the first.
- A regression gate in CI, so a prompt change that drops accuracy fails the build.
Read evaluating LLM systems here for the grader families and how far an LLM-as-judge can be trusted, and NIST AI RMF for the measurement and governance framing.
Ready to move on when. You can run one command that produces a scored report, and you have used it at least once to reject a change you expected to be an improvement.
Stage 4 - Security: treat model output as untrusted input
Prerequisites. Stages 1-3, plus general application security awareness.
Outcome. For a given AI feature you can produce a threat model that names the trust boundaries, identifies where untrusted text enters the prompt, and specifies the control at each boundary. You can also demonstrate the attack against your own system before mitigating it.
What to read and do. Work through the AI security section here, which follows the OWASP Top 10 for LLM Applications. Start with prompt injection, then improper output handling, which is where injection turns into a conventional vulnerability: model output rendered as HTML, executed as SQL, or passed to a shell.
The structural point behind all of it: there is no reliable separation between instructions and data inside a prompt. Anything that reaches the context window can attempt to steer the model, including retrieved documents, tool results, file contents and web pages. Controls therefore have to sit outside the model, at the boundaries where its output is consumed.
Then, in the order they will bite you:
- Sensitive information disclosure - what goes into the prompt can come back out.
- Excessive agency - the tools and permissions you grant define the worst case, before you write the first agent.
- Unbounded consumption - cost is an availability control; a loop without a budget cap is an outage with an invoice.
- Supply chain and data and model poisoning - model weights, datasets and plugins are dependencies with provenance you probably have not checked.
- Misinformation, including package hallucination, which turns a wrong answer into a code-execution path.
- Hidden context exposure - the system prompt is not a secret and must not carry one.
Ready to move on when. You have successfully executed an indirect prompt injection against your own retrieval system via a poisoned document, then implemented and verified the control that stops it.
Stage 5 - Agents and tool use
Prerequisites. Stages 1-4. Stage 4 is not optional here; an agent is the security stage with credentials attached.
Outcome. You can specify an agent’s tools, permissions and termination conditions such that its worst-case behaviour is bounded by design and not by the model’s cooperation, and you can trace a failed run to the step that caused it.
What to read and do. Follow the Agent Development Lifecycle here for the process: define, design, build, evaluate, deploy, monitor, iterate. It is the right frame because agents fail in the gaps between those phases.
The design rules that matter more than the framework you pick:
- Each tool gets its own least-privilege credential. Read and write are separate tools.
- Any irreversible action (payment, deletion, external message) requires human approval or a compensating action, decided at design time.
- Every loop has a hard step limit, a wall-clock timeout and a token budget, enforced outside the model.
Read tool calling first if the mechanics of a tool call, and why the model never executes one itself, are not already clear: the rules above only make sense once that boundary is. Where several applications need to reach the same tools, the Model Context Protocol is the standard for exposing them consistently, though it does not remove the need to treat a third-party server as untrusted code.
Splitting work across several agents is a separate decision with its own failure modes, covered in Stage 7.
- Every step is traced with its inputs, outputs and cost. An agent you cannot replay is an agent you cannot debug.
Ready to move on when. You can state your agent’s blast radius as a concrete list of what it can alter with its credentials if it is fully compromised, and the list is short enough that you are comfortable with it.
Stage 6 - Governance and running it in production
Prerequisites. Stages 1-5, and a system with real users.
Outcome. You can produce the documentation an auditor or a customer’s risk team will ask for, and map your controls to a recognised framework instead of inventing your own.
What to read and do. Read AI governance here, then the framework relevant to your context: the EU AI Act if you place a system on the EU market, NIST AI RMF for a voluntary control framework, ISO/IEC 42001 if you need a certifiable management system, and generative AI and GDPR wherever personal data enters a prompt.
Operationally, this stage is monitoring what you evaluated in stage 3, but continuously and against live traffic: output quality sampled and graded, cost per request tracked per feature, refusal and error rates, retrieval recall on a held-out set, and drift when a provider silently updates a model behind a stable name. Version-pin models where the provider allows it. Re-run your evaluation suite on every model change as if it were a code change, because it is.
Ready to move on when. You can answer, from dashboards rather than memory: what did this system cost last week, how often did it refuse, how often was it wrong, and which model version is serving production right now.
Stage 7 - Multi-agent orchestration
Prerequisites. Stage 5, and enough production time with a single agent to have seen it fail in a way you did not predict. Reaching for multiple agents before that usually multiplies a problem instead of solving one.
Outcome. You can say what a second agent buys that a single agent with more tools does not, and you can trace a failure across agent boundaries to the handoff that caused it.
The honest framing first. Most tasks described as multi-agent are a single agent with a tool list. Splitting work across agents adds coordination, state and failure surface, so the question is what the split earns. Two answers hold up:
- Context isolation. A sub-agent with its own window can explore, read a great deal, and return a short summary. The parent never pays the cost of the intermediate reading. This is the strongest general argument, and it is a context engineering argument rather than an intelligence one.
- Different permissions. An agent that can write to production and an agent that can read customer data should not be the same principal. Splitting them makes least privilege enforceable at the boundary instead of inside a prompt.
What does not hold up. Role-playing personas as a design technique. Giving one agent the label “critic” and another “engineer” is prompt decoration unless the two have genuinely different tools, permissions or context. If both have identical access, you have paid for coordination and bought nothing.
The failure modes to design against.
| Failure | How it shows up | What bounds it |
|---|---|---|
| Coordination loops | Two agents hand work back and forth without converging | A global step and token budget across the whole run, not per agent |
| Lost context at handoff | The receiving agent lacks a constraint the sender knew | Structured handoffs with an explicit schema, not free text |
| Privilege aggregation | The union of agent permissions exceeds what any single one should hold | Audit the union, not the parts |
| Untraceable failure | A wrong answer with no way to attribute it | Trace ids propagated across every agent and tool call |
What to read and do. LangChain and LangGraph covers this layering in depth: LangGraph is the low-level graph runtime, and LangChain’s agent harness and frameworks such as CrewAI and the OpenAI Agents SDK all wrap the same underlying loop of model call, tool dispatch and state handling. Choose on checkpointing, retry semantics and tracing, not on orchestration syntax, and read the radar entry for why this sits at Assess.
Build one thing: take a task you already run as a single agent and split it so a sub-agent does the reading and returns a summary. Measure the parent’s token use before and after. If it did not fall, the split was not worth making.
Coverage gaps
These stages have no reference page here yet. Use the primary sources.
| Topic | Primary source |
|---|---|
| Fine-tuning and parameter-efficient adaptation | Hugging Face PEFT documentation |
| Self-hosted inference and serving throughput | vLLM documentation |
| Tracing and observability for LLM applications | OpenTelemetry documentation |