Fundamentals of Generative AI

Chapter 04 — Foundation Models, Tokens, Embeddings, and the FM Lifecycle

Certification Blueprint

Field	Coverage
Exam	AWS Certified AI Practitioner (AIF-C01), exam guide v1.1
Domain	Content Domain 2 — Fundamentals of GenAI
Exam weight	24% of scored content
Task statement	2.1 Explain the basic concepts of generative AI (GenAI)
Objectives	2.1.1 foundational concepts · 2.1.2 use cases · 2.1.3 the FM lifecycle

What This Chapter Covers

Domain 1 is behind you — three chapters, 20% of the exam. This is the first chapter of Domain 2, which is 24% and the second-heaviest domain on the paper.

The change in character matters. Domain 1 rewarded classification: place the system, read the constraint, pick the technique. Domain 2 rewards precision. Several questions turn entirely on whether you know exactly what a word means — and these are words you almost certainly already use.

Domain 1 asked	Domain 2 asks
Is this AI, ML, deep learning or generative?	What is a foundation model, precisely?
Which learning type does the data permit?	What is the model actually reading? (tokens)
Which technique fits the output shape?	How does a machine represent meaning?
What does the ML pipeline produce at each stage?	What does the FM lifecycle produce at each stage?

This chapter takes the first three of Task 2.1's six objectives. Token-based pricing and context engineering are Chapter 05; agentic AI and MCP are Chapter 06.

What Is a Foundation Model?

A foundation model is a large model pre-trained on broad, general data that can be adapted to many downstream tasks without being trained specifically for any of them.

Two ways to hold it:

• A graduate hire rather than a specialist contractor. The graduate arrives knowing a great deal in general and is pointed at your particular job afterwards. The contractor arrives knowing your job and nothing else.
• A general-purpose kitchen rather than a bread machine. The bread machine makes excellent bread and nothing else. The kitchen makes anything, slightly less perfectly, and needs instruction.

The word doing the work is foundation. It is a base that other things are built on, not a finished product — which is why every later chapter in Domain 3 is a different way of building on top of it.

Note what is not the defining property: size. Large models existed before foundation models. What distinguishes a foundation model is adaptability without task-specific training.

Tokens: the Unit Everything Is Counted In

A token is the chunk of text the model actually processes. It is not a word and it is not a character — it is a learned sub-word unit.

Text	Roughly	Why
the	1 token	Common word, learned whole
unhappiness	~3 tokens	Rare; splits into sub-words
AIF-C01	several tokens	Digits and punctuation split

A rough guide for English: about four characters per token. Treat that as a rule of thumb rather than a formula — it does not hold for code, identifiers, or many other languages.

What to remember from this diagram: the model never sees your letters. It receives a list of integers, and it counts every one of them — in both directions. Output tokens are counted just as input tokens are.

Situation	What happens in tokens	Consequence
A prompt in fluent English	Efficient — most words are single tokens	Fewer tokens for the same meaning
A prompt full of product codes	Each code fragments	More tokens for the same meaning
A long conversation	Prior turns are re-sent each time	Token count grows as the conversation grows
A model asked for a long answer	Output tokens counted too	Output is not free

That last row is where most people's mental model is wrong. Nothing is remembered for free, and nothing is emitted for free.

Chunking

Chunking is splitting a long document into smaller pieces before it is processed or stored.

There are two reasons, and the exam uses both:

Reason	What it solves
A model processes a bounded amount at once	A 400-page manual cannot be handed over whole
Retrieval should return the relevant part	A whole manual answers no question usefully

Two ways to hold it:

• A book with chapters and an index — you fetch the chapter, not the library.
• Cutting a long interview into clips — each clip stands alone and can be found on its own.

Both failure directions exist. Chunk too large and you retrieve a great deal of irrelevant material alongside the answer. Chunk too small and you retrieve a sentence that no longer makes sense without the paragraph around it.

Embeddings and Vectors

An embedding is a representation of meaning as a vector — a fixed-length list of numbers.

Term	Precisely
Vector	An ordered list of numbers of fixed length. Implies no meaning by itself
Embedding	A vector produced so that position encodes meaning
Vector space	The space those vectors live in, where distance means relatedness

Every embedding is a vector. Not every vector is an embedding.

Two ways to hold it:

• Map coordinates. Two cities close in latitude and longitude are close on the ground, and the numbers themselves carry the relationship rather than describing it.
• A wedding seating plan. Guests with things in common are seated near each other, so the seat number encodes the relationship.

What to remember from this diagram: an embedding is not a summary and not a compressed copy. You cannot read the original text back out of it. It is a position, and the only operation a position enables is comparison.

Because meaning becomes distance, meaning becomes computable:

Capability	What it relies on
Search by meaning rather than keyword	"cheap flights" finds "budget airfare" — no shared word
Recommendation	Items near the ones a user liked
Grouping related documents	Positions that cluster together
Finding the relevant chunk to feed a model	The chunk nearest the question

Keyword search matches strings. Embedding search matches meaning. That is the exam-relevant difference.

The Transformer, and What Makes an LLM

A transformer is the model architecture behind current large language models. Its defining capability is relating every token to every other token in the input, so that meaning depends on context rather than on position alone.

A transformer-based large language model (LLM) is a transformer trained on a very large body of text.

The word	What it contributes
Large	Trained on a very large corpus, with very many parameters
Language	The domain it models is text
Model	It predicts — it does not look up

"Bank" in river bank and in savings bank is the same token with a different meaning. Relating tokens to each other is how that gets resolved. And note the third row: an LLM is not a database. It does not retrieve stored sentences; it predicts.

Prompt Engineering — the Term

Prompt engineering is the practice of structuring the input given to a model so that the output is more useful — supplying context, instruction and constraints rather than a bare question.

That definition is the whole of this chapter's requirement. Objective 2.1.1 lists prompt engineering among terms to define. The constructs, techniques, best practices, risks and versioning strategies belong to Objective 3.2 and are taught in Chapter 10. Being able to define it is examined here; being able to do it is examined later.

Three Model Families

Family	Handles	Typically produces
Transformer-based LLM	Text in, text out	Summaries, translations, code, replies
Multi-modal model	More than one modality in — commonly text and images	Usually text about the other modality
Diffusion model	Text in	Images, video, audio — generated by removing noise step by step

Diffusion works backwards from noise. It starts with random noise and repeatedly removes noise until an image consistent with the prompt remains. That mechanism makes the family unmistakable.

Be careful with multi-modal: the "multi" describes what the model can take in, commonly text and images together. It does not mean the model emits several kinds of output. If a question requires an image to be produced, that points at a diffusion model.

What to remember from this diagram: read the modalities, not the industry. What goes in and what must come out — that pair selects the family, and neither the sector nor the size of the company appears anywhere in the decision.

GenAI Use Cases

Objective 2.1.2 names these:

Use case	What the model is doing
Image, video and audio generation	Producing new media from a description
Summarization	Compressing text while preserving meaning
AI assistants	Multi-turn help grounded in context
Translation	Meaning preserved across languages
Code generation	Producing code from a description
Customer service agents	Handling enquiries conversationally
Search	Retrieving by meaning, not keyword
Recommendation engines	Suggesting items related to a preference

What to remember from this diagram: two of the eight named use cases are not generation at all. Search and recommendation are comparison problems and they run on embeddings. They appear in a generative-AI objective because embeddings come from the same family of models — and noticing this is what stops you reaching for a large language model on every Domain 2 question.

The FM Lifecycle

Objective 2.1.3 names seven stages:

#	Stage	The question it answers
1	Data selection	What will the model learn from?
2	Model selection	Which base model do we start from?
3	Pre-training	How does it gain general capability?
4	Fine-tuning	How does it fit our task or domain?
5	Evaluation	Is it good enough to ship?
6	Deployment	How is it made callable?
7	Feedback	What does real usage tell us?

This is not the AI/ML pipeline from Chapter 03. That pipeline describes a project — it starts at a business goal and ends at monitoring in production. This lifecycle describes the model itself. They overlap around evaluation and deployment, and conflating them is a reliable way to lose an ordering question in either domain.

What to remember from this diagram: the loop is the point. Feedback is a stage, not an afterthought — it is what sends a deployed model back for re-tuning. A lifecycle drawn as a straight line is wrong here for the same reason it was wrong in Chapter 03.

The objective says describe, so know what each stage produces, not just its name:

Stage	Produces
Data selection	A chosen, scoped corpus
Model selection	A named base model to start from
Pre-training	A general-capability model
Fine-tuning	A model adapted to a task or domain
Evaluation	A pass or fail against a defined bar
Deployment	A callable model
Feedback	Signals from real use that drive the next cycle

Ordering questions live here. Recall from Chapter 01 that ordering questions require the correct responses in the correct order, with no partial credit — so knowing seven names in the wrong sequence scores zero. Pre-training before fine-tuning is the pair most often inverted.

Decision Rules and Exam Signals

Rule 1 — define before you apply. In Domain 2, state what the term is before reaching for what it is used for. Several questions test only the definition.

Rule 2 — tokens are counted in both directions. Input and output. Any reasoning that counts only the prompt is incomplete.

Rule 3 — an embedding is a position, not a summary. Its only capability is comparison.

Rule 4 — modality selects the model family. What goes in, what must come out. Not the industry.

Rule 5 — "multi-modal" describes the input. If an image must be produced, that is diffusion.

Rule 6 — the FM lifecycle is about the model; Chapter 03's pipeline is about the project. Check which one a question is asking about before sequencing anything.

Distractor Patterns

