A map of the stack, and where the hard parts actually are

TL;DR: An applied AI system is seven pieces: input handling, context assembly, the model call, output validation, action, observation, and evaluation. The model is one box in the middle, and it is the box you spend the least time on. Almost all the engineering, and almost all the failure, lives in what surrounds it.

Where you are. You know the four shapes of the work and the five instincts to unlearn. Here is the map: the pieces every one of those shapes is built from, so that when a later module goes deep on one you already know where it sits. Nothing here is difficult; it is scaffolding for everything that follows.

The seven pieces

1. Input handling. Whatever arrives, made safe and usable: a question, an uploaded file, a webhook, a scraped page. Parsing, size limits, encoding, and treating anything user-supplied as untrusted. Ordinary engineering, and skipping it is how systems break on real data.

2. Context assembly. Deciding what goes into the prompt for this specific request: instructions, relevant documents, conversation history, tool definitions, examples. This is where retrieval lives, and it is the piece with the largest effect on output quality.

3. The model call. One API request. Choosing a model, setting the decoding knobs, handling timeouts and rate limits.

4. Output validation. Deciding whether what came back is usable before anything downstream sees it. Does it parse, does it have the required fields, are the values in the permitted set, is every claim traceable to something you supplied. On failure you go back and try differently, which is why the arrow returns to context assembly rather than stopping.

5. Action. Doing something with the result: returning it, storing it, calling a tool, updating a record. Where irreversible things happen and therefore where confirmation and idempotency belong.

6. Observation. Recording what happened: the prompt, the output, the latency, the cost, the failures. Without this you cannot debug a system whose failures are silent.

7. Evaluation. Deciding whether the whole thing is good enough, and noticing when it stops being so.

Where the time actually goes

Here is the part beginner material gets backwards. Newcomers expect the model call to be the interesting box. In practice it is the smallest piece of work in the system, often a few dozen lines that barely change after the first week.

The time goes, roughly in this order:

Context assembly takes the most. What to retrieve, how to chunk it, how to rank it, how much to include, what to drop when the budget is tight. Modules 4 and 5 are almost entirely this.

Evaluation takes the next most, and is the most commonly under-resourced. Building a set of examples, deciding what "good" means precisely enough to measure, and keeping it current.

Output validation and failure handling take more than expected, because every path needs one: unparseable output, missing retrieval, refusals, provider timeouts.

The model call itself takes almost none.

There is a useful consequence. When quality is disappointing, the instinct is to change the model. It is nearly always more productive to look one box to the left, at what you put in the context, and one box to the right, at whether you are checking the output. Model choice matters, and it is rarely the biggest lever available to you.

Reading the diagram as a course outline

The map doubles as the shape of the rest of this course, which is why it is worth twelve minutes now:

• Module 2 (done, if you came in order) is what happens inside box 3, to the extent you need it.
• Module 3 is boxes 2 and 4: writing the instructions and getting output a program can trust.
• Module 4 is box 2 at depth, which is retrieval.
• Module 5 is boxes 3 and 5 in a loop, which is what an agent is.
• Module 6 is box 7.
• Module 7 is boxes 5, 6, and everything about running this for real.

When a later lesson feels like it is in the weeds, come back to this diagram and locate it.

Box 3 is the one box this course treats as a black box on purpose. You will learn what goes in, what comes out, and how it fails, because that is what building with a model requires. If you would rather see inside it once so the decision to skip it is yours rather than ours, this is a good hour to spend.

WATCH

I Built an LLM From ScratchSyntaxA working engineer's account of opening box 3 end to end. Watch it to see what you are choosing not to build, which is a more comfortable position than treating that box as magic for the rest of the course.

Do this before moving on

Take the feature you named in the first lesson and sketch these seven boxes for it, one line each. Where does input come from, what would you put in the context, what would you validate, what happens on failure, what would you log, and how would you know it works.

You will find at least one box you cannot fill in. That box is where the project's actual risk is, and knowing it now is worth more than any amount of model comparison.

Go deeper

• RAG pipeline is boxes 1, 2, 3 and 4 assembled into the most common architecture in this field. The single most useful page to read before module 4.
• Context engineering is box 2 named as a discipline, which is exactly the reframe this lesson is arguing for.
• Guardrails is box 4 done properly, including what to do at the boundaries.
• Practice question: Design a production RAG system is this whole diagram as an interview question, and one of the most frequently asked in applied AI loops.
• Practice question: How do you trace and debug an LLM system in production? is box 6, and it is where candidates who have only built demos become obvious.

Key takeaways

• Seven pieces: input, context assembly, model call, validation, action, observation, evaluation.
• The model call is the smallest piece of engineering in the system. Context assembly and evaluation take the most time.
• Validation failures loop back to context assembly rather than terminating, which is why the arrow goes backwards.
• When quality disappoints, look at what you put in and whether you check what comes out, before changing the model.

LEARNING LAB1 of 4

Check yourself before an interviewer does. Answer from memory first.

Answer quality is disappointing. Which box should you examine before changing the model?

The model call, since decoding settings drive qualityContext assembly, since what you put in the prompt has the largest effect on outputObservation, since you cannot fix what you cannot see