Agentic AI on AWS, hands-on labs by Shivank Agrawal

Your first
AI agent

Section 1. We start with a model that can only talk, and end with an agent that can think, use tools and act. Then you build one on Amazon Bedrock in about ten lines of Python.

Folder section-01-your-first-agent Notebook 01_hello_agent.ipynb Scripts hello_agent.py hello_langgraph_agent.py Model: Claude Sonnet 4.6 on Amazon Bedrock

Swipe sideways to see the full diagram

The journey in this section. Each step adds one ability. Steps 1 to 4 make the model know more. Step 5 is different in kind: the model starts doing things.

1.0

Why a plain LLM isn't enough

Large language models are brilliant, but on their own they are stuck inside what they learned during training. This section is about the two ways we break them out, without retraining the model.

A such as Claude learns by reading a huge amount of text, once, during . After that its knowledge is frozen. That creates four practical problems for anyone building a real product.

Swipe sideways to see the full diagram

The four walls around a plain LLM, and the two doors out. RAG fixes the first three walls by feeding the model fresh, private information. Agents fix the fourth by letting the model use tools to act.

✦Think of it like this

Picture the class topper who has read every book in the library, and is then locked in an exam hall. No phone, no newspaper, no access to your company's files. Ask about last night's IPL match and they can only guess. Ask them to book you a Tatkal ticket on IRCTC and the best they can do is explain how you would book it.

RAG is slipping the right pages under the door. An agent is giving them a phone, a laptop and permission to make calls on your behalf.

Two fixes that don't need retraining

You could or retrain the model on new data, but that is slow, costly, and goes stale again the moment your data changes. Two lighter approaches solve most problems instead:

RRetrieval Augmented Generation (RAG)

Before the model answers, fetch the most relevant pieces of your data and put them in the prompt. The model now answers from facts it can see. It knows more.

AAI agents

Give the model a goal, a set of tools, and a loop in which it can reason, call a tool, look at the result and decide what to do next. It can do things.

From "knowledge retriever" to "actor"

Many teams first build a RAG chatbot that answers questions about their own data. It works, and then users immediately ask for more:

"Don't just tell me the leave policy. Apply leave for Friday."
"Find a free slot with the design team and book the meeting."
"Update the ticket and tell the customer it's fixed."

Moving from a passive system that retrieves knowledge to an active one that takes action is exactly where most developers get stuck. This section gives you the blueprint for that move. Keep two questions in mind as you read:

What is the actual difference between a chatbot and an agent?
How do we go beyond clever prompts to systems that carry out tasks reliably?

The usual path looks like the journey at the top of this page: a basic LLM, then single prompts, then chatbots, then chatbots grounded with RAG, and finally agents that reason, use tools and act.

What you'll learn here

What RAG is and how it works
What agents are and what they can do
The AWS agentic stack
How systems grow from one LLM to many agents
Agent protocols: MCP and A2A
The Strands Agents SDK
Building your own "Hello World" agent

iAlready built agents before?

If you have shipped agents with LangGraph or CrewAI, parts 1.1 to 1.7 will feel like a refresher. Skim them for the shared vocabulary we use in every later section, then jump to the lab in 1.8.

1.1

RAG: an open book for the model

Retrieval Augmented Generation (RAG) lets a model answer from information it was never trained on, by finding the right text and handing it over just before the model answers.

RAG combines an LLM with an information retrieval system. The name tells you the three moves, in order:

R
Retrieve
Search an external (a database, an API, or a library of documents) for information related to the user's question.
A
Augment
Add that information (the context) to the original question, building one detailed .
G
Generate
The LLM reads the prompt and writes an answer that is factual and relevant, because the facts are right there in front of it.

✦Think of it like this

RAG turns a closed-book exam into an open-book exam. Before you answer, a helpful librarian runs to the shelves, brings back the three most relevant pages and places them on your desk. You still write the answer yourself, but now you are reading from the page instead of guessing from memory.

A worked example

Suppose a user asks: "Who won the 2024 Nobel Prize in Physics?" A model whose training ended before October 2024 simply cannot know. Here is how RAG handles it.

Swipe sideways to see the full diagram

Retrieve, augment, generate. The retrieval step finds the fact; the augment step glues it to the question; the model only has to read and phrase the answer. Swap the news database for your HR policies and the same three steps answer "how many leave days do I get?".

Try it

Same question, with and without retrieval

What reaches the model

What the model says

The full RAG pipeline

The three moves above hide some important engineering. A complete RAG system has two halves: work you do once to prepare your documents, and work that happens every time someone asks a question.

Swipe sideways to see the full diagram

Seven steps, two phases. Steps 1 to 4 build a searchable "memory" of your documents. Steps 5 to 7 use it for each question. The dashed border on step 6 means it is optional.

Step 1. Loading (ingesting) the data

Load the documents you want people to ask about: PDFs, wiki pages, web pages, support tickets, rows from a database. This step is called . Garbage in, garbage out: if a document is outdated here, every answer built on it will be outdated too.

Step 2. Chunking

Split each document into smaller pieces of text, called . Two reasons:

The model can only read so much at once. Every LLM has a , a maximum amount of text it can take in one go. You cannot paste a 2,000-page manual into one prompt.
Long inputs bury details. Models tend to pay most attention to the start and end of a long input and skim the middle. This is called the . In a long story, the model might miss a character who appears halfway through. Small, focused chunks avoid that.

Lost in the middle. A fact buried in the middle of a huge block is the one most likely to be missed. Chunking means each piece is short, so there is barely a "middle" to get lost in.

✦Think of it like this

Chunking is turning a thick textbook into a stack of revision flashcards. Before an exam you don't reread the whole book; you pull out the three cards that matter for this question.

Try it

Change the chunk size

Words per chunk = 25

Too small and a chunk loses meaning ("…carry forward to the next…"). Too big and you are back to one long block. Most teams start around a few hundred words, often with a little overlap between neighbouring chunks, and tune from there.

Step 3. Embedding

Each chunk is turned into an : a long list of numbers (a ) that captures what the text means. An embedding model does this. On AWS a common choice is Amazon Titan Text Embeddings v2, the same model we use for agent memory in Section 3 (amazon.titan-embed-text-v2:0).

The magic property: texts with similar meaning get vectors that sit close together, even if they share no words. "How many days off do I get?" lands near "Every employee gets 24 days of paid leave".

From words to coordinates. The values shown are illustrative. What matters is that similar meanings produce nearby vectors, so "searching by meaning" becomes "finding the nearest points".

✦Think of it like this

An embedding is a GPS coordinate for meaning. Koramangala and HSR Layout have different names but nearby coordinates. In the same way, "salary credited late" and "payroll delay" are different words with nearby vectors.

Try it

See meaning as distance

Real embeddings have around a thousand dimensions. We have squashed some sentences down to two so you can see them. Pick a question and watch where it lands and which neighbours it pulls in.

Step 4. Storage in a vector database

Each chunk is saved together with its vector in a (or vector store). These systems are built for one job: given a vector, quickly find the stored vectors closest to it. That is called . Common options:

Option	What it is	A good fit when
Amazon OpenSearch Service	Managed search and analytics service on AWS with vector search	You want a managed AWS service that scales to large collections
Pinecone	Fully managed, hosted vector database	You want a dedicated vector service with nothing to operate
FAISS	Open-source similarity-search library that runs inside your app	Experiments, notebooks and smaller, in-memory indexes
Chroma	Lightweight open-source vector database	Quick local development and prototypes
PostgreSQL + pgvector	An extension that adds vector columns to Postgres	You already run Postgres (for example Amazon RDS or Aurora)

There is no single best choice. It depends on how much data you have, how fast answers must be, and what your architecture already uses.

✦Think of it like this

A normal library shelves books alphabetically. A vector database is a library that shelves books by meaning: walk to the "monsoon" aisle and you find books on rain, flooding and umbrellas side by side, whatever their titles.

Step 5. Retrieval

When a user asks a question, the system embeds the question with the same embedding model, then asks the vector database for the closest chunks. It returns the results, where k is simply how many you want: the top 3, top 5 or top 10. These chunks become the supporting context for the model.

Step 6. Filtering and reranking (optional)