Pattern	What it looks like	How to defuse it
Token as word	"1,000 words is 1,000 tokens"	Tokens are sub-word units; rare strings cost more
Output tokens forgotten	Counting only the prompt	Both directions are counted
Embedding as summary	Treating a vector as compressed text	It is a position; it enables comparison only
Diffusion for text	A diffusion model offered to summarise	Diffusion generates media, not prose
Multi-modal means multi-output	Assuming it must emit images	It takes more than one modality in
Fine-tuning before pre-training	Lifecycle stages reordered	Pre-training precedes fine-tuning, always
Search treated as generation	An LLM offered where embeddings fit	Search and recommendation are comparison problems

The first two share a root cause: thinking of tokens as a description of the prompt rather than as the unit of account for the whole exchange.

Scenario Walkthrough

A legal publisher holds 90,000 case documents, some over 300 pages. It wants lawyers to find relevant passages by describing a situation in their own words rather than guessing keywords, and it wants a short plain-English précis of each passage found. It also wants a cover illustration generated for each published digest.

Requirement	Reading	Decision
300-page documents must be processed	Too large to handle whole	Chunking first
Find by description, not keyword	Meaning compared, not strings matched	Embeddings and vector similarity
Short plain-English précis	Text in, text out	Transformer-based LLM — summarization
Cover illustration generated	Text in, image out	Diffusion model

One scenario, four different concepts — and only two of the four are generation.

The trap is answering the whole scenario with "an LLM". Retrieval here is a comparison problem, and chunking is a precondition rather than a technique choice.

Key Concepts

Term	Definition
Foundation model (FM)	A large model pre-trained on broad general data that can be adapted to many downstream tasks without being trained specifically for any of them
Token	The chunk of text a model actually processes — a learned sub-word unit, neither a word nor a character
Chunking	Splitting a long document into smaller pieces so it can be processed and so retrieval can return the relevant part
Vector	An ordered list of numbers of fixed length; implies no meaning by itself
Embedding	A vector produced so that its position encodes meaning, making relatedness measurable as distance
Vector space	The space embeddings occupy, in which distance between positions corresponds to relatedness in meaning
Transformer	The model architecture that relates every token to every other token, so meaning depends on context
Large language model (LLM)	A transformer trained on a very large body of text; it predicts rather than looks up
Multi-modal model	A model that accepts more than one modality as input, commonly text and images together
Diffusion model	A model that generates images, video or audio by starting from random noise and repeatedly removing it
Prompt engineering	The practice of structuring a model's input — context, instruction and constraints — so the output is more useful
Pre-training	The lifecycle stage in which a model gains general capability from broad data
Fine-tuning	The lifecycle stage in which a pre-trained model is adapted to a specific task or domain
FM lifecycle	Data selection, model selection, pre-training, fine-tuning, evaluation, deployment, feedback

Revision Flashcards

Say the answer aloud before revealing it.

1. What distinguishes a foundation model — and what does not? → Adaptability to many downstream tasks without task-specific training. Size is not the defining property; large models existed before foundation models did.

2. What is a token? → The chunk of text a model actually processes — a learned sub-word unit. Not a word and not a character. Roughly four characters per token in English, as a rule of thumb only.

3. Are output tokens counted? → Yes. Both input and output are counted. Nothing is emitted for free, and in a multi-turn conversation prior turns are re-sent, so the count grows with the conversation.

4. What two problems does chunking solve? → A model processes a bounded amount at once, so very long documents cannot be handed over whole; and retrieval should return the relevant part rather than the entire document.

5. What is the difference between a vector and an embedding? → A vector is any fixed-length ordered list of numbers. An embedding is a vector produced so that its position encodes meaning. Every embedding is a vector; not every vector is an embedding.

6. Can you recover the original text from an embedding? → No. It is a position in vector space, not a summary or a compressed copy. The only operation it enables is comparison.

7. What does keyword search do that embedding search does not, and vice versa? → Keyword search matches strings. Embedding search matches meaning, so "cheap flights" can find "budget airfare" despite sharing no word.

8. What does the transformer architecture contribute to an LLM? → It relates every token to every other token in the input, so meaning depends on context rather than position alone.

9. Does "multi-modal" mean the model produces several kinds of output? → No. It describes what the model accepts as input, commonly text and images together. Output is typically text about the other modality. If an image must be produced, that is a diffusion model.

10. How does a diffusion model generate an image? → It starts from random noise and repeatedly removes noise until an image consistent with the prompt remains — it works backwards from noise.

11. Which two of the eight Objective 2.1.2 use cases are not generation? → Search and recommendation engines. Both are comparison problems that run on embeddings.

12. Name the seven FM lifecycle stages in order. → Data selection, model selection, pre-training, fine-tuning, evaluation, deployment, feedback.

The Four-Beat Answer

The core question this chapter prepares you for: "Explain what a foundation model is and how one comes to be useful for a specific job."

Four beats, checked in this order. Missing a beat is a failure state — you will be probed on whichever one you skipped.

1. What it is — a large model pre-trained on broad general data, adaptable to many downstream tasks without task-specific training. Name adaptability rather than size as the distinguishing property.
2. What it operates on — tokens, which are learned sub-word units rather than words, counted in both directions. This is the unit that every later cost and capacity conversation is built on.
3. How it represents meaning — embeddings, which are vectors whose position encodes meaning, so relatedness becomes a measurable distance. Say what that makes possible: comparison, and therefore search and retrieval.
4. How it becomes useful — the lifecycle: data selection, model selection, pre-training, fine-tuning, evaluation, deployment, feedback. Name what the stages produce, and name the feedback loop, because a lifecycle without one is a description of a project that has already failed.

A strong answer names the unit and the loop. A weak answer describes capability.

Why This Helps You

On the job: the token is the unit that governs both cost and capacity in every foundation model system you will touch. Teams that treat tokens as words size their systems wrongly, and they discover it in production when a conversation grows.

In interviews: "what is an embedding?" is a standard screening question, and "it's a vector representation" is the answer everyone gives. Saying that it is a position whose only capability is comparison — and that you cannot read the text back out — signals that you have actually built with them.

On the exam: Domain 2 is 24% of scored content, and Task 2.1 questions frequently test the definition alone. The habit of stating what a term is before reaching for what it is used for is worth more marks here than anywhere else on the paper.

Chapter Checklist

• I can define a foundation model without using the word "big" as the distinguishing property
• I can say what a token actually is, and why it is neither a word nor a character
• I can state that both input and output are counted in tokens
• I can explain what chunking solves, and the cost of chunks that are too large or too small
• I can define an embedding as a vector whose position encodes meaning
• I can explain why an embedding cannot be read back as text
• I can say what embeddings make possible that keyword matching cannot
• I can explain what the transformer architecture contributes to an LLM
• I can define prompt engineering as a term, without straying into technique
• I can separate transformer-based LLMs, multi-modal models and diffusion models by modality
• I can name all eight Objective 2.1.2 use cases and say which two are comparison rather than generation
• I can sequence the seven FM lifecycle stages and say what each one produces

After the Chapter

1. Complete student/project.md — parts 15-18 of the AI/ML Decision Sheet you began in Chapter 01. Bring the same sheet; do not start a new one.
2. Take student/quiz.md closed-book, then review the reasoning for every question you guessed, including the ones you got right.
3. Open the official v1.1 exam guide's Domain 2 page and confirm you can attach a concept from this chapter to each of the first three bullets under Task Statement 2.1.
4. Next chapter: Chapter 05 — Token-Based Pricing and Context Engineering (Domain 2, Objectives 2.1.4 and 2.1.5). You now know what a token is; Chapter 05 turns that into money and latency, and introduces the role of context engineering in foundation model applications. It is short in objectives and heavy in consequence.

Chapter 05 — Token-Based Pricing and Context Engineering

Certification Blueprint

Field	Coverage
Exam	AWS Certified AI Practitioner (AIF-C01), exam guide v1.1
Domain	Content Domain 2 — Fundamentals of GenAI
Exam weight	24% of scored content
Task statement	2.1 Explain the basic concepts of generative AI (GenAI)
Objectives	2.1.4 the token-based pricing model and its effect on cost and performance for inference · 2.1.5 the role of context engineering in FM applications

What This Chapter Covers

Chapter 04 gave you the unit. This chapter attaches the consequences.

Chapter 04 established	Chapter 05 asks
What a token is	What a token costs, and what it costs you in time
That both directions are counted	Which direction moves the bill, and which moves the latency
That models have a bounded input	How to spend that bound deliberately
That prompt engineering is a term	What the larger discipline around it actually is

Two objectives is the smallest brief in Domain 2, and it is not a light chapter. These are the two objectives most people are confident about before they start — almost everyone has used an AI assistant, and that experience feels like understanding. It is not. Experience teaches you that replies cost something and that long conversations feel slower. It does not teach you which leg is metered at which rate, or why a long conversation costs more per request rather than merely more in total.

Every wrong answer in this pair of objectives sounds economical. That is the thing to watch for.

Token-Based Pricing

Token-based pricing charges for the quantity of tokens processed, counted separately for what goes in and what comes out. Not per request. Not per user. Not per unit of time.

Two ways to hold it:

• A metered utility. You are not billed for having the tap; you are billed for the water that goes through it. A request that moves more text costs more, and an idle account costs nothing.
• Postage charged by weight, at a different rate in each direction. The envelope you send and the reply you receive are both weighed, and the return leg is charged at the higher rate.

The unit of account is not the question you asked. It is the volume of text on both legs of the exchange.

The anatomy of a billed request

What to remember from this diagram: the user's question is usually the smallest part of what you pay for. Three of the four input components — the system instruction, the conversation history and the retrieved context — were added by the application, not by the person typing.

Input and output are not priced the same

Leg	What it contains	Typical rate
Input	System instruction, conversation history, retrieved context, user message	Lower per token
Output	Everything the model generates	Higher per token

The reason matters more than the fact, because it explains two things at once:

