AIF-C01
Deep Dive
Agentic AI is one of the fastest-growing topics on the updated exam: instead of a model that just responds with text, an agent reasons, decides, acts on external systems, and chains multiple steps. This section covers the general concept — independent of any specific service — and the technical pieces that make it possible: MCP, memory, orchestration, and multi-agent systems.
Contents
An AI agent is a system built around a foundation model that perceives a task, reasons about the steps needed, acts on the real world through tools, and evaluates the outcome iteratively until a goal is met — instead of just returning a text response to a single question.
This concept is independent of any particular AWS service: you can build an agent with Bedrock Agents, with your own SDK, or with open-source frameworks. What defines an agent isn't the underlying technology, but the behavior pattern: reason → act → observe → repeat.
Simple prompt-response
The model receives an input, generates text, and stops. It has no way to look up information that wasn't in its training or the prompt, and it can't perform any real action. It's a single inference call, with no state or subsequent decision loop.
Agent
The model participates in a loop: it decides whether it needs more information or a concrete action, invokes a tool, receives the result, decides the next step, and repeats until the full task is resolved — not just one question answered.
Bedrock Agents (covered in the D3 module) is AWS's managed implementation of this general pattern. This module goes deeper into the concepts that apply regardless of which platform is used to build the agent.
Create an agent in Bedrock capable of calling external APIs to complete multi-step tasks.
+1 more...
MCP is an open protocol that standardizes how an AI model (or an agent) connects with external tools and data sources — databases, APIs, file systems — instead of requiring a different custom integration for every model-tool combination.
Analogy: the universal USB for agents
Before USB, every peripheral (printer, keyboard, scanner) had its own connector and its own driver. MCP plays the same role for AI agents: instead of writing a different integration every time an agent needs to talk to a new tool (a database, a CRM, a file system), the tool exposes an MCP server that any compatible agent can use without integration code specific to that model.
What problem it exactly solves
Without a standard protocol, connecting N models with M tools can require up to N × M distinct integrations, each with its own input/output format. MCP defines a common format: the agent speaks "MCP" and any tool that exposes an MCP server becomes available, drastically reducing integration work and making it easier to reuse the same tool across different agents or models.
Not every task is best solved with a single, generalist agent. When a task is complex enough or spans different domains, it makes sense to split it among several specialized agents.
Single agent
A single agent with access to all the tools needed handles the entire task. It's simpler to build and debug, but becomes hard to maintain as the number of tools and responsibilities grows — the model has to reason over an ever-larger set of options at every step.
Multi-agent (orchestrator + specialized)
An orchestrator agent receives the request, breaks it into subtasks, and delegates each one to the appropriate specialized agent (for example, an inventory agent, a shipping agent, a customer-service agent). Each specialized agent has a narrower scope, making it easier to reason well about its specific domain and to test/maintain the system piece by piece.
When to prefer multi-agent
In a multi-agent system, agents need to pass information and tasks to each other in a structured way, not just free text. The most common patterns:
Orchestrator → specialized
The orchestrator agent sends a concrete subtask (with the necessary context) to a specialized agent, and waits for its result before continuing or delegating the next subtask.
Sequential handoff
An agent completes its part of the work and hands the result directly to the next agent in the chain, without going back through the orchestrator — useful in predictable linear flows.
Shared state
Agents read from and write to a common data space (for example, a session object or a shared database) instead of passing messages directly to each other.
An agent needs to remember information — but not all memory has the same scope or the same purpose.
Short-term memory
Exists only within an active conversation or session: the message history, intermediate results from tools already invoked, and the current reasoning state. It's lost when the session ends and is generally limited by the model's context window.
Long-term memory
Persists across different sessions: user preferences, facts learned in previous interactions, history of past decisions. It's usually implemented outside the model, storing relevant information in a database (often a vector one) and retrieving it when useful in a new session.
Why this distinction matters
An agent without long-term memory treats every session as if it were talking to the user for the first time. An agent with good memory management can, for example, remember that a customer prefers brief answers, or that they already reported a similar issue last week, without the user having to repeat that context every conversation.
An agent decides when and which tool to invoke by reasoning about the user's request against the list of available tools it was given (name, purpose, expected parameters).
1. Need assessment: The model determines whether it can answer using only its general knowledge or whether it needs external information/action to complete the task accurately.
2. Tool selection: If it needs to act, it chooses — among the described tools — the most suitable one for the current step, not necessarily for the whole task at once.
3. Parameter generation: It builds a structured call (not free text) with the correct arguments extracted from the user's request.
4. Result observation: It incorporates the result returned by the tool into its reasoning before deciding whether it needs another tool or can already respond.
The quality of the decision depends directly on how clear each tool's description is — ambiguous names or incomplete descriptions cause the agent to choose poorly or hallucinate parameters.
Workflow orchestration is the layer that coordinates multiple steps, tools, or agents to complete a complex task, managing execution order, dependencies between steps, and what to do when a step fails.
Sequential orchestration
Steps execute one after another, each using the previous one's result. Simple to reason about, but slower if some steps could run in parallel.
Dynamic orchestration
The model itself decides the next step in real time based on the results obtained so far, instead of following a fixed sequence predefined in advance.
In multi-agent systems, the orchestrator agent fulfills this role: it decides which specialized agent to delegate each subtask to, in what order, and how to combine the partial results into a coherent final response.
Besides Bedrock Agents (covered in the D3 module), AWS offers two other relevant pieces for building and operating agents, with distinct but complementary purposes.
Amazon Bedrock AgentCore
A platform designed to deploy and operate agents at scale in production: it manages aspects like runtime, identity, memory, and observability of agents, regardless of the framework they were built with. Its focus is operational — taking an already-designed agent into production reliably and scalably.
Strands Agents
AWS's open-source SDK for building agents: it provides the code scaffolding to define the agent's behavior, the tools it can use, and its reasoning logic. Its focus is development — the layer a team uses to build the agent's logic before operating it.
How they relate to each other
You can think of them as complementary layers: Strands Agents (or another framework) is used to build the agent's logic; AgentCore is used to operate that agent at scale in production; and Bedrock Agents is AWS's fully managed option when you'd rather build agents directly on top of Bedrock foundation models without managing the orchestration code separately. For the exam, it's enough to recognize the purpose of each, not memorize configuration details.
Scenario
A company needs an agent to check available inventory in a database, then call an external API from a shipping provider to calculate cost and delivery time, and finally notify the customer with the combined information — all from a single natural-language request.
Reasoned answer
This scenario describes exactly the pattern of an agent with chained tool use: the task requires invoking several different tools (database query, external API call, notification sending) in sequence, using the result of one step as the input of the next.
It's not a case of pure RAG (it's not about retrieving documents to ground a response), nor fine-tuning (it doesn't require changing the model's general behavior), nor a fixed-intent chatbot like Lex (the order of the three actions and their parameters depend on data only known at runtime). If, in addition, inventory, shipping, and notifications were domains maintained by different teams, it would be reasonable to split the task into a multi-agent pattern with an orchestrator delegating to specialized agents; with only three well-defined tools, a single agent with tool use already handles the case without needing that extra complexity.
Did you get this topic?
Test what you just learned
A company wants the same agent to use tools exposed by different internal systems (a database, a ticketing system, a file service) without writing a custom integration for each model-tool combination. Which technology is specifically designed to solve this problem?
Put what you learned to the test with original AIF-C01 exam questions.
Start AIF-C01 mock examUnlimited mock exams with the Pro plan
Log in to track your progress.