Similarity search is fast but rough. takes the retrieved chunks and scores them again with a more careful (and slower) model, and filtering drops chunks that are irrelevant or not allowed (old versions, another department's data). Both improve answer quality, but they add cost, latency and moving parts, so they are optional.

✦Think of it like this

Hiring at scale: a quick resume screen shortlists 50 candidates (retrieval), then a proper interview picks the best 3 (reranking). You only pay for interviews when the quick screen isn't good enough.

Step 7. Answer generation

The best chunks are passed to the language model together with the original question. The model writes a clear, relevant answer based on that retrieved information, ideally pointing to which chunk each fact came from.

Try it

Run the whole RAG pipeline on a tiny employee handbook

Or type your own question

Top k = 2 Rerank the retrieved chunks

Retrieve: every chunk, ranked by similarity to the question

Augment: the prompt sent to the model

Generate: the answer

This playground scores chunks by shared words, a toy stand-in for embeddings. Real embedding models match meaning, so they would also connect "days off" with "paid leave".

iWhere this goes next

Hold on to RAG. In the next part you will see that agents often use RAG as one of their tools, calling it only when they need facts.

1.2

What is an AI agent?

An agent is someone, or something, that does a task on your behalf. An AI agent uses an LLM to reason, plan and carry out tasks for people or for other systems.

are autonomous software systems. Their tasks can be as different as compiling research, paying bills, planning a trip or managing enterprise applications. They make decisions, adapt to new information and take action without needing a human to spell out every step. Many of them use RAG as part of their work to fetch the facts they need.

What really makes agents powerful is that they think iteratively: they try something, look at the result, adjust their approach, and keep going until the goal is reached.

?A chatbot

Like the enquiry counter at a railway station. Ask "When does the Shatabdi leave?" and you get an answer. You still have to queue, book, and check the PNR yourself.

AAn agent

Like a personal travel assistant. You say "get me to Chennai by Friday morning". They check trains and flights, book the best option, and message you if it's delayed.

An agent as a smart travel planner

A user asks: "What should I pack for New York in summer?" A plain chatbot would give generic advice. Watch what an agent does instead: it gathers facts from different places, combines them with what it knows about this user, then decides.

Swipe sideways to see the full diagram

Agentic RAG in action. The agent uses RAG for history, an API for live data and memory for this user, then reasons over all three. The answer is personal because the agent decided what to look up, not because someone scripted it.

Agent capabilities: plan, act, reason

RAG made LLMs better at answering by adding a retrieval step. Agents build on that foundation and go much further: they make decisions and take actions on their own, even for complex, multi-step tasks. They do it with three abilities, used in a loop:

1
Planning
Break a high-level objective into tasks that can actually be executed.
2
Acting
Use tools and information (such as knowledge bases) to carry out those tasks.
3
Reasoning
Look at the results of each action and update the plan, again and again, until the goal is achieved.

Plan, act, reason, repeat. A chatbot stops after one answer. An agent goes round this loop as many times as the task needs.

For example, an agent could fully automate scheduling a meeting: checking calendars, sending invites, booking a room, following up when someone declines, and updating the details. That is a job you would normally give a human executive assistant. Step through it below and notice the moment the plan has to change.

Try it

Watch an agent schedule a meeting

The agent's plan

What happens

Colour key in the log: plan, act, observe and reason.

The parts of an agent

Every agent, however fancy, is built from the same few parts. Learn this picture well; the rest of the course fills in each box.

Swipe sideways to see the full diagram

The agent is the coordinator, not the brain. The LLM does the thinking; the agent passes messages between the user, the LLM, the tools and memory, and keeps the plan moving.

Part	What it does	Examples	Covered in
Tools	External functions or APIs the agent uses to reach beyond its own knowledge and do things in the world	Search engine, database, calculator, code interpreter, weather API, a RAG pipeline	Section 2
Memory	Stores past interactions, short-term and long-term, so the agent keeps context and sees the bigger picture	This conversation so far; "this user prefers vegetarian food"	Section 3
Planning	Analyses the problem, works out the best order of actions, and decides which tool to use when. Strategy, not random actions	"First check calendars, then book the room, then send invites"	This section, Section 4
LLM	The core intelligence. The agent consults it to understand the request, draft responses and choose the next action, such as which tool to call. The relationship runs both ways	Claude Sonnet 4.6 or Claude Haiku 4.5 on Amazon Bedrock	This section

✦Think of it like this

An agent is a person at work. The LLM is the brain, the tools are the hands (phone, laptop, calculator), memory is the notebook on the desk, and the plan is the to-do list. A brain alone can't send an email; a pair of hands alone doesn't know which email to send. The agent is the whole person.

With this picture of how an agent is put together, let's see how these ideas map onto real services on AWS.

1.3

The AWS agentic stack

So far we have talked theory. Now we ground it in real services. AWS offers agent-building services at three levels of effort, and picking the right level is half of building a good agent.

Think of the AWS agentic AI landscape as a spectrum. At one end are ready-made apps for business users. In the middle are managed platforms for developers who want flexibility without running servers. At the other end are highly customisable services and specialised hardware for builders who need deep control.

✦Think of it like this

Dinner, three ways. Order on Swiggy: ready to eat, no effort, little choice (agentic applications). A meal kit: ingredients prepped and delivered, you cook it your way (managed solutions). Cook from scratch: buy the produce, own the kitchen, control every spice (do it yourself). This course cooks with the meal kit.

Swipe sideways to see the full diagram

Three tiers, one trade-off. Going down the stack you gain control and pay for it in effort. This course lives in the middle tier: Amazon Bedrock for models and safety features, Amazon Bedrock AgentCore for running agents in production.

Try it

Which tier fits you?

Pick a person above. The matching tier lights up in the diagram.

Tier by tier

Agentic applications

The top tier is fully managed, out-of-the-box agentic apps. They need minimal setup and the least effort, so they suit business users or anyone who wants AI quickly without deep technical skills. This tier started as the Amazon Q family (Amazon Q Business, Amazon Q Developer) and is moving to newer apps such as Amazon Quick Suite for business teams and Kiro, an agentic IDE, for developers.

iWe skip this tier

This course is about building agents with code, so we don't use the ready-made apps. Product names in this tier change often (Amazon Q Developer, for example, is being retired in favour of Kiro), so always check the current AWS documentation.

Managed solutions

More flexible than ready-made apps, but AWS still hides most of the infrastructure. Moderate effort, ideal for developers building custom agents without assembling every component. The two services we use throughout the course:

Amazon Bedrock is the key service for building and scaling generative AI apps. It gives you a choice of high-performing from Amazon and leading AI companies, all through a single API. Its features include:

Bedrock feature	What it does in plain words	In this course
Foundation models	Ready-to-call models such as Claude, Amazon Nova and Titan, paid per use	Every section
Guardrails	Safety policies that block harmful or off-topic input and output	Section 7
Agents	A managed way to create agents that run multi-step tasks	We build agents in code with Strands instead
Custom Model Import	Bring your own customised model into Bedrock and call it like any other	Concept only
Knowledge Bases	Managed RAG: connects to company data and grounds answers in it	Concept only
Model and RAG evaluation	Measures how good a model, a knowledge base or a RAG setup really is	Section 7 (agent evaluation)

Amazon Bedrock AgentCore is a secure, scalable platform for deploying and operating agents, so they can use tools and data without you managing infrastructure. It works with any framework (Strands, LangGraph, CrewAI…) and any model, combining open-source flexibility with enterprise-grade security and reliability. Its pieces map neatly onto the rest of this course:

Runtime: a fully managed, low-latency environment to deploy agents and tools (Section 6)
Memory: short- and long-term memory for agents (Section 3)
Gateway: turns existing APIs into tools agents can call (Section 6)
Observability, Evaluations, Policy: see, measure and control what agents do (Section 7)
Identity: who the agent is and what it may access on a user's behalf

Bedrock and AgentCore evolve quickly, so for the exact feature list always refer to the latest AWS documentation.

Do it yourself

The bottom tier gives maximum control. It provides the foundational infrastructure and tools to build, deploy and scale agentic apps from scratch, for experienced developers, ML engineers and researchers who want a say in everything from hardware to custom model architectures. Amazon SageMaker AI is the end-to-end service here: build, train and deploy machine-learning models at scale, including custom model development.

✦Think of Bedrock like UPI

UPI lets any app talk to any bank through one standard. Bedrock lets your code talk to models from many companies through one API. Switching from Claude Sonnet to Claude Haiku is changing one string, which is exactly what the BEDROCK_MODEL_ID variable does in our code.

Swipe sideways to see the full diagram

One front door, many models. Your agent code never changes when you change models. And if you customise a model in SageMaker AI, Custom Model Import brings it into Bedrock so it can be your agent's brain too.

iCustomising the brain

You can adapt an LLM to your domain in Amazon SageMaker AI (for example, by fine-tuning on your legal or medical documents) and then make it available in Bedrock through Custom Model Import. That domain-adapted model can then act as the reasoning engine, the "brain", of your agent.

Bedrock or SageMaker AI?

Most agent builders live in Bedrock and reach for SageMaker AI only when they need deeper control. Here is the side-by-side view.

Service	Best suited for	Strengths
Amazon Bedrock	Rapid development of generative AI apps and agents	Managed, serverless-style access to foundation models; one unified API; agent features; models from many providers
Amazon SageMaker AI	Advanced customisation, model training, fine-tuning and specialised deployment	Deep control over training, hosting, tuning and deployment; many endpoint and infrastructure options

In this course we use Amazon Bedrock to build and deploy agents, because it is a managed, API-first way to drive agent workflows with foundation models. SageMaker AI plays a supporting role for teams that need more: the agent's brain might be fine-tuned in SageMaker AI, or hosted on a SageMaker AI when a team wants tighter control over cost, latency or infrastructure. Together they cover everything from quick agent prototypes to heavily customised model deployments.

✦Think of it like this

Bedrock is booking an Uber: you pay per trip (per ), pick the car type, and never think about servicing. A SageMaker AI endpoint is leasing your own car: you choose exactly which car, keep it ready all day, and pay for it even while it's parked, in exchange for full control.

1.4

How an agent is built on AWS

Before we zoom into frameworks, here is the whole build in one picture: where you write code, what the code talks to, and how it reaches users.

Swipe sideways to see the full diagram

The blueprint for every agent in this course. Your app sits in the middle. It thinks by calling a model, acts by calling tools, and talks to people through a UI.

1
Write it in an IDE
A developer builds and configures the agentic app in an such as Visual Studio Code, Amazon SageMaker Studio, or an agentic IDE such as Kiro.
2
Use a framework
The app uses a such as LangChain or the Strands Agents SDK to define the agent's logic, orchestrate its workflow, and connect it to models and tools.
3
Call a model, the brain
An agent needs a reasoning engine to understand requests and decide what to do next, so the running app makes calls to model providers: Amazon Bedrock, or models hosted on Amazon SageMaker AI.
4
Reach tools, memory and other agents
At the same time, the app talks to tools, APIs, memory systems and other agents, over or , to fetch information, perform actions or collaborate.
5
Show the result
The output reaches the end user through a client application or user interface, where they interact with the agent.

✦STDIO vs HTTP(S), in one line each

STDIO is talking to a colleague sitting next to you: the tool runs on the same machine, and the two programs pass messages through standard input and output. HTTP(S) is phoning another office: the tool runs somewhere else and you reach it over the network.

The same blueprint, inside our first script

Here is hello_agent.py from the Section 1 folder. Even ten lines touch steps 2, 3 and 5. Step 4 (tools) arrives in the notebook you run in the lab.

section-01-your-first-agent/hello_agent.py (trimmed)

import os

from strands import Agent
from strands.models.bedrock import BedrockModel

MODEL_ID = os.getenv("BEDROCK_MODEL_ID", "global.anthropic.claude-sonnet-4-6")
REGION = os.getenv("AWS_REGION", os.getenv("AWS_DEFAULT_REGION", "us-east-1"))

model = BedrockModel(model_id=MODEL_ID, region_name=REGION)
agent = Agent(model=model)

response = agent("Hello! Tell me a fun fact about AI agents.")
print(response)

from strands import Agent Step 2: the framework (Strands Agents) supplies the agent logic.
BedrockModel(…) Step 3: the brain. Every call to the agent becomes an API call to Amazon Bedrock in your Region.
Agent(model=model) Step 2 again: model plus (later) tools plus (optionally) a system prompt make an agent.
print(response) Step 5: here the "UI" is just your terminal. In Section 6 it becomes a web app.

Now that you have seen how AWS supports the practical side of building agents, let's zoom out and look at how these systems grow up over time.

1.5

From one LLM to a team of agents

Agentic intelligence doesn't appear all at once. It grows in stages, from a single model answering questions to many agents working together. Each stage adds power, and adds risk.

Swipe sideways to see the full diagram

Six stages of agentic systems. Read the red arrow first: as systems get more capable, testing them, securing them, putting guardrails around them and being able to see what they are doing all become harder, and more important. Tap any stage to explore it.

Explore

Stage 1: LLM

What's new at this stage

Example

Where you meet it in this course

How much can go wrong

✦Why the red arrow grows

A bicycle needs a bell. A scooter needs a helmet and brakes. A car needs seatbelts, airbags and a dashboard. A fleet of buses needs all that plus a control room and traffic rules. More power, more ways to fail, so more safety and more visibility. Agents are the same; that's what Section 7 is about.

Stage 1. LLM

Using a foundation LLM directly: prompt it to write text, answer questions, summarise, translate. The interaction is usually a single turn or a simple conversation, with no tools and no multi-step decisions.

On AWS you have two ways to use a foundation model: models on Amazon Bedrock, which is , or models hosted on Amazon SageMaker AI, which is . (Remember the Uber vs leased car analogy.)

Example: asking Anthropic's Claude on Amazon Bedrock a question and getting a direct answer.

Stage 1 is a straight line. No lookups, no tools, no memory beyond the current conversation.

⌘In our code: `setup/check_setup.py`

The setup checker is a pure stage-1 call. It sends one message straight to the model through Bedrock's Converse API, with no agent and no tools:

setup/check_setup.py (excerpt)

runtime = boto3.client("bedrock-runtime", region_name=REGION)
for model_id in MODELS:
    try:
        r = runtime.converse(
            modelId=model_id,
            messages=[{"role": "user", "content": [{"text": "Reply with the single word: ready"}]}],
            inferenceConfig={"maxTokens": 10},
        )
        text = r["output"]["message"]["content"][0]["text"].strip()
        print(f"✅ {model_id}: {text}")
    except Exception as e:
        print(f"❌ {model_id}: {e}")

Stage 2. LLM + RAG

Here the LLM is in external knowledge through RAG. Instead of relying only on what it learned in training, the system first retrieves relevant information from enterprise documents, knowledge bases or databases, and passes it to the model as context. Answers become more accurate, more current and more specific to your domain.

Example: a chatbot that answers employees' questions using your internal HR policy documents.

Traditional RAG vs agentic RAG

You'll hear both terms. The difference is who decides when and how to retrieve.

Traditional RAG follows the same fixed path every time: user question → retrieve documents → send context to the LLM → generate answer. Ask "What is our company's leave policy?" and it fetches HR policy chunks and answers.

Agentic RAG treats retrieval as one tool among many inside an agent: question → agent reasons → maybe call the RAG tool → maybe call other tools → answer or act. The agent can decide when to retrieve, refine a search, use several sources, combine retrieval with APIs, and act on what it finds. The agent is the decision-maker; RAG is one capability it uses when needed.

Swipe sideways to see the full diagram

Fixed pipe vs decision-maker. Traditional RAG always retrieves, even when retrieval can't help. Agentic RAG picks the right source for each question, and can loop until it has what it needs.

Try it

Send the same question to both systems

Traditional RAG

Agentic RAG

Stage 3. Augmented LLM

Now the LLM is connected to external tools and data sources. This is the shift from a passive LLM to an active one.

Three pillars around the brain. Retrieval tells the LLM where to find information, tools let it act, and memory lets it keep track of what has happened so far.

The LLM is still the central brain, but on its own it is limited by its training cutoff and cannot touch the world. The augmented LLM adds three pillars. An effective agent knows where to find information (retrieval), how to use it to act (tools), and how to keep track of progress (memory). Understanding how these three talk to the LLM is the key to building reliable workflows on AWS.

Example: an LLM that searches the internet for live information before answering, or one that writes an email and then calls an email API to send it.

⌘In our code: `01_hello_agent.ipynb`, steps 4 and 5

When you give the agent the current_time tool and the prebuilt calculator, you have built an augmented LLM. The model can now get the real time and do exact arithmetic instead of guessing.

Stage 4. Agentic workflow, and stage 5. Autonomous agent

Agentic workflow. The LLM is no longer just answering; it becomes an agent that plans, reasons and executes a sequence of steps towards a goal. It breaks a complex task into sub-tasks, decides which tool each needs, runs them, and combines the results. Planning, memory and reflection usually come along.

Example: an agent booking a flight first checks availability through a flight API, compares prices, asks you about your preferences, and finally calls a booking API to complete the reservation.

Autonomous agent. A more advanced form of the agentic workflow, with more independence and persistence. It learns from its environment, adapts its plans and pursues long-term objectives without constant human input, using feedback loops and self-correction.

Swipe sideways to see the full diagram

The key visual difference: one has an end, the other doesn't. An agentic workflow is a task with a finish line. An autonomous agent is a loop that keeps watching, acting and learning, which is exactly why it needs the strongest guardrails.

Example of an autonomous agent: one that continuously monitors market trends, researches new investment opportunities, and executes trades on its own based on predefined strategies and risk limits.

✦Agentic workflow

A wedding planner with a checklist: venue, caterer, decorator, done. When the wedding is over, the job ends.

✦Autonomous agent

A self-driving car: it never stops perceiving the road, deciding, steering and correcting until the trip ends, and learns from every drive.

!Autonomy needs limits

An agent that trades money without asking anyone must have hard limits: maximum trade size, allowed instruments, a kill switch, and a full log of every decision. This is the red arrow from the stage diagram, made real.

Stage 6. Multi-agent collaboration

The most complex stage: several autonomous agents working together towards a shared goal. Each has a specialised role, its own knowledge or tools, and they communicate and coordinate to solve problems too big for one agent. It mimics how a human team works.

Swipe sideways to see the full diagram

A newsroom made of agents. Each agent is good at one thing, and the messages between them (violet) are where the coordination happens. Those messages are what agent protocols, coming next, standardise.

iWhere we build these

Agentic workflows, autonomous agents and multi-agent teams get full hands-on treatment in Section 4 (supervisor-worker, agent as a tool, graph and swarm patterns) and Section 5 (MCP and A2A).

Now that you understand how agents evolve and grow more complex, let's look at how they talk to tools and to each other.

1.6

Agent protocols: MCP and A2A

Big agent systems run into a plumbing problem: every agent needs to talk to many tools, and often to other agents. Protocols are the shared plugs and sockets that make this manageable.

An agent often has to call external tools, APIs or databases to fetch information or take actions it can't do alone. A travel agent asked to book a flight may need a flight API, the customer's profile and a payment service. As tools and workflows multiply, teams need one consistent way to connect agents to external systems. That is the problem solved by the Model Context Protocol (MCP), which standardises agent-to-tool communication.

Large systems also tend to use several specialised agents instead of one do-everything agent. A planner agent hands work to a booking agent, which in turn coordinates with a compliance or payment agent. Now the challenge is also agent-to-agent communication, which is what the Agent-to-Agent (A2A) protocol standardises.

Both exist so that agents and tools from different teams and vendors can work together without custom glue code for every pair. A is just an agreed set of rules for that conversation.

Swipe sideways to see the full diagram

Why protocols exist. Without a standard, every agent needs custom code for every tool, and the count explodes as you grow. With one, each side is built once and works with everything else that speaks it.

✦Think of it like this

Remember the drawer full of different phone chargers? USB-C fixed it: one socket shape, any device. Or think of UPI: before it, each payment app needed a deal with each bank; now any UPI app works with any bank. MCP is that idea for agents and tools, and A2A is that idea for agents and other agents.

Model Context Protocol (MCP)

MCP gives agents a standard way to discover and use tools when there are many of them. Its promise is write once, use anywhere: build an MCP server for your database once, and any MCP-aware app or agent can use it.

MCP was introduced by Anthropic in late 2024 as an open protocol, and is now governed by the Agentic AI Foundation under the Linux Foundation. It provides a standard way to connect AI models to virtually any data source or tool. It uses a design: you expose data and actions through lightweight MCP servers, and AI apps connect to them as MCP clients. Four parts make it work:

Part	What it is	USB-C version
Host	The program or AI tool that needs data through MCP: Claude Desktop, an IDE, or any AI application, including your own agent	Your laptop
Client	A protocol connector inside the host. Each client keeps a one-to-one connection with one server	One USB-C port
Server	A lightweight program that exposes capabilities through MCP and acts as a tool. It can offer tools (actions), resources (data to read) and prompts (reusable templates)	The device you plug in, like an external drive
Data sources	What a server connects to: local databases and file systems, or external systems over the internet through web APIs	The files on that drive

Swipe sideways to see the full diagram

Host, clients, servers, data. The host owns the AI and the clients; each server is a separate small program that wraps one system. Add a new system by adding a server, without touching the agent's code.

MCP in action: planning a warm January trip

Let's use the same travel agent, with a harder request: "Book a 5-day trip to Europe in January. We like warm weather." The host app (through its MCP clients) realises it needs outside data, connects through the protocol to specialised MCP servers for flights, hotels and weather, gets the data back, and gives the combined context to the LLM to produce a complete answer.

Swipe sideways to see the full diagram

The MCP workflow. Use the stepper below to light up one step at a time. Notice the host never talks to a database directly: it only ever speaks MCP to servers.

Step through

Follow one request through MCP

Pick step 1 to begin.

On the wire

// messages appear here

1
The request arrives
The user's natural-language request is sent to the MCP host.
2
The host works out what it needs
Using an LLM, the host understands the request and identifies the data it needs: flights, hotels and weather.
3
Clients call the servers
The host uses the MCP protocol to ask the right MCP servers for exactly that data.
4
Servers fetch from their sources
Each server reads its own data source (a database, a file system or a web API) and returns the information to the host.
5
The agent answers
The AI agents inside the host process all this combined information and fulfil the original request.

This is a distributed design: specialised MCP servers each handle access to one kind of data, and a central host, powered by an LLM for understanding and planning, coordinates them.

⌘Running MCP on AWS

MCP servers and clients can run on Amazon EKS or AWS Lambda, while the LLM is served by Amazon Bedrock or Amazon SageMaker AI inference. AWS also publishes an Amazon Bedrock AgentCore MCP server that helps you build agent components with built-in support for runtime, gateway integration, identity and memory. It suits rapid prototypes, production solutions, and scaling agent infrastructure across an enterprise.

You will write your own MCP server and client in Section 5 (section-05-mcp-and-a2a/mcp-basics) and connect a Strands agent to MCP tools, then turn APIs into MCP tools with AgentCore Gateway in Section 6.

Agent-to-Agent protocol (A2A)

A2A is an open standard for agents to discover each other and work together. Google introduced it in 2025; it is now also hosted by the Agentic AI Foundation, alongside MCP. It gives agents a common language even when they were built with different frameworks by different companies.

Why do we need it? Imagine building a trip planner. You need a hotel agent, an activity agent, a flight agent and a local guide agent, all coordinating. Building every one yourself is a lot of work. You would rather reuse agents that others have already built, but you have no idea how they are implemented inside. A2A gives you a standard way to collaborate with them anyway.

Swipe sideways to see the full diagram

One orchestrator, many independent agents. The travel agent doesn't handle the details itself, and doesn't need to know how any of these agents work inside. It only needs them to speak A2A.

Through A2A, the travel agent acts as the for the whole trip. It delegates specific tasks to specialised agents without understanding their internal code. Each agent, whoever built it and however, communicates using standard A2A messages. This decentralised approach means you don't rebuild every component, and good specialised agents get reused.

✦Think of it like this

A wedding planner doesn't cook, decorate or play music. They hire a caterer, a decorator and a DJ, agree on what's needed in a standard way (date, guests, budget, menu), and coordinate. They never need the caterer's recipes. A2A is that standard way of hiring and coordinating, for agents.

How A2A works

There are four players: the user, a client agent (Agent A, which acts for the user), and one or more remote agents (Agent B, the server, which does the work). The client agent sends tasks to remote agents over A2A and collects their results.

Swipe sideways to see the full diagram

Client and remote agents. The client agent works for the user and delegates. Remote agents publish an agent card describing what they can do, so the client knows whom to ask.

Agents advertise their capabilities with an , a small document usually published at /.well-known/agent-card.json. The client agent reads cards to find the best agent for a task, then uses A2A to talk to it. Here is roughly what the card of the flights agent you build in Section 5 looks like:

Agent card for a flights agent (illustrative)

{
  "name": "Flights Agent",
  "description": "Searches for and books flights between cities.",
  "url": "http://localhost:9002/",
  "version": "1.0.0",
  "capabilities": { "streaming": true },
  "defaultInputModes": ["text"],
  "defaultOutputModes": ["text"],
  "skills": [
    {
      "id": "search_flights",
      "name": "Search flights",
      "description": "Find available flights between two cities.",
      "tags": ["travel", "flights"],
      "examples": ["Find flights from London to Paris"]
    }
  ]
}

✦Think of it like this

An agent card is a visiting card plus a menu: who I am, where to reach me, and the list of dishes I can make. The client agent reads the menus and orders from the right kitchen.

Try it

Let the client agent find the right remote agent

submittedworkingcompleted

Pick a task. The client agent will scan each card's skills.

iMCP and A2A are partners, not rivals

They solve different problems and are used together in the same system.

MCP vs A2A side by side

	Model Context Protocol (MCP)	Agent-to-Agent protocol (A2A)
Main role	Connects an agent to tools, APIs and resources. Think: how an agent uses its capabilities (function calling)	Lets different agents communicate as peers. Think: how agents collaborate, delegate and manage tasks
Example	An agent uses MCP to call a weather API tool	A travel booking agent uses A2A to ask another agent to find flights
Relationship	Complementary, not competing	Complementary, not competing

Swipe sideways to see the full diagram

Down to tools, across to peers. MCP goes "down" from an agent to the tools it uses. A2A goes "across" between agents. A remote agent can use MCP for its own tools, and you never see that from outside.

✦Think of it like this

At work, using your laptop, the CRM and the printer is MCP. Emailing a colleague in the finance team and asking them to process an invoice is A2A. You need both to get anything done.

⌘Running A2A on AWS

A2A is supported on Amazon Bedrock AgentCore Runtime, so agents deployed there can discover peers, share capabilities and coordinate across platforms. You'll build A2A travel agents in Section 5 (section-05-mcp-and-a2a/a2a-travel-agents) and run a multi-agent system on AgentCore in Section 6.

1.7

Strands Agents and the agent loop

You now know the parts of an agent and the protocols around it. To actually build one, you need a framework that wires those parts together. In this course that framework is Strands Agents.

An agent framework gives you the building blocks: a way to define and orchestrate tools, store memory, and configure the LLM. As we saw in 1.4, popular frameworks include LangChain (with LangGraph) and Strands. We use Strands to build our "Hello World" agent, and here's why it feels so simple.

Strands Agents is an open-source from AWS that takes a model-driven approach to building and running agents with very little code. You describe the goal and hand over the tools; the LLM (for example, one on Amazon Bedrock) plans, reasons and chooses tools by itself.

Swipe sideways to see the full diagram

Who decides the steps? In workflow-driven code, you do, in advance, for every case. In model-driven code, the model decides at run time, using the tool descriptions you provide.

✦Think of it like this

Workflow-driven is giving a new driver turn-by-turn directions: if a road is closed, they're stuck. Model-driven is telling an experienced cab driver "Kempegowda airport, fastest route": they pick the roads, check traffic and reroute on their own.

Why Strands

Feature	What it means for you	Where you'll see it
Agents in a few lines	Define a prompt and some tools; that's an agent	This section
Easy tool integration	Turn any Python function into a tool, or use prebuilt and external tools and APIs	This section, Section 2
Model-agnostic	Works with many LLM providers, including Amazon Bedrock, Anthropic and more	`BedrockModel` in every lab
Multi-agent workflows	Build complex flows where several agents collaborate	Section 4
Safety and monitoring	Hooks for guardrails, prompt security and watching agent performance	Section 7

Inside Strands: the agent loop

This is the most important picture in the section. Every Strands agent, from the ten-line hello world to a production system, runs this loop. It's also called the or agentic workflow: take a high-level prompt, use a model to reason, use tools to act, and deliver a result.

Swipe sideways to see the full diagram

The loop that makes it an agent. The agent keeps going round: ask the model, run whatever tool it asks for, give the result back, ask again. It exits only when the model answers without asking for a tool.

Walking through the loop with a story prompt

Say the user's prompt is "Write a short story about a robot who wants to be a painter." That's the goal. Here is what happens, step by step.

1
Invoke the agent
The prompt is sent to the agent, the central orchestrator. Its job is to understand the prompt, plan how to fulfil it, and manage the conversation with the model and the tools.
2
Enter the agentic loop
Everything inside the dashed box is the loop, where the thinking and acting repeat.
3
Invoke the model
The agent sends the prompt (or a refined version, plus the conversation so far) to the model, the LLM.
4
Get a response
The model generates text based on its input.
5
Reasoning
The model understands the prompt, breaks it down and decides the next step. It might reason: "To write a story I need a character, a setting, a plot and an ending. I might want to look up some art ideas."
6
Tool selection
The model decides whether it needs an external tool. If the prompt had asked for an illustration too, it might choose an image generation API.
7
Execute the tool
If the model asks for a tool (to find information, make an image, do a calculation), the agent runs it. Tools are the external APIs or functions the agent has access to: image generation, text-to-speech, a search engine. For a plain story the model may need no tool; for "…and include an image of the robot's first painting" the agent would call the image API here.
8
Return the result
The tool does its job and sends its result back to the agent.
9
Go round again
With the tool result (or straight away, if no tool was needed) the agent calls the model again with the updated context. Ask the model, the model reasons and maybe picks a tool, the agent runs it, the result goes back in. This repeats until the prompt is fully handled.
10
Return the final response
When the work is done, the agent collects everything, including the story written by the model.
11
Result
The agent hands the result back to the user: the complete short story about the robot who wants to be a painter.

Run it

Agent loop simulator, using the prompts from our notebook

Tool results are real: the time comes from your browser clock and the maths is actually computed.

What the agent is doing

Conversation history the model sees (grows on every step)

[]

AaNew word: stop reason

Every model response comes with a that tells the agent what to do next. tool_use means "I need a tool, run it and come back to me". end_turn means "I'm done, here's my answer". That single field is what keeps the loop going or ends it.

iStrands in one sentence

Strands has three core ingredients, a model, tools and a prompt, plus the agentic feedback loop that lets the agent adapt to changing situations, handle the unexpected, and improve its result with every pass round the loop. Now let's build one.

1.8

Lab: your Hello World agent

Theory done. Now you set up your environment, check your AWS access, and build your first agent, adding a tool, a prebuilt tool and a system prompt one step at a time.

Everything for this lab is in the section-01-your-first-agent folder of the course code, plus two helpers in setup/.

File	What it does
`01_hello_agent.ipynb`	Start here. Model choice, a one-line agent, your own tool, a prebuilt tool, a system prompt
`hello_agent.py`	The smallest possible Strands agent, as a script
`hello_langgraph_agent.py`	The same idea built with LangChain and LangGraph: a ReAct agent with one tool
`requirements.txt`	The Python libraries this section needs
`setup/check_setup.py`	Pre-flight check: are your AWS credentials, Region and model access working?
`setup/iam-policy-course.json`	An IAM policy that covers every lab in the course (sandbox accounts only)

What you need

1
Python 3.10 or newer
3.11 or 3.12 is recommended. Check with python3 --version.
2
An AWS account
Use a sandbox or learning account, never a production one. Work in Region us-east-1 (N. Virginia), where every AgentCore feature used in the course is available.
3
Tools on your machine
AWS CLI v2, Git, and Jupyter (JupyterLab or VS Code with the Jupyter extension). Windows users: run shell scripts from WSL or Git Bash.
4
Access to the models on Amazon Bedrock
Bedrock's serverless models are now enabled by default; there's no model-access page to click through any more. One exception: Anthropic models need a one-time "first time use" form per AWS account (or once for the whole organisation). If your first Claude call says AccessDeniedException, open the Bedrock console, pick a Claude model, and submit the form. The first-ever use of a model also needs AWS Marketplace subscribe permissions and a valid payment method on the account.
5
IAM permissions
Permissions attached to your user, role or SSO permission set. Details just below.
6
A development environment
Either your own laptop with VS Code, Kiro, Cursor or JupyterLab (Option A), or Amazon SageMaker Studio with a JupyterLab space (Option B).

The models used in this course

Model	ID used in the code	Used for
Claude Sonnet 4.6 (default)	`global.anthropic.claude-sonnet-4-6`	Strong reasoning and tool use; the default brain
Claude Haiku 4.5	`global.anthropic.claude-haiku-4-5-20251001-v1:0`	Faster and cheaper: memory, evaluation judge, Lambda
Titan Text Embeddings v2	`amazon.titan-embed-text-v2:0`	Embeddings for agent memory (Section 3)

The global. prefix is a : Bedrock routes each request to whichever AWS Region can serve it best, and it works from any supported source Region, including India. To switch the model everywhere without touching code, set an environment variable:

terminal

export BEDROCK_MODEL_ID=global.anthropic.claude-haiku-4-5-20251001-v1:0

Swipe sideways to see the full diagram

One agent call, end to end. If anything fails, it's almost always the red box (credentials or permissions) or the Region. That's exactly what check_setup.py tests first.

IAM permissions

decides what your user or role may do. At a minimum, this section needs permission to call Bedrock models. Later sections need more:

bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream: call models, with and without streaming (needed now)
sagemaker:InvokeEndpoint: only if you call models hosted on SageMaker AI
s3:GetObject and s3:PutObject: read and write data and artefacts
bedrock-agentcore:*: needed for AgentCore in Sections 3, 6 and 7

In a sandbox account, an administrator user is simplest. Otherwise attach setup/iam-policy-course.json, which covers every lab in the course. It is deliberately broad, because labs create roles, gateways and Lambda functions, so treat it as sandbox-only.

✦Think of it like this

IAM is your office access card. Credentials prove who you are at the gate; the policy decides which doors your card opens. bedrock:InvokeModel is the door to the model room. No door, no answer, however correct your code is.

Laptop or SageMaker Studio?

Requirement	Option A: your laptop	Option B: SageMaker Studio
AWS credentials	`aws configure`, AWS SSO, or environment variables	Automatic, from the Studio execution role
IAM permissions	Attach to your IAM user, role or SSO permission set	Attach to the execution role
Bedrock model access	On by default; submit the Anthropic first-time use form once	Same
Python packages	`pip install` into a virtual environment	`%pip install` inside the notebook
Compute	Your own machine	A JupyterLab space, `ml.m5.large` or bigger, at least 20 GB storage

Set up your environment

Option A: your laptop (VS Code, Kiro, Cursor or JupyterLab)

1
Connect to your AWS account
With access keys use aws configure. With IAM Identity Center (the AWS access portal), use SSO and export the profile name so every tool picks it up.
2
Create a virtual environment
A keeps this course's libraries separate from everything else on your machine.
3
Set the Region and run the check
Point everything at us-east-1, then run the pre-flight script.

terminal: 1. credentials

aws configure                 # access key, secret, region = us-east-1
# or, with IAM Identity Center:
aws configure sso && aws sso login --profile my-profile && export AWS_PROFILE=my-profile

terminal: 2 and 3. environment and check

cd future-with-shivank-agentic-ai-on-aws
python3 -m venv .venv && source .venv/bin/activate      # Windows: .venv\Scripts\activate
pip install --upgrade pip boto3

export AWS_REGION=us-east-1
export AWS_DEFAULT_REGION=us-east-1

python setup/check_setup.py

You should see a ✅ for both models. Something like this:

expected output (your values will differ)

Python  : 3.12.4
Account : 123456789012
Caller  : arn:aws:sts::123456789012:assumed-role/AWSReservedSSO_CourseAdmin_1a2b3c/learner
Region  : us-east-1
✅ global.anthropic.claude-sonnet-4-6: ready
✅ global.anthropic.claude-haiku-4-5-20251001-v1:0: ready

If both models replied, you're ready for Section 1.

setup/check_setup.py

"""Quick pre-flight check: AWS credentials, region, and Bedrock model access.

Run:  python setup/check_setup.py
"""

import os
import sys

import boto3

REGION = os.getenv("AWS_REGION", os.getenv("AWS_DEFAULT_REGION", "us-east-1"))
MODELS = [
    os.getenv("BEDROCK_MODEL_ID", "global.anthropic.claude-sonnet-4-6"),
    "global.anthropic.claude-haiku-4-5-20251001-v1:0",
]

print(f"Python  : {sys.version.split()[0]}")
if sys.version_info < (3, 10):
    print("  ❌ Python 3.10+ is required (3.11 or 3.12 recommended)")

try:
    ident = boto3.client("sts", region_name=REGION).get_caller_identity()
    print(f"Account : {ident['Account']}")
    print(f"Caller  : {ident['Arn']}")
except Exception as e:
    sys.exit(f"❌ AWS credentials not working: {e}")

print(f"Region  : {REGION}")

runtime = boto3.client("bedrock-runtime", region_name=REGION)
for model_id in MODELS:
    try:
        r = runtime.converse(
            modelId=model_id,
            messages=[{"role": "user", "content": [{"text": "Reply with the single word: ready"}]}],
            inferenceConfig={"maxTokens": 10},
        )
        text = r["output"]["message"]["content"][0]["text"].strip()
        print(f"✅ {model_id}: {text}")
    except Exception as e:
        print(f"❌ {model_id}: {e}")

print("\nIf both models replied, you're ready for Section 1.")

REGION = os.getenv(…) Read the Region from the environment, falling back to us-east-1.
MODELS = […] The two models every lab relies on: your chosen default and Haiku.
sys.version_info Fail early if Python is too old.
get_caller_identity() Asks AWS "who am I?". If this fails, your credentials are the problem, not your code.
runtime.converse(…) A real, tiny model call capped at 10 tokens. If this fails but STS worked, the problem is permissions, the Region, or model access.

Option B: Amazon SageMaker Studio

In Studio, credentials come from the execution role automatically, so there's no aws configure. Attach the permissions above to that execution role.

1
Open your domain
In the SageMaker AI console, choose Domains in the navigation pane, then open your domain.
2
Go to Studio
In the navigation pane, under Applications and IDEs, choose Studio.
3
Launch Studio for your user
On the User profiles tab, find your user profile, then choose Launch and Studio.

Swipe sideways to see the full screen

Launching SageMaker Studio from your user profile (simplified). The console layout changes from time to time, but the path stays the same: Domains, your domain, User profiles, Launch, Studio.

4
Create and run a JupyterLab space
In Studio, open JupyterLab, create a space, choose an ml.m5.large instance (or bigger) with at least 20 GB of storage, choose Run space, then Open JupyterLab.

Swipe sideways to see the full screen

A running JupyterLab space (simplified). Pick the instance type before you run the space; you can stop it any time to stop paying for it.

5
Bring in the course code
Upload the course code with JupyterLab's upload button (or clone it if you have it in a Git repository). Open a terminal (File, New, Terminal). If you uploaded a zip, unzip it, then go into the Section 1 folder.
6
Install and restart
Open 01_hello_agent.ipynb and run the first cell to install the libraries. Then restart the kernel (Kernel, Restart) so Python picks up what you just installed.

JupyterLab terminal

unzip future-with-shivank-agentic-ai-on-aws.zip
cd future-with-shivank-agentic-ai-on-aws/section-01-your-first-agent

AaNew word: kernel

The is the Python process running behind a notebook. Libraries installed while it's running aren't always visible to it, so after installing you restart it to start fresh.

Build it, step by step

Open 01_hello_agent.ipynb (in JupyterLab or VS Code) and run each cell in order. The notebook is organised as Steps 1 to 6; here is every code cell, with what it does and why.

Step 1. Install the dependencies

01_hello_agent.ipynb, Step 1

%pip install -q -r requirements.txt

requirements.txt

# Section 1 — Your First AI Agent
strands-agents>=1.60.0,<2.0.0
strands-agents-tools>=0.8.9,<0.9.0
langchain>=1.4.0,<2.0.0
langchain-aws>=1.8.0,<2.0.0
langgraph>=1.2.0,<2.0.0
boto3>=1.40.0

strands-agents The Strands Agents SDK: Agent, tool, BedrockModel.
strands-agents-tools Ready-made tools, such as calculator.
langchain, langchain-aws, langgraph Only for the LangGraph comparison script.
boto3 The AWS SDK for Python; Strands uses it under the hood to call Bedrock.
>=1.60.0,<2.0.0 Version ranges: new enough for our code, but not a future major version that might break it.

Step 2. Choose the model

Every example in the course reads the model from one variable. Change it here, or set BEDROCK_MODEL_ID, to try a different model: global.anthropic.claude-sonnet-4-6 (default, strong reasoning and tool use) or global.anthropic.claude-haiku-4-5-20251001-v1:0 (faster and cheaper).

01_hello_agent.ipynb, Step 2

import os

MODEL_ID = os.getenv("BEDROCK_MODEL_ID", "global.anthropic.claude-sonnet-4-6")
REGION = os.getenv("AWS_REGION", os.getenv("AWS_DEFAULT_REGION", "us-east-1"))
os.environ.setdefault("AWS_REGION", REGION)

print(f"Model : {MODEL_ID}")
print(f"Region: {REGION}")

✦Think of it like this

os.getenv("NAME", default) is a settings knob that lives outside the code: "use the value of this environment variable if someone set it, otherwise use the default". That's how one notebook runs on Sonnet for you and Haiku for a classmate, with no edits.

Step 3. Create your first agent

01_hello_agent.ipynb, Step 3

from strands import Agent
from strands.models.bedrock import BedrockModel

model = BedrockModel(model_id=MODEL_ID, region_name=REGION)

# An agent = a model + (optional) tools + (optional) system prompt
agent = Agent(model=model)

response = agent("Explain Amazon Bedrock AgentCore in three sentences.")

The whole recipe. Steps 4, 5 and 6 below each fill in one of the optional slots.

The agent its answer as it generates it, so you see words appear live. The returned response object holds the full result: the final text, the token usage, and the stop reason.

01_hello_agent.ipynb, Step 3, next cell

print("Stop reason:", response.stop_reason)
print("Tokens used:", response.metrics.accumulated_usage)

example output (numbers will differ)

Stop reason: end_turn
Tokens used: {'inputTokens': 21, 'outputTokens': 112, 'totalTokens': 133}

end_turn means the model finished without asking for a tool, so the loop ran exactly once. are what you pay for: input tokens (what you sent) plus output tokens (what it wrote).

The script version, hello_agent.py, is the same thing outside a notebook:

section-01-your-first-agent/hello_agent.py

"""Section 1: Hello World agent with the Strands Agents SDK on Amazon Bedrock.

Run:
    python hello_agent.py
"""

import os

from strands import Agent
from strands.models.bedrock import BedrockModel

# One place to choose the model. Override without editing code:
#   export BEDROCK_MODEL_ID=global.anthropic.claude-haiku-4-5-20251001-v1:0
MODEL_ID = os.getenv("BEDROCK_MODEL_ID", "global.anthropic.claude-sonnet-4-6")
REGION = os.getenv("AWS_REGION", os.getenv("AWS_DEFAULT_REGION", "us-east-1"))

model = BedrockModel(model_id=MODEL_ID, region_name=REGION)
agent = Agent(model=model)

response = agent("Hello! Tell me a fun fact about AI agents.")
print()
print("-" * 60)
print(response)

iWhy you see the answer twice

Run python hello_agent.py and the answer appears, then a line of dashes, then the same answer again. The first copy is Strands streaming the text live as the model writes it. The second is print(response) printing the final result object. The dashes are there so you can tell them apart.

Step 4. Give the agent a tool

A tool is just a Python function with three things: the @tool , so the model knows what arguments to send, and a so the model knows when to use it.

01_hello_agent.ipynb, Step 4

from datetime import datetime
from zoneinfo import ZoneInfo

from strands import tool


@tool
def current_time(timezone: str = "Asia/Kolkata") -> str:
    """Get the current date and time in a given IANA timezone.

    Args:
        timezone: IANA timezone name, for example "Asia/Kolkata" or "America/New_York".
    """
    return datetime.now(ZoneInfo(timezone)).strftime("%A, %d %B %Y %I:%M %p %Z")


agent = Agent(model=model, tools=[current_time])
agent("What time is it right now in Bangalore and in New York?")

How each part of the function is used

@
@tool
Registers the function as a tool the agent can offer to the model.
:
timezone: str = "Asia/Kolkata"
Becomes the input schema: one text argument, optional, with a default.
"
The docstring
Becomes the description. The model reads it to decide whether this tool fits the question.

Roughly what the model is shown

{ "name": "current_time", "description": "Get the current date and time in a given IANA timezone.", "inputSchema": {"json": { "type": "object", "properties": { "timezone": { "type": "string", "description": "IANA timezone name, for example \"Asia/Kolkata\" or \"America/New_York\"." } }, "required": [] }} }

✦Think of it like this

The docstring is the description on a restaurant menu. The waiter (the model) can't taste the food in the kitchen (your code); it recommends a dish only from what the menu says. Vague menu, wrong dish. That's why good docstrings matter so much in Section 2.

Ask about Bangalore and New York, and the model will request current_time twice, once per timezone, read the two results and answer. That's the agent loop from 1.7, with real tools. You can replay it in the loop simulator above.

Step 5. Use a prebuilt tool

strands-agents-tools ships ready-made tools. Here the agent gets a calculator so it doesn't have to do arithmetic "in its head", which LLMs are surprisingly unreliable at.

01_hello_agent.ipynb, Step 5

from strands_tools import calculator

agent = Agent(model=model, tools=[calculator, current_time])
agent("What is 18% GST on a laptop that costs Rs 84,999? Give me the final price too.")

Expected numbers: GST = 84,999 × 0.18 = ₹15,299.82, final price = ₹1,00,298.82. Notice the agent has two tools but uses only the one it needs.

Step 6. Shape behaviour with a system prompt

The sets the agent's role, tone and rules for every turn of the conversation.

01_hello_agent.ipynb, Step 6

agent = Agent(
    model=model,
    system_prompt=(
        "You are a patient tutor for engineers who are new to AI agents. "
        "Explain ideas with one real-world analogy and keep answers under 120 words."
    ),
)
agent("What is the difference between an LLM and an AI agent?")

✦Think of it like this

A system prompt is the briefing a new employee gets on day one: who you are here, how you talk to customers, what you never do. The user's prompt is each customer's request; the briefing applies to all of them.

Try it

Agent builder: switch things on and watch the code change

Model

Tools

System prompt

Add a system prompt

my_agent.py (generated)

✓What you just did

Built an agent in one line, added your own tool and a prebuilt tool, and controlled its behaviour with a system prompt. Next, run the two scripts in the folder to see the same idea as plain Python files, including one built with LangGraph.

The same idea in LangGraph

Strands isn't the only way. hello_langgraph_agent.py builds the same kind of agent with LangChain's create_agent, which runs on the LangGraph runtime and replaces the older langgraph.prebuilt.create_react_agent. It builds a agent: reason, act with a tool, observe, repeat. The same loop you met in 1.7, just with different wording.

section-01-your-first-agent/hello_langgraph_agent.py

"""Section 1: Hello World agent with LangGraph / LangChain on Amazon Bedrock.

`create_agent` (from langchain.agents) is the current way to build a
ReAct-style agent that runs on the LangGraph runtime. It replaces the older
`langgraph.prebuilt.create_react_agent`.

Run:
    python hello_langgraph_agent.py
"""

import os

from langchain.agents import create_agent
from langchain.chat_models import init_chat_model
from langchain.tools import tool

MODEL_ID = os.getenv("BEDROCK_MODEL_ID", "global.anthropic.claude-sonnet-4-6")
REGION = os.getenv("AWS_REGION", os.getenv("AWS_DEFAULT_REGION", "us-east-1"))


# A simple tool the agent can call
@tool
def greet(name: str) -> str:
    """Greet someone by name."""
    return f"Hello, {name}! Welcome to the world of AI agents."


# Initialize the LLM via the Bedrock Converse API
llm = init_chat_model(MODEL_ID, model_provider="bedrock_converse", region_name=REGION)

# Create a ReAct agent with the tool
agent = create_agent(model=llm, tools=[greet], system_prompt="You are a friendly assistant.")

# Run the agent
response = agent.invoke({"messages": [{"role": "user", "content": "Please greet Alice and Bob."}]})

# Print every message in the conversation: user -> AI (tool calls) -> tool results -> AI answer
for message in response["messages"]:
    print(f"{message.type}: {message.text}")

Because the script prints every message, you can see the loop itself in the output:

example output (wording will differ)

human: Please greet Alice and Bob.
ai: I'll greet both Alice and Bob for you!        ← model asks for greet("Alice") and greet("Bob")
tool: Hello, Alice! Welcome to the world of AI agents.
tool: Hello, Bob! Welcome to the world of AI agents.
ai: I've greeted both Alice and Bob! They've been welcomed to the world of AI agents.

Idea	Strands	LangChain / LangGraph
Model	`BedrockModel(model_id=…)`	`init_chat_model(…, model_provider="bedrock_converse")`
Tool	`@tool` from `strands`	`@tool` from `langchain.tools`
Agent	`Agent(model, tools, system_prompt)`	`create_agent(model, tools, system_prompt)`
Run it	`agent("…")`	`agent.invoke({"messages": […]})`

Strands vs LangChain vs LangGraph: which when?

	Strands Agents	LangChain	LangGraph
Approach	Agent-first SDK: model + tools + prompt	Building blocks: prompts, parsers, loaders, integrations	Stateful graph orchestration
Boilerplate	Minimal	Moderate	More setup, more control
State	Built in (plus AgentCore Memory or session managers)	Manual	Built in, with checkpointers
Best for	Fast, AWS-native agents	RAG pipelines and integrations	Complex flows with loops, branches, human-in-the-loop

Swipe sideways to see the full diagram

A quick decision guide. Graph and swarm patterns are in Section 4, AgentCore Memory in Section 3, AgentCore Runtime in Section 6.

✦Think of it like this

Strands is an automatic car: get in and drive. LangChain is a box of Lego: every part you could want, you assemble them. LangGraph is designing a metro map: you draw every station and track, so you control exactly where each train can go, including loops and stops where a human gets on.

When something goes wrong

Error	What it usually means and how to fix it
`AccessDeniedException` calling Bedrock	Check IAM permissions and that `AWS_REGION` is set. For Claude models, make sure the Anthropic first-time use form has been submitted for the account.
`ValidationException … model identifier is invalid` or "on-demand throughput isn't supported"	Use an inference-profile ID (with `global.` or `us.`), as in the model table.
`ResourceNotFoundException … Legacy model` or end-of-life	That model was retired. Set `BEDROCK_MODEL_ID` to a current model.
`ThrottlingException`	Too many requests. Wait a minute and retry; use Haiku for bulk runs.
Credentials errors or "token has expired"	Your SSO session ran out. Run `aws sso login --profile my-profile` again.
`ModuleNotFoundError` in a notebook	Run the `%pip install -r requirements.txt` cell, then restart the kernel.

₹Cost and clean-up

This section creates no AWS resources; you only pay per model call, which for these labs is a few cents. There's nothing to clean up. Later sections that create resources end with a clean-up cell or a cleanup.sh script; always run it before moving on.

1.9

Recap and self-check

You now have the foundation every later section builds on.

We traced how agentic intelligence grows, from a plain LLM to teams of agents. RAG gives a model fresh, private knowledge by retrieving the right chunks before it answers. Agents go further: they plan, act with tools, reason about results, and loop until the job is done. We looked at the protocols that let agents plug into tools (MCP) and into each other (A2A), and at why they complement each other.

We mapped the AWS agentic stack and saw why Amazon Bedrock (with AgentCore) and Amazon SageMaker AI cover everything from quick prototypes to heavily customised models. Then we moved from theory to practice with the Strands Agents SDK, its model-driven agent loop, and your own Hello World agent: one line to create it, a decorator to give it a tool, a prebuilt calculator, and a system prompt to shape it.

You should now be able to explain

Idea	In one line
RAG	Retrieve relevant chunks, add them to the prompt, let the model generate from them
Chunk, embedding, vector DB	Small pieces of text, their meaning as numbers, and a store that finds the nearest ones fast
Agent	An LLM in a loop with tools and memory: plan, act, reason, repeat
AWS agentic stack	Ready-made apps, managed services (Bedrock, AgentCore), or do-it-yourself (SageMaker AI)
Six stages	LLM, LLM + RAG, augmented LLM, agentic workflow, autonomous agent, multi-agent; risk grows with each
MCP vs A2A	MCP connects an agent to tools; A2A connects agents to agents; use both
Strands agent loop	Invoke model, run requested tools, return results, repeat until `end_turn`
Hello World agent	`Agent(model=BedrockModel(...), tools=[...], system_prompt=...)`

Self-check

Ten quick questions. Pick an answer to see why it's right or wrong.

Score: 0 of 10 answered

→Up next: Section 2, agent tools

You've given your agent a brain. Next you give it hands: building your own tools with @tool, using prebuilt and AWS-aware tools like use_aws, and advanced patterns such as class-based and async tools. Folder: section-02-agent-tools.

A–Z

Glossary

Every underlined word on this page, in one place.

Your firstAI agent

Why a plain LLM isn't enough

✦Think of it like this

Two fixes that don't need retraining

RRetrieval Augmented Generation (RAG)

AAI agents

From "knowledge retriever" to "actor"

What you'll learn here

iAlready built agents before?

RAG: an open book for the model

Retrieve

Augment

Generate

✦Think of it like this

A worked example

Same question, with and without retrieval

The full RAG pipeline

Step 1. Loading (ingesting) the data

Step 2. Chunking

✦Think of it like this

Change the chunk size

Step 3. Embedding

✦Think of it like this

See meaning as distance

Step 4. Storage in a vector database

✦Think of it like this

Step 5. Retrieval

Step 6. Filtering and reranking (optional)

✦Think of it like this

Step 7. Answer generation

Run the whole RAG pipeline on a tiny employee handbook

iWhere this goes next

What is an AI agent?

?A chatbot

AAn agent

An agent as a smart travel planner

Agent capabilities: plan, act, reason

Planning

Acting

Reasoning

Watch an agent schedule a meeting

The parts of an agent

✦Think of it like this

The AWS agentic stack

✦Think of it like this

Which tier fits you?

Tier by tier

Agentic applications

iWe skip this tier

Managed solutions

Do it yourself

✦Think of Bedrock like UPI

iCustomising the brain

Bedrock or SageMaker AI?

✦Think of it like this

How an agent is built on AWS

Write it in an IDE

Use a framework

Call a model, the brain

Reach tools, memory and other agents

Show the result

✦STDIO vs HTTP(S), in one line each

The same blueprint, inside our first script

From one LLM to a team of agents

Stage 1: LLM

✦Why the red arrow grows

Stage 1. LLM

⌘In our code: setup/check_setup.py

Stage 2. LLM + RAG

Traditional RAG vs agentic RAG

Send the same question to both systems

Stage 3. Augmented LLM

⌘In our code: 01_hello_agent.ipynb, steps 4 and 5

Stage 4. Agentic workflow, and stage 5. Autonomous agent

✦Agentic workflow

✦Autonomous agent

!Autonomy needs limits

Stage 6. Multi-agent collaboration

iWhere we build these

Agent protocols: MCP and A2A

Your first
AI agent

⌘In our code: `setup/check_setup.py`

⌘In our code: `01_hello_agent.ipynb`, steps 4 and 5