• Input is read in one pass. The model takes in the whole prompt before it begins.
• Output is produced one token after another, each one depending on the ones before it.

That single mechanical difference is why the output leg is typically dearer and why output length dominates how long the user waits. Learn it once, apply it twice.

The exam never asks you for a price. Published rates change and vary by model and region. What is examinable is the shape of the model: metered, two-sided, asymmetric.

What actually drives the bill

Driver	Why it grows	Who added it
A long system instruction	Resent in full on every request	The application
Conversation history	Prior turns resent every turn	The application
Retrieved context	Every injected chunk is input tokens	The application
Few-shot examples	Repeated on every call	The application
The user's message	Usually short	The user
The model's answer	Billed at the higher rate	The design

Five of the six are decisions rather than traffic. Cost is a design output, not a usage fact.

The system instruction row is the one that surprises people. A long standing instruction looks like configuration and behaves like a recurring charge — it is resent, in full, on every single request.

The conversation that costs more every turn

What to remember from this diagram: the model is stateless. What looks like memory is the whole conversation being sent again. So a long chat costs more per request, not merely more in total — and that per-request growth is the version the exam asks about.

Inference Performance

The objective says "cost and performance for inference". Performance here means latency, not accuracy. A question about whether the answers are good belongs to a different objective.

Number	What it measures	Moved mainly by
Time to first token	The wait before anything appears	Input length
Total response time	The wait until the answer is complete	Output length
Throughput	How much work the system sustains overall	Concurrency and request size

A scenario that mentions users waiting is asking about this table. Which of the first two rows it means depends on one word — whether the answer is slow to start or slow to finish.

What to remember from this diagram: reading the prompt happens in one pass; writing the answer happens one token at a time. Prefill governs the time to first token and is driven by input length. Decode governs the rest and is driven by output length. That is why output length is the stronger lever on total wait.

The levers, and what each one costs you

Lever	Moves	Trade-off
Shorten the system instruction	Cost	Less standing guidance
Cap the response length	Cost and latency	Truncated or terser answers
Inject fewer retrieved chunks	Cost and time to first token	Risk of missing the relevant passage
Summarise conversation history	Cost	Older detail is lost
Choose a smaller model	Cost and latency	Capability
Batch non-urgent work	Cost	Not available when a user is waiting

No lever is free. Every one trades tokens for something the system used to have. Naming a lever without naming its trade-off is half an answer.

Diagnose before you pull a lever

Symptom	What is actually happening	The reading
"Cost tripled but traffic was flat"	Whole conversations kept; each turn resends everything before it	Growth is in history, not usage
"The first word takes forever"	Many retrieved chunks injected per question	Long input delays prefill
"We shortened every prompt and the bill barely moved"	Long structured reports requested	The spend was on the output leg all along

The third is the expensive one — real effort spent on the wrong side of the meter.

Context Engineering

Context engineering is the practice of deciding what information occupies the model's context window on each request, and how it is arranged, so that the model can do the job.

Two ways to hold it:

• Packing a case for a specialist you have hired for one hour. They are extremely capable and know nothing about your situation. What you put in the case decides what they can do — and the case is only so big.
• A one-page brief for a stand-in presenter. Give them the wrong page and they will present the wrong thing confidently. Give them forty pages and they will not find the point.

The model brings general capability. Context supplies the particulars — and every particular is paid for, on every request.

What occupies the context window

What to remember from this diagram: the window is refilled from empty on every request. Nothing carries over by itself — which is exactly why history has to be resent, which is exactly why a long conversation costs more each turn. The stateless fact and the growing bill are the same fact seen twice.

Note the last occupant: room has to be reserved for the answer, which shares the same window. A request that fills the window with input leaves nothing to answer into.

Context engineering is not prompt engineering

	Prompt engineering	Context engineering
Governs	The wording of the instruction	The whole payload sent with it
Asks	How do I phrase this?	What should be in here at all?
Decides	Tone, structure, examples, constraints	What to retrieve, what to keep, what to drop
Fails as	A vague or ambiguous instruction	A window full of the wrong things
Examined in	Task 3.2 — Chapter 10	This objective, 2.1.5

Prompt engineering writes the instruction. Context engineering decides what surrounds it. One is a component of the other, not a synonym for it — and they are examined under different objectives in different domains.

Assembling the context

What to remember from this diagram: two questions do most of the work — does this request need it, and does it change between requests. The first keeps the window clean. The second decides between a system instruction and per-request retrieval.

And note the trim order. When the window fills, something goes. If you have not decided what, the system decides for you. Compress history first because it is the most redundant; drop examples last because they shape the output format.

When more context makes the answer worse

Failure	What it looks like	Why it happens
Dilution	The answer drifts to a nearby but wrong topic	The relevant passage is present but outnumbered
Truncation	Part of the input silently disappears	The window filled; something had to go
Contradiction	A confident answer built on stale material	Two injected sources disagree
Leakage	Sensitive data appears in an answer	It was placed in the context

Dilution is the counter-intuitive one: the correct passage is right there, correct, and the answer is still wrong because it is outnumbered. Being in the window is not the same as being used.

"Add everything, just in case" raises cost, raises latency, and can lower accuracy at the same time. It is wrong on all three axes, which is precisely what makes it such a good distractor.

Why this is the cheapest way to specialise a model

This is the "role" the objective actually asks about. A general model does your particular job because of what you put in front of it — not because it was rebuilt for you.

Approach	What changes	What it costs
Context engineering	The request	Tokens per request
Fine-tuning	The model's weights	A training cycle, then serving
Pre-training	A model from scratch	Rarely justifiable

Context engineering is the first thing to try, not the fallback when training fails. The full comparison — in-context learning, RAG, fine-tuning, distillation, pre-training — is the customization cost ladder in Chapter 09.

Decision Rules and Exam Signals

Rule 1 — both legs are metered, and they are not priced alike. Output is typically dearer per token. Any reasoning that costs only the prompt is incomplete.

Rule 2 — cost and latency have different levers. Establish which number the question says moved before choosing anything.

Rule 3 — "slow to start" is input; "slow to finish" is output. Prefill versus decode. One word in the scenario decides it.

Rule 4 — capacity is not a discount. A larger context window lets you send more; it does not make what you send cheaper.

Rule 5 — the model is stateless. Anything that looks like memory is being resent and rebilled.

Rule 6 — more context is not more accuracy. Dilution, truncation and contradiction are all real and all get worse as you add material.

Rule 7 — context engineering decides the payload; prompt engineering decides the wording. If the question is about phrasing, it is Chapter 10's objective, not this one.

Signal in the question	Points at
"Cost rose, traffic flat"	Conversation history or injected context growing
"Slow before anything appears"	Input length → prefill → time to first token
"Slow to finish"	Output length → decode
"Answers drift off-topic since we added documents"	Dilution, not model quality
"Needs current or private facts"	Context, not retraining
"Same instruction on every call"	System instruction, not per-request injection

Distractor Patterns

Pattern	What it looks like	How to defuse it
Output is free	Only the prompt is costed	Both legs are metered; output usually costs more per token
A bigger window is cheaper	"Move to a larger context window to cut cost"	Capacity is not a discount; you pay for what you put in it
Fine-tune to save tokens	Retraining offered as a cost fix	That is a training cost, and it does not help with current or private facts
More context is more accurate	"Inject all the documents"	Dilution and truncation both degrade the answer
Latency is about the prompt	A shorter prompt offered for a slow finish	Prompt length moves first-token time; output length moves total time
Memory is stored server-side	"The model remembers the conversation"	It is stateless; history is resent and rebilled
Context engineering = prompt engineering	Treated as synonyms	One writes the instruction; the other decides the payload

The second is the highest-value one to recognise. It sounds like an upgrade, and it is the opposite of a saving.

Scenario Walkthrough

A retailer runs an assistant that answers policy questions. It injects the twenty most similar policy passages into every request, carries the full conversation, and asks for a detailed written explanation each time. Costs have risen sharply while traffic stayed flat, users complain the reply takes a long time to start, and since the policy library grew the answers sometimes cite the wrong region's rules.

Observation	Reading	Action
Cost up, traffic flat	Growth is inside the request, not in usage	Summarise history; stop resending whole conversations
Slow to start	Large input delays prefill	Inject fewer, better-targeted chunks
Wrong region's rules	Dilution — twenty chunks outnumber the right one	Retrieve fewer, and filter by region
Detailed explanation every time	Output leg, at the higher rate	Cap the length; ask for detail only when needed

Three different complaints and three different mechanisms. The wrong-region symptom is the one most often mislabelled as a model-quality problem — it is not. The model is doing exactly what it was given.

One change happens to help all three: injecting fewer, better chunks touches cost, prefill and dilution simultaneously. That is a property of this scenario, not a general rule.

Key Concepts

Term	Definition
Token-based pricing	Charging by the quantity of tokens processed, counted separately for input and output, rather than per request, per user or per unit of time
Input tokens	Everything sent to the model — system instruction, conversation history, retrieved context and the user's message
Output tokens	Everything the model generates in response, metered separately and typically priced higher per token
System instruction	Standing guidance sent in full with every request; looks like configuration, behaves like a recurring charge
Context window	The bounded space a request occupies, refilled from empty each time, shared between the input and the room reserved for the answer
Prefill	The stage in which the model reads the whole prompt in one pass; governs time to first token
Decode	The stage in which output tokens are produced one after another; governs total response time
Time to first token	The wait before any output appears, driven mainly by input length
Total response time	The wait until the answer is complete, driven mainly by output length
Statelessness	The property that nothing carries between requests, so apparent memory is history being resent and rebilled
Context engineering	Deciding what information occupies the context window on each request and how it is arranged, so the model can do the job
Dilution	Degradation caused by relevant material being outnumbered by irrelevant material in the context
Truncation	Silent loss of part of the input when the context window fills
Trim order	The deliberate sequence for reducing a request that does not fit: compress history, then fewer chunks, then fewer examples

