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.