Revision Flashcards

Say the answer aloud before revealing it.

1. What exactly is token-based pricing charging for? → The quantity of tokens processed, counted separately for input and output. Not per request, not per user, not per unit of time.

2. Which four things make up the input side of a billed request, and which did the user supply? → The system instruction, the conversation history, the retrieved context and the user's message. Only the last came from the user; the other three were added by the application.

3. Which leg is usually priced higher, and why? → Output. Input is read in a single pass, whereas output is produced one token after another, each depending on the ones before it.

4. Why does a long conversation cost more per request, not just more in total? → The model is stateless. Prior turns are resent with every request, so the input grows each turn even when the new message is short.

5. What is the difference between time to first token and total response time? → Time to first token is the wait before anything appears and is driven mainly by input length through prefill. Total response time is the wait until the answer is complete and is driven mainly by output length through decode.

6. A user says the reply is slow to start. Which side of the request do you look at? → The input side. Long input delays prefill. If they had said slow to finish, it would be the output side.

7. Does moving to a model with a larger context window reduce cost? → No. A larger window increases how much you may send; you still pay for every token you actually send. Capacity is not a discount.

8. Which single lever moves both cost and latency? → Capping the response length. It reduces output tokens, which are both the dearer leg and the driver of total response time. The trade-off is terser or truncated answers.

9. Define context engineering in one sentence. → Deciding what information occupies the model's context window on each request, and how it is arranged, so the model can do the job.

10. How is context engineering different from prompt engineering? → Prompt engineering governs the wording of the instruction. Context engineering governs the whole payload around it — what to retrieve, what history to keep, what to drop. Prompt engineering is a component of context engineering.

11. Name three ways that adding more context makes the answer worse. → Dilution, where the relevant passage is outnumbered; truncation, where the window fills and something is silently dropped; and contradiction, where two injected sources disagree and the model answers confidently from the wrong one.

12. What is the trim order when a request does not fit the window? → Compress the conversation history first because it is the most redundant, then inject fewer retrieved chunks, then reduce examples last because they shape the output format.

The Four-Beat Answer

The core question this chapter prepares you for: "How does token-based pricing work, and what do you do about it?"

Four beats, checked in this order. Missing a beat is a failure state — you will be probed on whichever one you skipped.

1. The unit. Charging is metered by token quantity, counted on both legs, with output typically dearer per token because it is generated sequentially rather than read in one pass.
2. What is actually in the request. The system instruction, the conversation history, the retrieved context and the user's message — and most of that is the application's own decisions rather than user traffic. This is the beat that makes an answer sound like it came from someone who has built something.
3. Which number moves. Input length drives prefill and therefore time to first token. Output length drives decode and therefore total response time. Both drive cost. Name the lever and what it trades away.
4. The discipline. Context engineering: treat the window as a finite budget, allocate it on purpose, and know the trim order for when it does not fit. It is the cheapest way to make a general model do a particular job.

A weak answer describes billing. A strong answer names the levers and what each one costs you.

Why This Helps You

On the job: almost every foundation-model system that becomes unexpectedly expensive got there the same way — a growing system instruction, unmanaged conversation history, and retrieval tuned for recall rather than precision. All three are invisible until the bill arrives, and all three are design decisions rather than traffic.

In interviews: "how would you reduce the cost of this feature?" is a standard system-design follow-up, and "use a cheaper model" is the answer everyone gives. Naming which leg you would cut, which number it moves, and what capability it costs is the answer that sounds like experience.

On the exam: Domain 2 is 24% of scored content, and these two objectives are unusually distractor-rich because every wrong option sounds thrifty. The habit of asking which number does this actually move is worth more here than anywhere else on the paper.

Chapter Checklist

• I can describe token-based pricing as metered, two-sided and asymmetric
• I can name the four components of an assembled prompt and say which one the user supplied
• I can explain why a multi-turn conversation costs more per request over time
• I can separate prefill from decode, and time to first token from total response time
• I can say which lever moves cost, which moves latency, and which moves both
• I can name the trade-off that comes with every lever I propose
• I can define context engineering without describing prompt engineering
• I can treat the context window as a budget and state a trim order
• I can explain three ways in which more context makes an answer worse
• I can say why context is the cheapest way to specialise a general model
• I can reject "a bigger context window will reduce our costs" and say why

After the Chapter

1. Complete student/project.md — parts 19-22 of the AI/ML Decision Sheet you began in Chapter 01. Bring the same sheet; do not start a new one.
2. Take student/quiz.md closed-book, then review the reasoning for every question you guessed, including the ones you got right. In this chapter especially, a right guess is not a right understanding — the distractors are designed to sound thrifty.
3. Open the official v1.1 exam guide's Domain 2 page and confirm you can attach a concept from this chapter to the fourth and fifth bullets under Task Statement 2.1.
4. Next chapter: Chapter 06 — Agentic AI: MCP, Multi-Agent Patterns, Memory, Tools, and Orchestration (Domain 2, Objective 2.1.6). It is the last objective in Task 2.1 and the newest material on the exam. ⚠️ Note the domain carefully: version 1.1 moved the Model Context Protocol out of Domain 3 and into Domain 2, so anyone revising from older material has it filed in the wrong place. Memory management appears on that objective's list — and memory is this chapter's context window put under deliberate control.

Chapter 06 — Agentic AI: MCP, Multi-Agent Patterns, Memory, Tools, and Orchestration

Certification Blueprint

Field	Coverage
Exam	AWS Certified AI Practitioner (AIF-C01), exam guide v1.1
Domain	Content Domain 2 — Fundamentals of GenAI
Exam weight	24% of scored content
Task statement	2.1 Explain the basic concepts of generative AI (GenAI)
Objective	2.1.6 Define foundational agentic AI concepts

What This Chapter Covers

This chapter covers one bullet of the exam guide. That bullet names six concepts: multi-agent system patterns, the Model Context Protocol and its role in connecting agents to external systems, multi-agent communication patterns, memory management, tool usage, and workflow orchestration.

Six concepts in one sentence is why this gets a chapter to itself. Each is independently examinable, and two of them are routinely merged by learners who have studied — which makes telling them apart worth more marks than learning either one in isolation.

Chapters 04 and 05 took objectives 1-5 of Task 2.1. This one finishes the task statement.

⚠️ Where This Material Lives

If your notes file MCP under Domain 3, they were built from version 1.0 of the exam guide.

	Exam guide v1.0	Exam guide v1.1 — current
MCP appeared in	Objective 3.1.6, Domain 3	Objective 2.1.6, Domain 2
As	A parenthetical example	Its own objective, with five other concepts
Objective 3.1.6 now reads	—	"Define the role of AI agents and describe AI agents' business applications"

Checked against the live guide from both directions: the Domain 2 page carries this objective as the sixth bullet of Task 2.1, and the Domain 3 page does not contain "MCP" or "Model Context Protocol" anywhere at all.

This is not trivia. Domain 2 is 24% and Domain 3 is 28%, so filing it wrongly weights your revision wrongly. More importantly, it puts this material next to the wrong neighbours: studied under Domain 3 it sits beside retrieval and prompting, when it actually belongs beside tokens, embeddings and the FM lifecycle.

The boundary to hold: this objective asks what the parts are. Objective 3.1.6, taught in Chapter 08, asks what agents are for. Same subject, two domains, two different questions — and both appear on the exam.

What Is an Agent?

An agent is a system that uses a foundation model to decide which actions to take toward a goal, then takes them, reads what came back, and decides again — rather than producing one answer in one pass.

Two ways to hold it:

• A researcher with a library card rather than someone answering from memory. They look things up, and what they find changes the next question they ask. Someone answering from memory cannot be surprised.
• A thermostat that can also phone the boiler engineer. It does not merely report the temperature; it acts, checks the result, and acts again.

The distinguishing property is the loop. A single model call that returns excellent text is not an agent, however good the text is. The test is whether anything can come back and change its mind.

Tool Usage

Tool usage is giving a model access to external functions, APIs or data sources, so it can request an action and receive the result back as new context.

The model does not execute anything. This is the most commonly mistaken point on this objective:

Step	Who does it
Decide a tool is needed, and with what arguments	The model
Actually call the API, query, or function	The runtime around the model
Return the result into context	The runtime
Decide what the result means and what is next	The model

A doctor ordering a blood test does not run the lab. They order it, the lab runs it, the result comes back — and the diagnosis changes. That last part is why tools belong to the loop rather than being a bolt-on.

What to remember from this diagram: nothing here is new capability inside the model. The capability is that the loop exists, and that results re-enter as context. The branch after the result — act again, or answer — is the agent.

Why it is worth the machinery:

Situation	Without tools	With tools
"What is our stock level for part 4471?"	A plausible number, generated	The real number, queried
"Is this customer overdue?"	An answer from training data that predates the customer	An answer from the billing system
"Book the earliest slot"	A description of how one might book	A booking made, and confirmed
"What changed in the policy last week?"	Confident recall of a policy it never saw	The current document, read

Tools are what let an agent be right about things that changed after training. Note that the model's confidence is identical in both columns — which is why the last row matters.

The Model Context Protocol

MCP is an open protocol that standardises how an AI application connects a model to external tools and data sources — one common interface instead of a bespoke integration per system.

The clearest way to hold it is the arithmetic, because the problem it removes is multiplicative:

	Bespoke integrations	With a shared protocol
3 applications × 4 systems	12 separate integrations	3 + 4 = 7 implementations
Add a fifth system	3 more integrations to write	1

Two ways to hold it:

• USB-C. Every device once had its own cable and charger. One connector standard means any device meets any peripheral, and neither side has to know about the other in advance.
• The mains socket. An appliance maker does not negotiate with each building. They build to the socket; the building provides one.

What to remember from this diagram: read the arrows. MCP connects an agent to external systems. It is not how one agent talks to another — that is multi-agent communication patterns, a separate item on the same objective.

What MCP Is Not

Mistake	Correction
"MCP is an AWS service"	It is an open protocol. It does not appear on any vendor's service list. AWS services can speak it, which is a different statement
"MCP is a model"	It carries context to and from a model; it is not one
"MCP is how agents talk to each other"	It connects an agent to external systems. Agent-to-agent exchange is multi-agent communication patterns
"MCP replaces the need for tools"	It standardises tool connection. The tools still exist and still do the work
"MCP is required to use tools"	Tool usage predates it and works without it. MCP removes the per-system integration cost

The last row is worth care. A learner who believes MCP is a prerequisite for tool usage will misread scenarios. With two or three connections, bespoke integration is tolerable; the case for a shared protocol grows with the number of pairs.

Memory Management

Memory management is deciding what an agent carries forward, for how long, and what it discards.

Recall from Chapter 04 that the model is stateless between calls and prior turns are re-sent. Memory is therefore never automatic and never free — it is a choice about what to re-supply.

Scope	Holds	Lives for
Short-term / working	The current task, recent turns, the last tool result	One session or task
Long-term / persistent	Preferences, prior outcomes, durable facts about a user or account	Across sessions, stored outside the model

Two ways to hold it:

• A desk and a filing cabinet. The desk holds what you are working on now; the cabinet holds everything else, and you fetch a single folder when you need it.
• A shift handover at a hospital. Not everything from the shift is passed on — what matters carries over, the rest is recorded and left behind. Note that a handover is a summary, not a transcript. That is the discipline exactly.

What to remember from this diagram: the wrong question is "how do we remember more?" The right one is "what must survive, and what must not?" — and the second half is real. Some things should be actively forgotten.

Requirement	Scope	Why
The last tool result the agent just fetched	Working	Needed for this step; meaningless next week
"This customer prefers SMS, not email"	Persistent	Durable, and useless if forgotten between sessions
Every message of a long conversation, verbatim	Neither	Re-sending everything is re-counted every call; summarise or select
A one-off verification code	Working, and discarded	Durable storage here is a liability, not a feature

More memory is not better memory. Everything carried forward is re-supplied and counted again, and everything stored has to be justified — retention is a risk as well as a cost.

Multi-Agent System Patterns

A multi-agent system uses several specialised agents where one general agent would be stretched too thin. The system pattern is how they are structured.

Pattern	Shape	Fits when
Supervisor	A lead agent decomposes the task, delegates to specialists, assembles the result	Sub-tasks need genuinely different expertise
Sequential	Each agent's output is the next one's input	The task is a chain with defined stages
Parallel	Several agents work at once; results are merged	Sub-tasks are independent of each other
Hierarchical	Supervisors of supervisors	Decomposition is deep enough that one lead cannot hold it

Reach for these when a task spans distinct specialisms, not when it is merely long. A long single-specialism task is one agent doing more steps.

What to remember from this diagram: these are org charts. They say who reports to whom. They say nothing at all about how the messages travel — which is a separate concept, and the next one.

Multi-Agent Communication Patterns

A different question: not how agents are arranged, but how they exchange information.

Pattern	How information moves	Fits when
Direct / point-to-point	One agent calls another and waits	The recipient is known and the reply is needed now
Broadcast	One agent informs many at once	Several agents need the same update
Shared state	Agents read and write a common store rather than messaging	Many agents contribute to one evolving artifact
Message queue	Messages are published and consumed asynchronously	Agents must be decoupled, or work at different rates

System pattern is the org chart. Communication pattern is how the memos move.

The two are genuinely independent, and that independence is what makes them separately examinable: a supervisor system can pass messages point-to-point or through shared state, and choosing one does not determine the other. If a question asks how agents exchange information and you answer "supervisor", you have answered a different question.

Workflow Orchestration

Workflow orchestration is coordinating the steps of an agentic application: sequencing them, routing between them, handling failures and retries, and deciding when the task is finished.

That last one is easy to overlook and worth naming — knowing when to stop is part of orchestration.

Something must own the plan. There are two ways it can:

Approach	Who decides the next step	Trade-off
Deterministic	The developer, in a defined workflow	Predictable, testable, auditable — but cannot adapt to the unforeseen
Model-driven	The model, at each turn	Adapts to novel situations — but the path varies between runs

Do not treat model-driven as the sophisticated answer by default. In a regulated or audited process, "the path varies between runs" is a defect rather than a feature — which is Chapter 02's guaranteed-deterministic-result material appearing again in a new place.

Two ways to hold it:

• A film director. The actors perform; the director decides what happens in what order, and when the scene is done.
• An air traffic controller. Each pilot flies their own aircraft; the controller sequences them and decides who moves when.

One Agent, or Several?

What to remember from this diagram: the default is one agent with good tools. Multiple agents are what you escalate to, with a reason you can name.

Every agent added multiplies something:

What multiplies	Consequence
Model calls	Each agent's input and output are counted — Chapter 05 attaches the cost
Latency	Steps that wait on each other add up
Failure modes	Any agent can fail, stall, or hand on a bad result
Debugging surface	"Which agent decided that?" becomes a real question

Choosing a single agent for a bounded, single-specialism task is not timidity. It is the correct answer, and this domain rewards knowing the difference.

The AWS Names Attached to These Concepts

Task 2.3 lists the services and Chapter 07 chooses between them. Attach the vocabulary now:

Name	Where it sits
Amazon Bedrock AgentCore	AWS capabilities for running agents in production — including managed memory, identity and tool connectivity
Strands Agents	An AWS open-source toolkit for building agents
Kiro	An AWS agentic development environment

All three entered scope at v1.1, the same revision that created this objective — the guide added the concepts and the names together. Recognise them and the family they belong to; selection and cost trade-offs are examined under Task 2.3.

Decision Rules and Exam Signals

Rule 1 — an agent is defined by its loop. If nothing can come back and change the decision, it is a single model call regardless of how good the output is.

Rule 2 — the model requests, the runtime executes. Any option saying the model itself queried, called or booked something has the mechanism wrong.

Rule 3 — ask what is on each end of the connection. Agent to external system is MCP. Agent to agent is a communication pattern. This one question resolves the most-confused pair on the objective.

Rule 4 — MCP is a protocol, not a product. It never belongs in a list of services to select.

Rule 5 — memory is a choice about what survives. "Keep everything" is a decision with a cost, not a safe default.

Rule 6 — structure and message flow are separate questions. Supervisor, sequential, parallel and hierarchical answer how they are arranged. Direct, broadcast, shared state and queue answer how they communicate.

Rule 7 — one agent is the default. Escalate to several only for distinct specialisms, never because the scenario used the word "complex".

Rule 8 — check which objective is being asked. What the parts are is 2.1.6, here. What agents are for is 3.1.6, Chapter 08.

Distractor Patterns

Pattern	What it looks like	How to defuse it
MCP filed in Domain 3	Studied beside RAG and prompting	v1.1 moved it to 2.1.6, Domain 2
MCP as agent-to-agent	"Use MCP so the agents can talk"	MCP connects an agent to external systems
MCP as a product	Picking "MCP" from a service list	It is an open protocol, not a service
Model executes the tool	"The model queries the database"	The model requests; the runtime executes
Multi-agent by default	Five agents for a bounded lookup	Cost, latency and failure modes multiply
Memory as unlimited context	"Give it the whole history"	Carried context is re-supplied and re-counted
Structure answered for message flow	"Supervisor" offered for how they exchange information	System pattern ≠ communication pattern
Role and business value	A question about why a business uses agents	That is Objective 3.1.6, Domain 3

The first three share a root cause: not knowing precisely what MCP is and what it connects. The last one is different in kind — it is a correct idea filed under the wrong objective, and recognising which objective a question tests is itself an exam skill.

Scenario Walkthrough

A logistics operator wants an assistant that answers "where is my shipment, and will it be late?" by reading the tracking database, a weather feed and the carrier's schedule API. It must remember each customer's preferred notification channel for as long as they remain a customer. When a shipment is genuinely disrupted, the recommendation needs pricing, customs and capacity expertise. And the whole thing must recover cleanly when the carrier API times out.

Requirement	Reading	Decision
Read three live external systems	Must act on current data, not recall	Tool usage, standardised by MCP
Preferred channel, held for years	Must survive the session	Persistent memory, retrieved selectively
Pricing, customs and capacity	Three distinct specialisms	Multi-agent, supervisor pattern
Recover from a timed-out call	Something must own the plan	Workflow orchestration
Plain "where is my shipment"	Bounded, one lookup	A single agent with tools

Five concepts, and the last row is the one most people get wrong. The simple query does not need the multi-agent path, and routing it there buys cost and latency and returns nothing.

A good architecture here has two paths, not one. Noticing that is what separates a considered answer from a pattern-matched one.

Key Concepts

Term	Definition
Agent	A system that uses a foundation model to decide which actions to take toward a goal, take them, read the results, and decide again
The agent loop	The cycle of decide, act, observe, decide again — the property that distinguishes an agent from a single model call
Tool usage	Giving a model access to external functions, APIs or data sources so it can request an action and receive the result back as context
Model Context Protocol (MCP)	An open protocol that standardises how an AI application connects a model to external tools and data sources
Memory management	Deciding what an agent carries forward, for how long, and what it discards
Working memory	Short-term state for the current task or session — recent turns, the last tool result — discarded when the task ends
Persistent memory	Durable facts held outside the model across sessions, retrieved selectively when relevant
Multi-agent system	Several specialised agents used where a single general agent would be stretched too thin
Multi-agent system pattern	How multiple agents are structured: supervisor, sequential, parallel, hierarchical
Multi-agent communication pattern	How agents exchange information: direct, broadcast, shared state, message queue
Supervisor pattern	A lead agent that decomposes a task, delegates to specialists, and assembles the result
Workflow orchestration	Coordinating an agentic application's steps — sequencing, routing, failure handling, and deciding when the task is done
Deterministic orchestration	The developer defines the workflow; predictable and auditable, but cannot adapt to the unforeseen
Model-driven orchestration	The model decides each next step; adaptable, but the path varies between runs

Revision Flashcards

Say the answer aloud before revealing it.

1. What single property distinguishes an agent from one model call? → The loop. It decides on an action, something happens, the result re-enters its context, and it decides again. If nothing can come back and change its mind, it is not an agent — however good the output.

2. In a tool call, who decides and who executes? → The model decides a tool is needed and with what arguments. The runtime around the model executes the call and returns the result into context. The model then interprets it. The model itself never executes anything.

3. What is MCP, in one sentence? → An open protocol that standardises how an AI application connects a model to external tools and data sources, so each side is implemented once instead of once per pair.

4. What problem does MCP remove, stated as arithmetic? → Bespoke integration is multiplicative: 3 applications × 4 systems is 12 pieces of work. A shared protocol makes it 3 + 4 = 7, and a new system costs one implementation rather than one per application.

5. What does MCP connect — and what does it not connect? → It connects an agent to external systems such as databases, APIs and file stores. It does not govern agent-to-agent exchange; that is multi-agent communication patterns, a separate item on the same objective.

6. Is MCP an AWS service? → No. It is an open protocol and appears on no vendor's service list. AWS services can speak it, which is a different claim. A question offering MCP among services to select is testing exactly this.

7. What is the difference between working memory and persistent memory? → Working memory holds the current task — recent turns, the last tool result — and is discarded when the task ends. Persistent memory holds durable facts such as preferences across sessions, stored outside the model and retrieved selectively.

8. Why is "keep the entire conversation history" the wrong default? → Everything carried forward is re-supplied and counted on every call, so cost and latency grow without improving answers — and usually degrade them, because what matters gets diluted. Summarise or select instead.

9. Name the four multi-agent system patterns and what each fits. → Supervisor: a lead decomposes and delegates to specialists. Sequential: a chain of defined stages. Parallel: independent sub-tasks merged afterwards. Hierarchical: supervisors of supervisors for deep decomposition.

10. Name the four multi-agent communication patterns. → Direct point-to-point, broadcast to many, shared state that agents read and write, and asynchronous message queues for decoupling.

11. What is the difference between a system pattern and a communication pattern? → System pattern is the org chart — who reports to whom. Communication pattern is how the memos move. They are independent: a supervisor system can use direct calls or shared state.

12. What is the trade-off between deterministic and model-driven orchestration? → Deterministic is predictable, testable and auditable but cannot adapt to the unforeseen. Model-driven adapts to novel situations but the path varies between runs — which is a defect, not a feature, in an audited process.

The Five-Beat Answer

The core question this chapter prepares you for: "What is an agentic AI system actually made of?"

Five beats, checked in this order. Missing a beat is a failure state — you will be probed on whichever one you skipped.

1. The loop — an agent decides on an action, acts, reads the result, and decides again. Name the loop as the distinguishing property, not the quality of the output.
2. Tools — the loop needs something to act on. The model requests a tool call; the runtime executes it and returns the result as context. Say who does which, because getting this backwards signals you have not built one.
3. Connection — as the number of systems grows, bespoke integration becomes multiplicative. MCP standardises the connection between an agent and external systems so each side is implemented once. Name it as a protocol, and say what it connects.
4. Memory — the model is stateless between calls, so memory is a deliberate choice about what survives. Separate working from persistent, and say that carrying everything is a cost rather than a safe default.
5. Coordination — when a task spans distinct specialisms, several agents are structured by a system pattern and exchange information by a communication pattern, with orchestration owning the sequencing and failure handling. Then say when not to: a bounded task is one agent with tools.

A strong answer names the loop and knows when to stop adding agents. A weak answer lists technologies.

Why This Helps You

On the job: the multiplicative integration problem is real and expensive, and teams discover it at the fourth system rather than the first. Recognising it early — and knowing that a standard protocol is the structural answer rather than more glue code — is the difference between a system that grows and one that has to be rewritten.

In interviews: "what is an agent?" is asked constantly, and "it's an LLM that can use tools" is the answer everyone gives. Naming the loop, and being precise that the model requests while the runtime executes, signals that you have actually seen one run. Knowing when a multi-agent system is the wrong choice signals judgement rather than enthusiasm.

On the exam: this objective is new at v1.1 and much third-party material still files it under Domain 3. Two of its six concepts — MCP and multi-agent communication — are routinely merged, and questions are built on exactly that confusion. Asking "what is on each end of the connection?" defuses most of them.

Chapter Checklist

• I can define an agent by its loop rather than by the cleverness of its output
• I can say who executes a tool call, and who only requests it
• I can define MCP as an open protocol and state the problem it removes
• I can say what MCP connects, and what it does not connect
• I can explain why MCP is not required in order to use tools
• I can distinguish working memory from persistent memory by what must survive
• I can explain why carrying everything forward is a cost rather than a feature
• I can name the four multi-agent system patterns and what each fits
• I can name the four communication patterns and how information moves in each
• I can state the difference between a system pattern and a communication pattern
• I can define workflow orchestration and the deterministic-versus-model-driven trade-off
• I can give a concrete reason to choose one agent over several
• I can say which domain and objective this material belongs to, and which objective covers agents' business role

After the Chapter

1. Complete student/project.md — parts 23-26 of the AI/ML Decision Sheet you began in Chapter 01. Bring the same sheet; do not start a new one.
2. Take student/quiz.md closed-book, then review the reasoning for every question you guessed, including the ones you got right.
3. Open the official v1.1 exam guide's Domain 2 page and confirm you can attach a concept from this chapter to each of the six items named inside Objective 2.1.6. Then open the Domain 3 page and confirm for yourself that MCP is not there.
4. Next chapter: Chapter 07 — Choosing GenAI, and the AWS GenAI Stack (Domain 2, Tasks 2.2 and 2.3). Task 2.1 is now complete across Chapters 04, 05 and 06. Chapter 07 closes the domain with what generative AI is genuinely good at, where it fails, the factors that select a model, the business metrics that justify one, and the AWS services that build these applications — including the three names introduced here.

Chapter 07 — Choosing GenAI, and the AWS GenAI Stack

Certification Blueprint

Field	Coverage
Exam	AWS Certified AI Practitioner (AIF-C01), exam guide v1.1
Domain	Content Domain 2 — Fundamentals of GenAI
Exam weight	24% of scored content
Task statements	2.2 Capabilities and limitations of GenAI · 2.3 AWS infrastructure and technologies for GenAI
Objectives	2.2.1-2.2.4 and 2.3.1-2.3.4 — all eight

What This Chapter Covers

This chapter closes Domain 2, and it carries eight of the domain's fourteen objectives — the widest brief in the domain.

The character of the material changes here. Chapters 04, 05 and 06 were definitions: what a foundation model is, what a token costs, what an agent does. This chapter is decisions, and almost every exam question in Tasks 2.2 and 2.3 is built on a conflict — two things the scenario wants that cannot both be had.

Chapters 04-06 gave you	This chapter asks
What a foundation model, token and embedding are	Should this problem use one at all?
How token pricing and context work	What does each serving choice cost?
What an agent, MCP and orchestration are	Which AWS service runs it?
Definitions	Decisions, under conflict

Questions here rarely ask whether generative AI is good. They ask which limit disqualifies it, or which factor wins when two of them pull in opposite directions.

The Advantages of GenAI

Objective 2.2.1 names four. They are not a list of virtues — each is a specific capability a scenario can be reaching for.

Advantage	What it actually means
Adaptability	One model serves many tasks without being retrained for each
Responsiveness	It answers now, on unseen input, rather than after a build cycle
Conversational capabilities	It holds a multi-turn exchange in which each turn depends on the last
Ability to generate content	It produces new artefacts, rather than classifying or scoring existing ones

Two ways to hold it:

• A general contractor with a broad crew rather than a single specialist tradesperson. Any job gets started today; none of them is done by someone who has done only that job for twenty years.
• A fluent colleague in a language you do not speak. They will answer anything you ask immediately, and they will never say "I do not know that word." Keep this one — it carries the limits as well as the advantages.

The examinable habit is naming which advantage a scenario invokes:

The scenario says	Advantage being invoked
"Handles enquiries about products we add every week"	Adaptability
"Must answer questions nobody anticipated"	Responsiveness
"The follow-up question depends on the previous answer"	Conversational
"Draft the first version of the report"	Generation

"GenAI is powerful" is not a reason. "The catalogue changes weekly, and adaptability removes a retraining cycle per product" is.

The Disadvantages — Three Failures Before Four Names

Look at these before reading the definitions underneath them.

What was observed	What it looked like to the business
An assistant cited a refund policy clause, with a section number, that has never existed in the policy	Confident, specific, correctly formatted — and invented
The same question, asked twice in one afternoon, produced two different totals	Neither answer was flagged as uncertain; both were stated plainly
A rejected loan application could not be explained to the applicant, because nobody could say which input drove the decision	Commercially defensible and legally indefensible

None of these is a bug that a patch fixes. Each is a property of the technology that a design must account for. Now the names — Objective 2.2.2 gives four, and they are four different failures with four different mitigations:

Disadvantage	Precisely	The failure above
Hallucination	Content that is fluent, plausible and not grounded in any source	The invented policy clause
Nondeterminism	The same input may produce different output on different runs	The two different totals
Interpretability	Why a given output was produced cannot be readily traced	The unexplainable rejection
Inaccuracy	The output is simply wrong against a known correct answer	Any of them, once checked

Hallucination and inaccuracy are not synonyms, and this is the most common conflation in the objective. An inaccurate answer is wrong. A hallucinated answer is unfounded — it can be accidentally correct and still be a hallucination, because nothing grounded it. The mitigations differ, which is why the exam keeps them apart: inaccuracy is addressed by evaluating against a benchmark, hallucination by grounding the output in retrieved source material and citing it.

Nondeterminism cannot be configured away. Inference parameters influence how much variation you get — Chapter 08 covers them — but the property is inherent. A requirement for byte-identical repeatable output is a reason to reject generative AI for that part of the system, not a setting to hunt for.

What to remember from this diagram: two of the three gates are exits. This is Chapter 02's suitability screen one level down — there the question was whether to use AI at all, here it is whether to use generative AI given these four specific limits. The middle exit matters most: "not open-ended" sends you back to traditional ML or a managed AI service, which is a Domain 1 answer appearing correctly inside a Domain 2 question.

Selecting a Model: the Eight Factors

Objective 2.2.3 names eight. Learners memorise them as a flat list and then cannot use them, because a flat list gives no way to resolve a conflict — and conflict is what the questions are made of.

Factor	The question it asks
Model types	Does the modality match what goes in and comes out?
Constraints	What is technically or contractually forbidden here?
Compliance	What is legally or regulatorily required?
Performance requirements	What quality bar must the output clear?
Latency	How fast must the answer arrive?
Capabilities	Can it do the specific things this use case needs?
Cost	What does it cost at the volume we actually expect?
Model complexity	How much model is the job worth?

Model complexity is the least obvious of the eight: it asks how much model the job is worth. A large general model pointed at a narrow, well-defined task is a real and common wrong answer.

What to remember from this diagram: gates one and two eliminate. Only gate three ranks. This is the single most examinable sentence in Task 2.2, because distractors are built exactly against it — an option that is cheaper, faster, and violates a stated constraint.

That structure resolves conflicts without needing intuition:

Conflict in the scenario	Which wins	Why
Compliance requires regional data residency · the best model is elsewhere	Compliance	A hard constraint cannot be traded, however good the model
Latency budget is 300 ms · the larger model is more accurate	Latency	Stated performance envelope; an answer that arrives late is not an answer
Cost is tight · a smaller model meets the quality bar	Cost	Once the bar is met, further quality is not free value
Cost is tight · no model within budget meets the quality bar	Neither — re-scope	This is no longer a model-selection problem

The third row is counterintuitive for engineers, who read "more accurate" as strictly better. The fourth is the one candidates avoid: sometimes no option is acceptable, and a question that offers that reading is testing whether you will force a choice anyway.

Business Value and Metrics

Objective 2.2.4 names seven metrics. The examinable skill is not reciting them — it is knowing which end of the chain each one sits on.

Metric	Which end
Accuracy	Model
Cross-domain performance	Model — does it hold up outside the data it was tuned on?
Efficiency	The operational bridge — time, volume, rework
ROI	Business
Conversion rate	Business
Average revenue per user	Business
Customer lifetime value	Business

Cross-domain performance is worth learning properly, because the name does not give it away: it asks whether the model holds up outside the data it was tuned on. It is a model metric, and it is the one that predicts whether a business metric will survive contact with real usage.

What to remember from this diagram: the weak answer stops at the first box. "It is 94% accurate" is not a business case — it is the first link of one. Four of the seven named metrics are business metrics, because a sponsor does not buy accuracy; a sponsor buys the outcome accuracy caused.

The AWS GenAI Stack

Objective 2.3.1 names seven services. Several are recent additions to the exam guide — study material written against the earlier version will not contain Kiro, Strands Agents or Amazon Bedrock AgentCore at all. Amazon Quick is not one of the additions: it was already in scope, and it is Amazon Q that joined the in-scope list alongside those three.

Service	What it is for
Amazon Bedrock	Reach managed foundation models from multiple providers behind one API
Amazon SageMaker AI	Build, train and deploy models with full control of the process
SageMaker JumpStart	Start from pre-trained models and solution templates rather than from nothing
Amazon Bedrock AgentCore	Run agents in production — deployment, tool access, observability, security at scale
Strands Agents	An open-source SDK for building agents, in Python and TypeScript
Kiro	Agentic development — turning prompts into executable specs
Amazon Quick	An AI companion for work — research, business insights and automation

Learn the need each one answers, not the order of the list. An exam question supplies a need, never a service name — nobody is asked "what is Kiro", they are asked what fits a described situation.

What to remember from this diagram: two services in the same layer are alternatives; two in different layers are usually used together. That one sentence answers a great many "which service" questions. In particular, Strands Agents is what you build an agent with and Amazon Bedrock AgentCore is what you run it on — they are not competitors, and a question offering both as competing choices is testing exactly that.

Amazon Quick is not Amazon Q

Both are in scope for this exam. They are different services, and only one is named in Objective 2.3.1.

	Amazon Quick	Amazon Q
Named in Objective 2.3.1?	Yes	No
Listed under	Analytics	Developer Tools
In one line	An AI companion for work — research, business insights, automation	A generative AI assistant in the developer-tools family

Three more name pairs that cost marks:

Do not confuse	With
Amazon Bedrock — reach and use managed FMs	Amazon Bedrock AgentCore — run agents in production
Amazon SageMaker AI — build and train with full control	SageMaker JumpStart — start from pre-trained models and templates
Strands Agents — the SDK you build an agent with	Amazon Bedrock AgentCore — the platform you run it on

The general habit is worth more than the four specific pairs: when two options differ by one word, the question is usually about that word.

Why Build on AWS GenAI Services

Objective 2.3.2 names six advantages. Each is best stated as what it removes — that is what turns a list into an answer.

Advantage	What it removes
Accessibility	Needing to source, host and operate a model yourself
Lower barrier to entry	Needing a specialist team before the first working prototype
Efficiency	Rebuilding shared plumbing for every application
Cost-effectiveness	Paying for idle capacity you provisioned in advance
Speed to market	The lead time between deciding and shipping
Ability to meet business objectives	The gap between a demonstration and something operable

A managed service is not "easier". It is a different set of things that are now somebody else's job, and the exam wants you to name which things.

What the Infrastructure Itself Contributes

Objective 2.3.3 names four benefits of the infrastructure, as distinct from the services built on it. The third column is the examinable part.

Benefit	What the platform provides	What is still yours
Security	Isolation, encryption, identity and access control	Deciding who should have access, and to what
Compliance	Audited programs and evidence you can inherit	Proving your own use case meets its own obligations
Responsibility	Tooling to evaluate and constrain model behaviour	Deciding what behaviour is acceptable here
Safety	Guardrail mechanisms that can filter and block	Defining what must be filtered or blocked

The shared responsibility model does not disappear because a service is managed — it moves. A managed service does not make an application compliant; it gives you evidence you can inherit for the parts AWS operates. Domain 5 examines this properly.

Cost Trade-offs

Objective 2.3.4 names eight considerations. Every one is a trade — the cheaper choice always costs something else, and a candidate who cannot name what it costs has not understood it.

Trade-off	What you gain	What you give up
Token-based pricing	No commitment; pay only for what is used	Spend rises with usage, and is hard to cap
Provisioned throughput	Predictable responsiveness and capacity	Paid whether used or not
Custom models	Behaviour prompting cannot reach	Training and hosting cost, and a maintenance obligation
Redundancy and availability	Survives a failure	Duplicate capacity, paid continuously
Regional coverage	Data residency and lower latency near users	Not every model is offered in every Region
Performance	A larger or faster tier	Cost rises faster than the quality gain

Token-based pricing appeared in Chapter 05 as a mechanism. Here it is one option among several — the objective asks you to trade it against the alternatives, not to explain how it works.

Regional coverage catches people out, because it interacts directly with a data-residency constraint from gate one: not every model is offered in every Region.

What to remember from this diagram: traffic shape picks the serving mode; requirement picks the model. They are separate decisions, and questions frequently blend them to see whether you will. Note the "stop here" node — reaching for a custom model before prompting has been tried is the expensive wrong answer, and it appears in distractors constantly because it sounds like the thorough option.

Decision Rules and Exam Signals

Rule 1 — name the advantage, not the technology. Say which of the four the scenario reaches for and what it removes.

Rule 2 — hallucination is unfounded; inaccuracy is wrong. Different failures, different fixes.

Rule 3 — nondeterminism is inherent. If byte-identical output is required, that is an exit, not a configuration task.

Rule 4 — gates one and two eliminate, gate three ranks. Compliance, constraints and model type are never traded for cost.

Rule 5 — carry a model metric through to a business metric. Accuracy → efficiency → ROI or conversion or revenue per user or lifetime value.

Rule 6 — same layer means alternatives, different layers mean used together. This resolves most "which service" questions.

Rule 7 — traffic shape picks the serving mode. "Unpredictable" and "near zero overnight" point at on-demand; "steady, high, all day" points at provisioned throughput.

Rule 8 — the cheapest path that meets the requirement wins. Prompting before retrieval, retrieval before fine-tuning.

Distractor Patterns

Pattern	What it looks like	How to defuse it
Advantage stated in general	"GenAI is flexible and powerful"	Name which of the four, and what the scenario needed it for
Hallucination as inaccuracy	Treating the two as one failure	Unfounded vs wrong — different mitigations
Nondeterminism as a bug	Offering to "fix" it with configuration	It is inherent; design around it or reject GenAI
Trading a hard constraint	Compliance sacrificed for cost or quality	Gates one and two eliminate; only gate three ranks
Model metric as business value	"94% accurate" offered as the business case	Carry it through efficiency to a business metric
Amazon Q for Amazon Quick	The similar name selected	Different services; only Amazon Quick is in Objective 2.3.1
Bedrock for AgentCore	The familiar name selected	Bedrock reaches models; AgentCore runs agents
Custom model reached for first	Fine-tuning offered before prompting is tried	The cheapest path that meets the requirement wins

The fourth is the single most reliable way to lose a Task 2.2 question, because the offending option is usually the most attractive one on cost and speed.

Scenario Walkthrough

A national insurer wants an assistant that answers policyholder questions in conversation. Policy wordings change quarterly. Regulation requires that any statement made to a policyholder be traceable to the policy document it came from, and that customer data stay within the country. Traffic is steady and high all day. The sponsor has asked what the business case is.

Requirement	Reading	Decision
Multi-turn policyholder questions	Conversational capability, and content generated per question	GenAI fits on advantage
Every statement traceable to a source	Hallucination is disqualifying unless grounded	GenAI only with grounding and citation
Customer data stays in-country	Compliance — a hard constraint	Gate one; regional coverage decides the shortlist
Wordings change quarterly	Adaptability, and an argument against a custom model	Prompting and retrieval before fine-tuning
Steady, high, all-day traffic	Predictable capacity is worth reserving	Provisioned throughput over on-demand
"What is the business case?"	Accuracy is not the answer	Carry through efficiency to ROI and customer lifetime value

Six requirements, six different objectives. The one nearly always missed is the fourth: quarterly change is an argument against a custom model, not for one. Content that changes faster than a training cycle is a retrieval problem — fine-tuning changes behaviour, not facts, and a custom model would be permanently behind while carrying a maintenance obligation nobody scoped.

Key Concepts

Term	Definition
Adaptability	One model serving many tasks without being retrained for each — the advantage that removes a per-task build cycle
Responsiveness	Answering now, on unseen input, rather than after a build cycle
Conversational capability	Holding a multi-turn exchange in which each turn depends on the previous one
Hallucination	Fluent, plausible content that is not grounded in any source; it may be accidentally correct and is still a hallucination
Nondeterminism	The property that identical input may produce different output on different runs; inherent, not a defect
Interpretability	The degree to which the reason for a given output can be traced
Inaccuracy	Output that is wrong against a known correct answer
Cross-domain performance	A model metric asking whether performance holds up outside the data the model was tuned on
Provisioned throughput	Reserved model capacity bought for predictable responsiveness, paid whether used or not
Amazon Bedrock	The service for reaching managed foundation models from multiple providers behind one API
Amazon Bedrock AgentCore	The platform for running agents in production — deployment, tool access, observability and security at scale
Strands Agents	An open-source SDK, in Python and TypeScript, for building agents
Kiro	An agentic development tool that turns prompts into executable specifications
Amazon Quick	An AI companion for work — research, business insights and automation; the service named in Objective 2.3.1, distinct from Amazon Q
SageMaker JumpStart	The on-ramp of pre-trained models and solution templates, as distinct from building from nothing in Amazon SageMaker AI

Revision Flashcards

Say the answer aloud before revealing it.

1. Name the four advantages of GenAI, and say what makes naming one better than praising GenAI. → Adaptability, responsiveness, conversational capabilities, and the ability to generate content. Naming one identifies what the scenario actually needed and what that advantage removes — "GenAI is powerful" identifies nothing and answers no question.

2. What is the difference between a hallucination and an inaccuracy? → An inaccurate answer is wrong against a known correct answer. A hallucinated answer is unfounded — nothing grounded it. A hallucination can be accidentally correct and still be a hallucination. Inaccuracy is addressed by evaluation against a benchmark; hallucination by grounding and citation.

3. Can nondeterminism be switched off? → No. Inference parameters influence how much variation you get, but the property is inherent. A requirement for byte-identical repeatable output is a reason to reject generative AI for that part of the system, not a setting to find.

4. Name the eight model-selection factors, and the three groups they sort into. → Model types, constraints, compliance (hard constraints); performance requirements, latency, capabilities (performance envelope); cost and model complexity (economics). The first two groups eliminate; only the third ranks.

5. Compliance and cost conflict. Which wins, and what is the better way to say why? → Compliance — but the structural answer is stronger: compliance is a hard constraint, so it eliminates rather than ranks. An option that saves money by violating a stated constraint has not made a trade-off, it has answered a different question.

6. What does cross-domain performance measure? → Whether a model's performance holds up outside the data it was tuned on. It is a model metric, and it is the one that predicts whether a business metric will survive real usage.

7. Why is "it is 94% accurate" not a business case? → Accuracy is a model metric and only the first link of the chain. A business case carries it through an operational effect — usually efficiency in time, volume or rework — to a business metric such as ROI, conversion rate, average revenue per user or customer lifetime value.

8. Name the seven services in Objective 2.3.1. → Amazon Bedrock, Amazon SageMaker AI, SageMaker JumpStart, Amazon Quick, Kiro, Strands Agents, and Amazon Bedrock AgentCore.

9. How do Amazon Quick and Amazon Q differ, and which is examinable under Objective 2.3.1? → They are two different services and both are in scope for the exam. Amazon Quick — an AI companion for work covering research, business insights and automation — is the one named in Objective 2.3.1. Amazon Q is not named there and sits under Developer Tools in the in-scope list.

10. Strands Agents or Amazon Bedrock AgentCore — when would you pick one over the other? → The framing is the trap: they are not alternatives. Strands Agents is the open-source SDK you build an agent with; Amazon Bedrock AgentCore is the platform you run one on. A question offering both as competing choices is testing whether you know that.

11. Traffic falls to near zero overnight and spikes during promotions. On-demand or provisioned throughput? → On-demand, token-based pricing. Reserved capacity is paid whether used or not, so it is wasted on traffic that drops to near zero. Provisioned throughput is for steady, high, predictable volume where the reservation is actually used.

12. A knowledge base changes weekly. Why is fine-tuning the wrong answer? → Because fine-tuning changes behaviour, not facts, and a training cycle is slower than the rate of change — the model is permanently behind and carries a maintenance obligation. Frequently changing content is a retrieval problem: ground the model in the current source at request time.

The Four-Beat Answer

The core question this chapter prepares you for: "How would you decide whether to use generative AI for this, and what would you build it on?"

Four beats, checked in this order. Missing a beat is a failure state — you will be probed on whichever one you skipped.

1. Fit — name which of the four advantages the requirement actually reaches for, then name the limit that could disqualify it. Say explicitly that nondeterminism is inherent and that a requirement for identical repeatable output is an exit rather than a configuration problem.
2. Selection — sort the factors into hard constraints, performance envelope and economics, and state that only the economics may be traded. Compliance, constraints and model type eliminate.
3. The stack — name the service by the need it answers, not by familiarity: Bedrock to reach managed models, SageMaker AI for full control, JumpStart to start from pre-trained, AgentCore to run agents in production, Strands Agents to build one, Kiro for spec-driven development, Amazon Quick as an AI companion for work.
4. Economics — pick the serving mode from the traffic shape, and name what the choice costs. Then carry the value claim through efficiency to a named business metric rather than stopping at accuracy.

A strong answer names an exit and a trade. A weak answer lists capabilities.

Why This Helps You

On the job: the most expensive mistakes in generative AI projects are made at this stage, not in implementation — a custom model commissioned for a fast-changing-content problem, or reserved capacity bought for traffic that does not justify it. Both are decisions that look thorough and cost money for the life of the system.

In interviews: "when would you not use generative AI?" is a standard senior screening question, and it separates people who have shipped from people who have demonstrated. Naming nondeterminism as inherent, and traceability as a grounding requirement rather than a model choice, is what a strong answer sounds like.

On the exam: these eight objectives are the decision-heavy half of a domain worth 24% of scored content. The single highest-value habit is the gate structure — hard constraints eliminate, economics rank — because the most attractive distractor in a Task 2.2 question is almost always the one that buys cost or speed by breaking a stated constraint.

Chapter Checklist

• I can name all four advantages, and say which one a given scenario is reaching for
• I can separate hallucination, nondeterminism, interpretability and inaccuracy as four distinct failures
• I can explain why nondeterminism cannot be configured away
• I can sort the eight selection factors into hard constraints, performance envelope and economics
• I can say which factors may be traded and which may not
• I can carry a model metric through efficiency to a named business metric
• I can name the seven services in Objective 2.3.1 and the need each one answers
• I can distinguish Amazon Quick from Amazon Q, and Amazon Bedrock from Amazon Bedrock AgentCore
• I can state what AWS infrastructure provides and what remains the builder's responsibility
• I can choose a serving mode from the traffic shape, and name what that choice costs

After the Chapter

1. Complete student/project.md — parts 27-30 of the AI/ML Decision Sheet you began in Chapter 01. Bring the same sheet; do not start a new one.
2. Take student/quiz.md closed-book, then review the reasoning for every question you guessed, including the ones you got right.
3. Open the official v1.1 exam guide's Domain 2 page and confirm you can attach a concept from this chapter to each of the four bullets under Task Statement 2.2 and each of the four under Task Statement 2.3. Then open the In-Scope AWS Services page and find Amazon Quick and Amazon Q in their two different categories.
4. Domain 2 is now complete. Next: Chapter 08 — Designing FM Applications: Selection, Inference Parameters, and Agents (Domain 3, Task 3.1). Domain 3 is the largest domain on the exam at 28%, and it asks how rather than whether. Chapter 08 opens it with the criteria that pick one foundation model over another — including the inference parameters this chapter deferred.