DEV Community: Jamal

# 🤖 Lab 07: Building Multi-Agent Systems with an Orchestrator | Strands Agentic AI

Jamal — Sun, 31 May 2026 06:06:09 +0000

So far in this series, we've built agents, custom tools, MCP integrations, and MCP servers.

But real-world AI applications often require multiple specialists working together.

Instead of creating one giant agent responsible for everything, we can create multiple specialized agents and use a central orchestrator to route requests to the right expert.

In this lab, we'll build:

A Study Assistant
An Expense Assistant
An Orchestrator Agent

The orchestrator will decide which specialist should handle the user's request.

By the end of this tutorial, you'll understand one of the most important patterns in Agentic AI: Multi-Agent Architectures.

📚 Strands Agentic AI Lab Series

⬅️ Previous: Lab 07: Build Your First MCP Server

📍 Current: Lab 08: Building Multi-Agent Systems

➡️ Next: Lab 09: Agent Collaboration & Sequential Workflows

🚀 What You'll Learn

In this lab, you'll learn:

What multi-agent systems are
Why specialized agents outperform general-purpose agents
How to build reusable agents
How to create an orchestrator agent
How to route requests dynamically
How to add logging for debugging

🤖 Why Multi-Agent Systems?

Imagine building a personal assistant that can help with:

Studying
Budgeting
Fitness
Travel
Career Advice

You could create one massive prompt.

Or you could create specialists.

```text id="w70n8v"
User
↓
Orchestrator
↓
├── Study Agent
├── Expense Agent
├── Fitness Agent
└── Travel Agent




This approach is:

✅ Easier to maintain

✅ Easier to scale

✅ Easier to test

✅ More accurate

This architecture is commonly used in enterprise AI systems.

---

## 🛠️ Prerequisites

Before starting, make sure you have:

* Python 3.10+
* Strands SDK
* AWS Account
* Amazon Bedrock access
* AWS credentials configured
* uv installed

---

## 🏗️ Architecture Overview

Our application looks like this:



```text id="hkxgx6"
User
  ↓
Orchestrator Agent
  ↓
 ├── study_assistant()
 │      ↓
 │   Study Agent
 │
 └── expense_assistant()
        ↓
     Expense Agent

The orchestrator never answers directly.

Its job is to decide which specialist should handle the request.

📜 The Complete Script

This lab introduces:

Reusable agent creation
Specialized agents
Tool-based routing
Agent orchestration
Structured logging

Let's break it down step by step.

⚙️ Step 1: Configure Logging

```python id="ej58br"
logging.basicConfig(
level=logging.DEBUG,
format="%(asctime)s | %(levelname)s | %(message)s",
)




Logging helps us understand:

* Which agent was selected
* Which tool was called
* What response was generated
* Any errors that occurred

Example:



```text id="y4dkvh"
INFO | User query received
INFO | study_assistant called
DEBUG | Study response generated

This becomes incredibly useful when debugging complex multi-agent systems.

⚙️ Step 2: Configure the Bedrock Model

```python id="h3c66o"
bedrock_model = BedrockModel(
model_id="",
region_name="eu-west-2",
temperature=0.3,
)




All agents in this lab share the same Bedrock model.

This keeps the architecture simple.

In production, different agents may use different models.

---

## ⚙️ Step 3: Create a Reusable Agent Factory



```python id="o5j5dr"
def create_agent(
    name: str,
    system_prompt: str
) -> Agent:

This helper function creates specialized agents.

Benefits:

Less code duplication
Consistent configuration
Easier maintenance

Instead of repeating:

```python id="4mgv3u"
Agent(...)
Agent(...)
Agent(...)




we centralize the logic.

---

## ⚙️ Step 4: Create Specialized Agents

### Study Agent



```python id="m9l6bf"
study_agent = create_agent(
    name="study_agent",
    system_prompt="""
    You are a study assistant.
    Help users create learning plans.
    """
)

Responsibilities:

Learning plans
Courses
Certifications
Exams
Technical concepts

Expense Agent

```python id="sz9rj6"
expense_agent = create_agent(
name="expense_agent",
system_prompt="""
You are an expense assistant.
Help users manage budgets.
"""
)




Responsibilities:

* Budgeting
* Savings
* Spending analysis
* Cost reduction
* Financial planning

Each agent becomes an expert in its own domain.

---

## ⚙️ Step 5: Expose Agents as Tools

### Study Tool



```python id="e4qj98"
@tool
def study_assistant(
    query: str
) -> str:

This wraps the Study Agent as a tool.

Workflow:

```text id="83lykw"
Tool Call
↓
Study Agent
↓
Response




---

### Expense Tool



```python id="4vr1ig"
@tool
def expense_assistant(
    query: str
) -> str:

This wraps the Expense Agent.

Workflow:

```text id="x4wozg"
Tool Call
↓
Expense Agent
↓
Response




Now the orchestrator can invoke either specialist.

---

## ⚙️ Step 6: Create the Orchestrator Prompt



```python id="ys8teq"
orchestrator_prompt = """
You are a router assistant.
"""

This prompt defines routing rules.

Study Topics

```text id="e80bvo"
study
learning
courses
practice
certifications
exams




### Expense Topics



```text id="rul44e"
budget
money
savings
spending
expenses
cost

The orchestrator's job is not to answer.

Its job is to route.

Think of it as a smart receptionist.

⚙️ Step 7: Build the Orchestrator Agent

```python id="v38nbe"
orchestrator_agent = Agent(
system_prompt=orchestrator_prompt,
model=bedrock_model,
tools=[
study_assistant,
expense_assistant,
],
)




This is the brain of the system.

It receives the user request and chooses the correct specialist.

Architecture:



```text id="bx9qwf"
User
 ↓
Orchestrator
 ↓
Correct Tool
 ↓
Specialized Agent

▶️ Run the Application

Execute:

```bash id="rxy1ii"
python agent.py




Or:



```bash id="k5d2nh"
uv run labs/08-multi-agent-orchestrator/agent.py

📊 Example Interaction #1

User

```text id="s9zn1s"
Help me prepare for AWS Cloud Practitioner.




### Routing



```text id="m6v00u"
Orchestrator
     ↓
study_assistant
     ↓
Study Agent

Response

```text id="yykx7m"
Here's a 4-week AWS Cloud Practitioner study plan...




---

## 📊 Example Interaction #2

### User



```text id="hk0e5q"
How can I save ₹5000 every month?

Routing

```text id="m7hd8x"
Orchestrator
↓
expense_assistant
↓
Expense Agent




### Response



```text id="v9xl7r"
Let's review your monthly expenses and identify savings opportunities...

📊 Example Interaction #3

User

```text id="3swmpx"
I have an exam next month and need a budget for training materials.




This query touches multiple domains.

The orchestrator may:

* Ask a clarification question
* Choose the dominant topic
* Route accordingly

This demonstrates why orchestration logic matters.

---

## 🔍 What Happened Behind the Scenes?

When a user submits a request:



```text id="vd6l7r"
User Query
     ↓
Orchestrator Agent
     ↓
Tool Selection
     ↓
Specialized Agent
     ↓
Response

The orchestrator never becomes an expert.

Instead, it delegates expertise.

This pattern is called:

```text id="vvw7mt"
Agent Orchestration




and is widely used in production AI systems.

---

## 💡 Why Developers Love This Pattern

Without Multi-Agent Systems:

❌ Huge prompts

❌ Mixed responsibilities

❌ Difficult maintenance

❌ Poor scalability

With Multi-Agent Systems:

✅ Specialized expertise

✅ Easier debugging

✅ Modular design

✅ Independent evolution

✅ Better scalability

Each agent focuses on one job and does it well.

---

## 🌍 Real-World Use Cases

This same architecture powers:

### Customer Support



```text id="n1e0y4"
Billing Agent
Technical Agent
Escalation Agent

Healthcare

```text id="slkj6g"
Symptoms Agent
Insurance Agent
Appointment Agent




### Enterprise Operations



```text id="px0i6z"
HR Agent
Finance Agent
IT Agent
Legal Agent

Personal Assistants

```text id="4m98t8"
Study Agent
Budget Agent
Fitness Agent
Travel Agent




The possibilities are endless.

---

## 🎯 Key Takeaways

* Multi-agent systems separate responsibilities
* Specialized agents improve accuracy
* Orchestrators route requests intelligently
* Tools can act as wrappers around agents
* Logging makes orchestration easier to debug
* This pattern scales extremely well in production

---

## 📚 Source Code

GitHub Repository:

https://github.com/d3vjamal/strands-agents-labs

---

## 🔗 Continue Learning

⬅️ Previous Lab

[Lab 06: Build Your First MCP Server with Streamable HTTP | Strands Agentic AI](https://dev.to/d3vjamal/-lab-06-build-your-first-mcp-server-with-streamable-http-strands-agentic-ai-1995)


---

## 🚀 Next Lab

In the next tutorial, we'll move beyond simple routing and explore how multiple agents can collaborate together, passing information between each other to solve complex tasks that no single agent can handle alone.

# 🧮 Lab 06: Build Your First MCP Server with Streamable HTTP | Strands Agentic AI

Jamal — Sun, 31 May 2026 04:48:00 +0000

In the previous labs, we connected a Strands Agent to an existing MCP server and used its tools.

But what if you want to create your own MCP server?

That's exactly what we'll do in this lab.

We'll build a Calculator MCP Server that exposes arithmetic operations such as addition, subtraction, multiplication, and division. Then we'll connect a Strands Agent to that server using Streamable HTTP transport.

By the end of this tutorial, you'll understand both sides of the MCP ecosystem:

MCP Server
MCP Client
Strands Agent

📚 Strands Agentic AI Lab Series

⬅️ Previous: Lab 06: Connecting to MCP with STDIO

📍 Current: Lab 07: Build Your First MCP Server

➡️ Next: Lab 08: Advanced MCP Tools & Multi-Tool Workflows

🚀 What You'll Learn

In this lab, you'll learn:

How to create an MCP Server
How MCP tools are exposed
How Streamable HTTP transport works
How to connect a Strands Agent to a custom MCP server
How agents invoke MCP tools automatically

🤖 Why Build Your Own MCP Server?

Previously we consumed an existing MCP server.

Agent
  ↓
AWS Documentation MCP Server

Now we'll build one ourselves.

Agent
  ↓
Your MCP Server
  ↓
Your Tools

This allows you to expose:

Internal APIs
Databases
Business Logic
Enterprise Systems
Custom Applications

through a standard MCP interface.

🏗️ Architecture

Our solution looks like this:

User
  ↓
Strands Agent
  ↓
MCP Client
  ↓
Calculator MCP Server
  ↓
Calculator Tools

The agent doesn't perform calculations directly.

Instead, it delegates them to MCP tools.

🛠️ Prerequisites

Before starting, ensure you have:

Python 3.10+
Strands SDK
MCP SDK
AWS Bedrock access
uv installed

Install dependencies:

pip install strands-agents
pip install mcp

📜 The Complete Script

This example creates:

An MCP Calculator Server
Four calculator tools
A Strands Agent
An interactive chat loop

The agent automatically uses MCP tools whenever calculations are required.

⚙️ Step 1: Create the MCP Server

mcp = FastMCP("Calculator Server")

This initializes a new MCP server.

Think of it as:

Web Framework
    ↓
Routes

but for AI tools.

MCP Server
    ↓
Tools

⚙️ Step 2: Create MCP Tools

Addition Tool

@mcp.tool(description="Add two numbers together")
def add(x: int, y: int) -> int:
    return x + y

Subtraction Tool

@mcp.tool(description="Subtract one number from another")
def subtract(x: int, y: int) -> int:
    return x - y

Multiplication Tool

@mcp.tool(description="Multiply two numbers together")
def multiply(x: int, y: int) -> int:
    return x * y

Division Tool

@mcp.tool(description="Divide one number by another")
def divide(x: float, y: float) -> float:
    if y == 0:
        raise ValueError("Cannot divide by zero")

    return x / y

Every tool becomes automatically discoverable through MCP.

No additional registration is required.

⚙️ Step 3: Start the MCP Server

mcp.run(
    transport="streamable-http"
)

This launches the MCP server using Streamable HTTP transport.

Server endpoint:

http://localhost:8000

Now other MCP clients can connect.

⚙️ Step 4: Run the Server in a Background Thread

server_thread = threading.Thread(
    target=start_calculator_server,
    daemon=True
)

Why?

Because we need:

Calculator Server
      +
Strands Agent

running simultaneously.

The background thread keeps the server alive while the agent runs.

⚙️ Step 5: Connect the MCP Client

def create_streamable_http_transport():
    return streamablehttp_client(
        "http://localhost:8000/mcp/"
    )

This creates an MCP Client connection.

Architecture:

Agent
   ↓
MCP Client
   ↓
HTTP Transport
   ↓
Calculator Server

⚙️ Step 6: Discover Available Tools

tools = streamable_http_mcp_client.list_tools_sync()

This is one of MCP's biggest advantages.

Instead of manually registering tools:

tools=[add, subtract]

the client automatically discovers them.

Example:

Available MCP tools:

add
subtract
multiply
divide

⚙️ Step 7: Create the Agent

agent = Agent(
    model=bedrock_model,
    system_prompt=system_prompt,
    tools=tools
)

Notice:

tools=tools

Those tools came directly from the MCP Server.

No custom integration required.

⚙️ Step 8: Interactive Calculator Assistant

while True:
    user_input = input("Question: ")

    response = agent(user_input)

    print(response)

This creates a conversational calculator.

Example:

Question:
What is 125 * 42?

Agent:

Behind the scenes:

Agent
 ↓
multiply()
 ↓
5250

▶️ Run the Application

Execute:

python agent.py

Or:

uv run labs/07-mcp-calculator-server/agent.py

📊 Example Interaction

User

What is 25 + 17?

Agent Workflow

Question
   ↓
Agent Reasoning
   ↓
add Tool
   ↓
42
   ↓
Response

Response

25 + 17 = 42

🔍 What Happened Behind the Scenes?

When you asked:

What is 25 + 17?

the agent:

Understood the request.
Found an MCP tool capable of addition.
Invoked the tool.
Received the result.
Generated a response.

The actual calculation happened in the MCP Server.

Not in the LLM.

💡 Why This Matters

This simple calculator demonstrates a powerful concept.

Today:

add()
subtract()
multiply()
divide()

Tomorrow:

Create Customer
Generate Invoice
Query Database
Deploy Lambda
Update CRM

The exact same MCP architecture scales to enterprise applications.

🎯 Key Takeaways

MCP Servers expose tools to AI agents
FastMCP makes building servers simple
Streamable HTTP enables remote communication
Agents automatically discover tools
MCP separates tool implementation from agent logic
This pattern scales from calculators to enterprise systems

📚 Source Code

Lab Source Code:
Your GitHub Repository

🔗 Continue Learning

⬅️ Previous Lab

Lab 05: Connecting to an MCP Server with STDIO Transport | Strands Agentic AI

➡️ Next Lab

Lab 07: Building Multi-Agent Systems with an Orchestrator | Strands Agentic AI

🚀 Next Lab

In the next tutorial, we'll build more sophisticated MCP tools, explore tool schemas, and learn how agents can choose between multiple MCP capabilities to solve complex tasks.

# 🚀 Lab 05: Connecting to an MCP Server with STDIO Transport | Strands Agentic AI

Jamal — Sun, 31 May 2026 04:14:05 +0000

In the previous lab, we learned what Model Context Protocol (MCP) is and why it is becoming the standard way for AI agents to access tools and external systems.

Now it's time to build a real MCP-powered agent.

In this lab, you'll connect a Strands Agent to the AWS Documentation MCP Server using STDIO transport and allow the agent to retrieve information directly from AWS documentation.

By the end of this tutorial, you'll have an AWS Documentation Assistant capable of answering AWS questions using MCP-provided tools.

📚 Strands Agentic AI Lab Series

⬅️ Previous: Lab 05: Introduction to MCP

📍 Current: Lab 06: Connecting to an MCP Server with STDIO Transport

➡️ Next: Lab 07: Exploring MCP Tools and Capabilities

🚀 What You'll Learn

In this lab, you'll learn:

What STDIO transport is
How MCP clients communicate with MCP servers
How to connect to an AWS Documentation MCP Server
How to discover available tools dynamically
How to build an AI assistant powered by MCP tools

🤖 Why STDIO Transport?

MCP supports multiple communication methods.

The simplest is STDIO.

Agent
  ↓
STDIO
  ↓
MCP Server

Instead of communicating over a network, the agent and MCP server communicate through standard input and output streams.

Benefits:

Simple setup
Fast local development
No network configuration
Great for experimentation

Think of STDIO as two applications having a direct private conversation.

🛠️ Prerequisites

Before starting, make sure you have:

Python 3.10+
AWS credentials configured
Amazon Bedrock access
uv installed
Strands SDK installed
MCP SDK installed

Install dependencies:

pip install strands-agents
pip install mcp

📜 The Script

Let's start with the complete example.

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

from strands.tools.mcp import MCPClient
from mcp import stdio_client, StdioServerParameters

# Bedrock
bedrock_model = BedrockModel(
    model_id="<YOUR_MODEL_ID>",
    region_name="eu-west-2",
    temperature=0.3,
)

# Connect to an MCP server using stdio transport
stdio_mcp_client = MCPClient(lambda: stdio_client(
    StdioServerParameters(
        command="uvx",
        args=["awslabs.aws-documentation-mcp-server@latest"]
    )
))

with stdio_mcp_client:
    tools = stdio_mcp_client.list_tools_sync()

    agent = Agent(
        system_prompt="""
        You are an AWS Documentation expert.
        Use the tools that are available to provide factual information.
        """,
        model=bedrock_model,
        tools=tools
    )

    agent("What is AWS Lambda?")

Now let's break it down.

⚙️ Step 1: Import MCP Components

from strands.tools.mcp import MCPClient
from mcp import stdio_client, StdioServerParameters

These imports provide the building blocks for MCP communication.

MCPClient

Creates a bridge between Strands and the MCP server.

stdio_client

Handles communication over standard input and output.

StdioServerParameters

Defines how the MCP server should start.

⚙️ Step 2: Configure the Bedrock Model

bedrock_model = BedrockModel(
    model_id="<YOUR_MODEL_ID>",
    region_name="eu-west-2",
    temperature=0.3,
)

This model performs:

Reasoning
Tool selection
Response generation

The MCP server provides tools.

The LLM decides how to use them.

⚙️ Step 3: Configure the MCP Server

stdio_mcp_client = MCPClient(
    lambda: stdio_client(
        StdioServerParameters(
            command="uvx",
            args=[
                "awslabs.aws-documentation-mcp-server@latest"
            ]
        )
    )
)

This launches the AWS Documentation MCP Server.

Architecture:

Strands Agent
       ↓
MCP Client
       ↓
AWS Documentation MCP Server
       ↓
AWS Documentation Tools

The MCP server automatically exposes tools to the agent.

⚙️ Step 4: Platform Differences

macOS/Linux

command="uvx"
args=[
    "awslabs.aws-documentation-mcp-server@latest"
]

Windows

command="uvx"
args=[
    "--from",
    "awslabs.aws-documentation-mcp-server@latest",
    "awslabs.aws-documentation-mcp-server.exe"
]

The server package is the same.

Only the launch syntax changes.

⚙️ Step 5: Start the MCP Session

with stdio_mcp_client:

This starts the MCP server session.

Once inside the context:

Server launches
Connection is established
Tools become available

When execution completes, resources are cleaned up automatically.

⚙️ Step 6: Discover Available Tools

tools = stdio_mcp_client.list_tools_sync()

This is where MCP becomes powerful.

Instead of manually creating tools:

@tool
def search_docs():
    ...

You can simply discover tools provided by the server.

Connect
    ↓
Discover
    ↓
Use

No custom tool implementation required.

⚙️ Step 7: Create the Agent

agent = Agent(
    system_prompt="""
    You are an AWS Documentation expert.
    Use the tools that are available to provide factual information.
    """,
    model=bedrock_model,
    tools=tools
)

Notice:

tools=tools

These tools come directly from the MCP server.

The agent now has access to AWS documentation capabilities without any additional coding.

⚙️ Step 8: Ask a Question

agent("What is AWS Lambda?")

Workflow:

User Question
       ↓
Agent Analysis
       ↓
MCP Tool Selection
       ↓
AWS Documentation Search
       ↓
Information Retrieved
       ↓
Final Response

The agent uses official AWS documentation instead of relying only on model memory.

▶️ Run the Agent

Execute:

python agent.py

Or:

uv run labs/06-mcp-stdio-client/agent.py

📊 Example Interaction

User

What is AWS Lambda?

Agent Workflow

Question Received
       ↓
Discover Documentation Tool
       ↓
Query AWS Documentation
       ↓
Retrieve Results
       ↓
Generate Answer

Response

AWS Lambda is a serverless compute service that allows you to run code without provisioning or managing servers.

Lambda automatically scales your application and charges only for the compute time used.

🔍 What Happened Behind the Scenes?

When the question was asked:

The LLM analyzed the request.
It discovered documentation tools.
It selected the most relevant tool.
The MCP server retrieved AWS documentation.
Results were returned to the model.
The model generated the final answer.

The agent never needed a custom Python function.

The MCP server supplied everything.

💡 Why Developers Love MCP

Without MCP:

❌ Build custom integrations

❌ Maintain tools manually

❌ Write wrappers for every service

With MCP:

✅ Connect once

✅ Discover tools automatically

✅ Reuse existing integrations

✅ Build agents faster

MCP turns integrations into plug-and-play components.

🎯 Key Takeaways

STDIO is the simplest MCP transport
MCP servers expose tools dynamically
Agents can discover tools automatically
AWS Documentation MCP Server provides factual AWS information
MCP dramatically reduces integration effort
Strands Agents integrate seamlessly with MCP

📚 Source Code

GitHub Repository:

https://github.com/d3vjamal/strands-agents-labs

🔗 Continue Learning

⬅️ Previous Lab

Lab 05: Introduction to MCP

➡️ Next Lab

Lab 07: Exploring MCP Tools and Capabilities

🚀 Next Lab

In the next tutorial, we'll inspect the tools exposed by an MCP server, understand their schemas, and learn how agents choose the right tool for a given task.

# 🔌 Lab 05: Using MCP (Model Context Protocol) with Strands Agents | Strands Agentic AI

Jamal — Sun, 31 May 2026 04:05:33 +0000

So far in this series, we've built custom tools and taught agents how to interact with the outside world.

But what if someone else has already built the tools you need?

Instead of writing every integration yourself, you can connect your AI agent to an MCP Server.

Model Context Protocol (MCP) is an open standard that allows AI agents to discover and use tools provided by external systems.

In this lab, you'll connect a Strands Agent to the AWS Documentation MCP Server and allow the agent to retrieve factual AWS documentation directly from official sources.

By the end of this lab, you'll have an AWS Documentation Assistant powered by MCP.

🚀 What You'll Learn

In this lab, you'll learn:

What MCP (Model Context Protocol) is
Why MCP is becoming important in Agentic AI
How to connect to an MCP server
How to use STDIO transport
How agents automatically discover MCP tools
How to build an AWS Documentation Assistant

🤖 What is MCP?

Model Context Protocol (MCP) is an open protocol that allows AI models and agents to connect to external tools and data sources.

Think of MCP as:

USB for AI Agents

Just as USB allows computers to connect to keyboards, printers, and storage devices, MCP allows AI agents to connect to:

Documentation systems
Databases
APIs
Search engines
Internal tools
Enterprise applications

Without MCP:

Agent
  ↓
Custom Tool
  ↓
External System

With MCP:

Agent
  ↓
MCP Server
  ↓
Many Tools

One connection can expose dozens of tools instantly.

🛠️ Prerequisites

Before starting, make sure you have:

Python 3.10+
AWS Account
Amazon Bedrock access
AWS credentials configured
uv installed
MCP SDK installed
Strands SDK installed

Install dependencies:

pip install strands-agents
pip install mcp

🌟 Why MCP Matters

Imagine you're building an AWS assistant.

Without MCP:

Build Tool #1
Build Tool #2
Build Tool #3
Build Tool #4
...

You must create and maintain every integration yourself.

With MCP:

Connect MCP Server
Discover Tools
Start Using Them

The MCP server handles the heavy lifting.

Your agent simply consumes the available tools.

This dramatically reduces development effort.

📜 The Script

Let's start by looking at the complete example.

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

from strands.tools.mcp import MCPClient
from mcp import stdio_client, StdioServerParameters

# Bedrock
bedrock_model = BedrockModel(
    model_id="<YOUR_MODEL_ID>",
    region_name="eu-west-2",
    temperature=0.3,
)

# Connect to an MCP server using stdio transport
stdio_mcp_client = MCPClient(
    lambda: stdio_client(
        StdioServerParameters(
            command="uvx",
            args=["awslabs.aws-documentation-mcp-server@latest"]
        )
    )
)

with stdio_mcp_client:
    tools = stdio_mcp_client.list_tools_sync()

    agent = Agent(
        system_prompt="""
        You are an AWS Documentation expert.
        Use the tools that are available to provide factual information.
        """,
        model=bedrock_model,
        tools=tools
    )

    agent("What is AWS Lambda?")

Now let's break it down.

⚙️ Step 1: Import MCP Components

from strands.tools.mcp import MCPClient
from mcp import stdio_client, StdioServerParameters

These imports provide everything required to communicate with an MCP server.

Components

Component	Purpose
MCPClient	Connects Strands to MCP
stdio_client	Uses standard input/output transport
StdioServerParameters	Configures the MCP server

⚙️ Step 2: Configure Amazon Bedrock

bedrock_model = BedrockModel(
    model_id="<YOUR_MODEL_ID>",
    region_name="eu-west-2",
    temperature=0.3,
)

This is the reasoning engine behind our agent.

The model decides:

Which tool to use
What information to retrieve
How to respond

⚙️ Step 3: Create the MCP Connection

stdio_mcp_client = MCPClient(
    lambda: stdio_client(
        StdioServerParameters(
            command="uvx",
            args=[
                "awslabs.aws-documentation-mcp-server@latest"
            ]
        )
    )
)

This establishes a connection to the AWS Documentation MCP Server.

Think of it as:

Agent
  ↓
MCP Client
  ↓
AWS Documentation MCP Server

The server exposes AWS documentation tools automatically.

⚙️ Step 4: Understanding STDIO Transport

This lab uses STDIO transport.

Agent Process
      ⇅
Standard Input/Output
      ⇅
MCP Server Process

STDIO is ideal for:

Local development
Local testing
Lightweight integrations

Because communication happens through process streams, no network setup is required.

⚙️ Step 5: Start the MCP Session

with stdio_mcp_client:

This opens a connection to the MCP server.

Once inside the context manager:

Server starts
Tools become available
Agent can access them

When execution finishes, the connection closes automatically.

⚙️ Step 6: Discover Available Tools

tools = stdio_mcp_client.list_tools_sync()

This is one of the most powerful MCP features.

Instead of manually creating tools:

tools = stdio_mcp_client.list_tools_sync()

The agent automatically discovers everything exposed by the MCP server.

Think of it like:

Connect
    ↓
Discover Tools
    ↓
Use Tools

No additional coding required.

⚙️ Step 7: Create the Agent

agent = Agent(
    system_prompt="""
    You are an AWS Documentation expert.
    Use the tools that are available to provide factual information.
    """,
    model=bedrock_model,
    tools=tools
)

Notice something interesting.

We aren't manually registering tools.

Instead:

tools=tools

contains every tool discovered from the MCP server.

The agent now has access to AWS documentation capabilities.

⚙️ Step 8: Ask a Question

agent("What is AWS Lambda?")

The workflow becomes:

User Question
       ↓
Agent Analysis
       ↓
MCP Tool Selection
       ↓
AWS Documentation Search
       ↓
Documentation Retrieved
       ↓
Final Response

The answer comes from official AWS documentation rather than relying solely on model memory.

▶️ Run the Agent

Execute the script:

python agent.py

Or:

uv run labs/05-mcp-introduction/agent.py

📊 Example Interaction

User

What is AWS Lambda?

Agent Workflow

Question Received
       ↓
Discover Documentation Tool
       ↓
Query AWS Documentation
       ↓
Retrieve Information
       ↓
Generate Response

Agent Response

AWS Lambda is a serverless compute service that lets you run code without provisioning or managing servers.

You pay only for the compute time consumed and can automatically scale applications in response to demand.

The exact response may vary depending on the documentation version and model.

🔍 What Makes MCP Different?

Traditional Tool Approach:

Build Tool
Register Tool
Maintain Tool
Update Tool

MCP Approach:

Connect Server
Discover Tools
Use Tools

The MCP server owns the implementation.

Your agent simply consumes capabilities.

This dramatically improves scalability.

💡 Real-World MCP Use Cases

MCP is useful for connecting agents to:

Documentation Systems

AWS Documentation
Azure Documentation
Internal Knowledge Bases

Databases

PostgreSQL
MySQL
MongoDB

Development Tools

GitHub
GitLab
Jira

Cloud Services

AWS
Azure
Google Cloud

Enterprise Systems

CRM
ERP
HR Systems

The possibilities are nearly endless.

🧠 Why Developers Love MCP

Without MCP:

❌ Build every integration yourself

❌ Maintain tool definitions

❌ Handle protocol changes

❌ Create custom wrappers

With MCP:

✅ Discover tools automatically

✅ Reuse existing integrations

✅ Standardized communication

✅ Faster development

✅ Easier maintenance

MCP shifts focus from integration work to solving business problems.

🎯 Key Takeaways

MCP stands for Model Context Protocol
MCP allows agents to connect to external tool providers
STDIO transport is perfect for local development
Agents can automatically discover available tools
MCP significantly reduces integration effort
The AWS Documentation MCP Server provides direct access to official AWS information

📚 Source Code

GitHub Repository:

https://github.com/d3vjamal/strands-agents-labs

🚀 Next Lab

In the next lab, we'll explore remote MCP servers and learn how agents can connect to tools running on different machines and services across the network.

🔗 Continue Learning

⬅️ Previous Lab

Lab 04B: Building a Web Search Tool for AI Agents

➡️ Next Lab

Lab 06: Remote MCP Servers

# 🌐 Lab 04B: Building a Web Search Tool for AI Agents | Strands Agentic AI

Jamal — Sun, 31 May 2026 03:52:57 +0000

Large Language Models are powerful, but they have one major limitation:

They only know what they were trained on.

What if you want your AI agent to access the latest information from the web?

That's where custom tools become incredibly useful.

In this lab, you'll build a custom web search tool using DuckDuckGo Search (DDGS) and connect it to a Strands Agent. This allows the agent to retrieve up-to-date information and provide responses based on real-time search results.

By the end of this lab, you'll have a Recipe Assistant that can search the web for recipes and cooking information.

🚀 What You'll Learn

In this lab, you'll learn:

How to create a custom web search tool
How to integrate third-party Python libraries into Strands tools
How agents use tools to access live information
How to handle API errors gracefully
How to build a specialized AI assistant

🤖 Why Web Search Matters

LLMs have knowledge cutoffs.

For example, an LLM may know:

✅ How recipes work

✅ Common cooking techniques

✅ Popular dishes

But it may not know:

❌ Latest recipes

❌ Current food trends

❌ Newly published cooking content

❌ Real-time information

A web search tool solves this problem.

User Question
      ↓
Agent Analysis
      ↓
Web Search Tool
      ↓
Search Results
      ↓
Agent Response

Instead of relying only on training data, the agent can retrieve fresh information from the web.

🛠️ Prerequisites

Before starting, make sure you have:

Python 3.10+
AWS Account
Amazon Bedrock access
AWS credentials configured
uv installed
DDGS package installed

Install DDGS:

pip install ddgs

📜 The Script

Let's start by looking at the complete example.

from strands import Agent, tool
from ddgs import DDGS
from ddgs.exceptions import RatelimitException
import logging
from strands.models.bedrock import BedrockModel

# Configure logging
logging.getLogger("strands").setLevel(logging.INFO)

# Define a websearch tool
@tool
def websearch(
    keywords: str,
    region: str = "us-en",
    max_results: int | None = None
) -> str:
    """Search the web to get updated information."""

    try:
        results = DDGS().text(
            keywords,
            region=region,
            max_results=max_results
        )

        return results if results else "No results found."

    except RatelimitException:
        return "RatelimitException: Please try again after a short delay."

    except Exception as e:
        return f"Exception: {e}"


# Bedrock
bedrock_model = BedrockModel(
    model_id="<YOUR_MODEL_ID>",
    region_name="eu-west-2",
    temperature=0.3,
)

# Create a recipe assistant agent
recipe_agent = Agent(
    model=bedrock_model,
    system_prompt="""
    You are RecipeBot, a helpful cooking assistant.
    Help users find recipes based on ingredients and answer cooking questions.
    Use the websearch tool to find recipes when users mention ingredients or to look up cooking information.
    """,
    tools=[websearch],
)

response = recipe_agent(
    "Suggest a recipe with chicken and capsicum."
)

print(f"Metrics : {response.metrics}")

Now let's break it down step by step.

⚙️ Step 1: Import Dependencies

from strands import Agent, tool
from ddgs import DDGS
from ddgs.exceptions import RatelimitException
import logging
from strands.models.bedrock import BedrockModel

We're importing:

Import	Purpose
Agent	Creates the AI agent
tool	Converts a Python function into a Strands tool
DDGS	Performs DuckDuckGo searches
RatelimitException	Handles search rate limits
logging	Displays runtime information
BedrockModel	Connects to Amazon Bedrock

⚙️ Step 2: Configure Logging

logging.getLogger("strands").setLevel(logging.INFO)

Logging helps us understand what the agent is doing during execution.

Example output:

INFO | strands.agent | Processing user request
INFO | strands.tools | Executing websearch tool

During development, logs provide valuable visibility into agent behavior.

⚙️ Step 3: Create the Web Search Tool

@tool
def websearch(
    keywords: str,
    region: str = "us-en",
    max_results: int | None = None
) -> str:

This function becomes a Strands tool through the @tool decorator.

The agent can now call this function whenever it needs information from the web.

Parameters

Parameter	Description
keywords	Search query
region	Search region
max_results	Maximum number of results

Example:

websearch(
    "chicken capsicum recipe"
)

⚙️ Step 4: Search Using DDGS

results = DDGS().text(
    keywords,
    region=region,
    max_results=max_results
)

DDGS performs a DuckDuckGo search and returns matching results.

These results are then sent back to the agent.

The agent uses them to generate an informed response.

⚙️ Step 5: Handle Errors Gracefully

Production-ready tools should always handle failures.

Rate Limit Handling

except RatelimitException:

If too many requests are made, DDGS may temporarily block searches.

Instead of crashing, the tool returns a helpful message.

General Error Handling

except Exception as e:

Unexpected failures are captured and returned safely.

This improves reliability and user experience.

🧠 Why the Docstring Matters

"""Search the web to get updated information."""

The docstring helps the LLM understand:

What the tool does
When it should use it
What kind of information it can retrieve

Think of the docstring as instructions for the AI.

A clear description leads to better tool selection.

⚙️ Step 6: Configure Amazon Bedrock

bedrock_model = BedrockModel(
    model_id="<YOUR_MODEL_ID>",
    region_name="eu-west-2",
    temperature=0.3,
)

This model powers the reasoning and decision-making process.

The agent determines:

Whether web search is needed
What search query to generate
How to interpret results
How to respond to users

⚙️ Step 7: Create a Specialized Recipe Agent

recipe_agent = Agent(
    model=bedrock_model,
    system_prompt="""
    You are RecipeBot...
    """,
    tools=[websearch],
)

This agent has a clear responsibility:

Find recipes
Answer cooking questions
Search the web when necessary

The system prompt defines the agent's personality and capabilities.

⚙️ Step 8: Ask the Agent a Question

response = recipe_agent(
    "Suggest a recipe with chicken and capsicum."
)

The agent receives the request and reasons about how to solve it.

Because recipe information may require fresh data, it can choose to invoke the web search tool.

▶️ Run the Agent

Execute the script:

python agent.py

Or:

uv run labs/04b-websearch-tool/agent.py

📊 Example Interaction

User

Suggest a recipe with chicken and capsicum.

Agent Workflow

User Request
      ↓
Agent Analysis
      ↓
Web Search Tool
      ↓
Recipe Search Results
      ↓
Response Generation

Agent Response

You can make a Chicken Capsicum Stir Fry.

Ingredients:
- Chicken breast
- Capsicum
- Onion
- Garlic
- Soy sauce

Instructions:
1. Sauté garlic and onion.
2. Add chicken and cook thoroughly.
3. Add sliced capsicum.
4. Stir in soy sauce.
5. Serve hot with rice.

Actual responses may vary depending on model and search results.

📈 Understanding Agent Metrics

At the end of the script:

print(f"Metrics : {response.metrics}")

Metrics help monitor agent performance.

You may see information such as:

Input Tokens
Output Tokens
Latency
Tool Calls

These metrics become extremely useful when optimizing production agents.

🔍 How Tool Calling Works

When a user asks a question:

User Prompt
      ↓
Agent Reasoning
      ↓
Tool Selection
      ↓
Web Search
      ↓
Results Returned
      ↓
Final Response

The agent automatically decides whether the tool should be used.

You don't need to manually call the function.

This is what makes agentic systems powerful.

💡 Real-World Use Cases

The same approach can be used for:

News Assistant

Search latest headlines

Research Assistant

Search technical documentation

Travel Assistant

Search destinations and hotels

Shopping Assistant

Search products and reviews

Support Assistant

Search knowledge bases

A web search tool unlocks countless possibilities.

🎯 Key Takeaways

Custom tools allow agents to access live information
DDGS provides a simple web search capability
Error handling improves reliability
Docstrings help the LLM understand tool functionality
Agents automatically decide when to invoke tools
Tool-based architectures make AI assistants far more useful

📚 Source Code

GitHub Repository:

https://github.com/d3vjamal/strands-agents-labs

🚀 Previous Lab

Lab 04A: Creating Your First Custom Tool | Strands Agentic AI

# 🛠️ Lab 04A: Creating Your First Custom Tool | Strands Agentic AI

Jamal — Sun, 31 May 2026 03:48:47 +0000

AI agents become truly powerful when they can perform actions beyond generating text.

While large language models are great at reasoning, tools allow them to interact with the real world, process data, and execute custom logic.

In this lab, you'll learn how to create your first custom tool using the @tool decorator in Strands and expose it to an AI agent.

By the end, your agent will be able to count words using your own Python function.

🚀 What You'll Learn

In this lab, you'll learn:

What tools are in Strands Agents
How the @tool decorator works
How to create your own custom tool
How agents automatically discover and use tools
How tool docstrings help the LLM understand capabilities

🤖 Why Custom Tools Matter

Without tools, an AI agent can only generate responses based on its training and reasoning.

With tools, agents can:

Query databases
Call APIs
Read files
Write files
Perform calculations
Execute business logic

Think of a language model as a brain.

Tools are its hands.

The brain can think about counting words, but a tool can perform the counting accurately and consistently.

🛠️ Prerequisites

Before starting, make sure you have:

Python 3.10+
AWS Account
Amazon Bedrock access
Access to a model such as amazon.nova-2-lite-v1
AWS credentials configured
uv installed
Completed Lab 01 and Lab 02

📜 The Script

Let's start by looking at the complete example.

# Just an example of using creating your custom tool

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

# Bedrock
bedrock_model = BedrockModel(
    # Set your preferred model ID here
    model_id="<YOUR_MODEL_ID>",
    region_name="eu-west-2",
    temperature=0.3,
)


@tool
def word_count(text: str) -> int:
    """Count words in text.

    This docstring is used by the LLM to understand the tool's purpose.
    """
    return len(text.split())


agent = Agent(model=bedrock_model, tools=[word_count])

response = agent("How many words are in this sentence?")

Now let's break it down step by step.

⚙️ Step 1: Import Required Modules

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

We're importing:

Import	Purpose
Agent	Creates the AI agent
tool	Converts a Python function into a Strands tool
BedrockModel	Connects the agent to Amazon Bedrock

The tool decorator is the star of this lab.

It allows Strands to expose a Python function to the language model.

⚙️ Step 2: Configure Amazon Bedrock

bedrock_model = BedrockModel(
    model_id="<YOUR_MODEL_ID>",
    region_name="eu-west-2",
    temperature=0.3,
)

This creates the model that powers the agent.

Parameters

Parameter	Description
model_id	Bedrock model identifier
region_name	AWS region
temperature	Controls creativity and randomness

For utility tools, lower temperatures often produce more predictable results.

⚙️ Step 3: Create a Custom Tool

@tool
def word_count(text: str) -> int:
    """Count words in text."""
    return len(text.split())

This is where the magic happens.

The @tool decorator transforms a normal Python function into a tool that the agent can invoke.

Function Breakdown

def word_count(text: str) -> int:

Input:

text: str

Output:

int

The function simply splits text into words and returns the total count.

Example:

word_count("hello world")

Returns:

🧠 Why the Docstring Matters

One of the most important parts of a custom tool is the docstring.

"""Count words in text."""

The LLM reads this description to understand:

What the tool does
When it should use it
What inputs it expects

Think of the docstring as instructions for the AI.

A clear docstring helps the model choose the correct tool at the correct time.

⚙️ Step 4: Register the Tool

agent = Agent(
    model=bedrock_model,
    tools=[word_count]
)

Here we provide the tool to the agent.

tools=[word_count]

The agent now knows:

The tool exists
What it does
How to call it

From this point forward, the model can decide when to use it.

⚙️ Step 5: Ask the Agent a Question

response = agent(
    "How many words are in this sentence?"
)

When the agent receives this request, it reasons about the task.

The model recognizes that counting words is exactly what the word_count tool is designed to do.

Instead of guessing, it invokes the tool and uses the result.

▶️ Run the Agent

Execute the script:

uv run labs/04a-custom-tool/agent.py

Or:

python agent.py

📊 Example Interaction

User

How many words are in this sentence?

Agent Reasoning

This task requires counting words.
A tool named word_count is available.
I'll use the tool.

Tool Execution

word_count(
    "How many words are in this sentence?"
)

Result:

Agent Response

There are 7 words in the sentence.

🔍 How Tool Calling Works

When a user sends a request:

User Prompt
     ↓
Agent Analysis
     ↓
Tool Selection
     ↓
Tool Execution
     ↓
Result Returned
     ↓
Final Response

The agent automatically decides whether a tool should be used.

You don't explicitly call the function yourself.

The LLM handles that decision-making process.

💡 Real-World Tool Examples

The same pattern can be used to build more powerful tools:

Calculator Tool

@tool
def add(a: int, b: int) -> int:
    return a + b

Date Tool

@tool
def current_date() -> str:
    ...

Database Tool

@tool
def get_customer(customer_id: str):
    ...

AWS Tool

@tool
def list_s3_buckets():
    ...

This is the foundation of building production-ready AI agents.

🎯 Key Takeaways

Tools extend the capabilities of AI agents
The @tool decorator converts Python functions into agent tools
Docstrings help the LLM understand tool functionality
Agents automatically decide when to use tools
Custom tools are the foundation of real-world agent workflows

📚 Source Code

Lab Source:

https://github.com/d3vjamal/strands-agents-labs/tree/master/labs/04a-custom-tool

🚀 Next Lab

In the next lab, we'll create more advanced tools with parameters and learn how agents can chain multiple tool calls together to solve complex tasks.

# 🔍 Lab 03: Logging and Debugging | Strands Agentic AI

Jamal — Fri, 29 May 2026 19:32:16 +0000

AI agents can perform complex tasks, call tools, and interact with external services. But what happens when something goes wrong?

Without logging, debugging an AI agent can feel like trying to solve a puzzle with half the pieces missing.

In this lab, you'll learn how to enable logging in Strands Agents so you can observe what's happening behind the scenes, understand agent behavior, and troubleshoot issues more effectively.

🚀 What You'll Learn

By the end of this lab, you'll understand:

How logging works in Strands Agents
How to enable DEBUG logs
How to inspect agent execution flow
How to monitor tool invocations
How logging helps troubleshoot agent issues

🤖 Why Logging Matters in Agentic AI

Traditional applications usually follow a predictable flow.

AI agents are different.

A single prompt can trigger multiple reasoning steps, tool calls, and external API requests.

User Prompt
     ↓
Agent Reasoning
     ↓
Tool Selection
     ↓
HTTP Request
     ↓
Response Processing
     ↓
Final Answer

If something fails during this process, logs help us understand:

Which tool was selected
What requests were sent
What responses were received
Where failures occurred
How the agent reached its final answer

Think of logging as the flight recorder for your AI agent.

🛠️ Prerequisites

Before starting, make sure you have:

Python 3.10+
AWS Account
Amazon Bedrock access
Access to a model such as amazon.nova-2-lite-v1
AWS credentials configured
uv installed

📜 The Script

Let's start by looking at the complete example.

# This lab is to teach you about logging

from strands import Agent
from strands.models.bedrock import BedrockModel
from strands_tools import file_read, file_write, http_request
import logging

# Configure the root strands logger
logging.getLogger("strands").setLevel(logging.DEBUG)

# Add a handler to display logs in the terminal
logging.basicConfig(
    format="%(levelname)s | %(name)s | %(message)s",
    handlers=[logging.StreamHandler()]
)

# Configure the Bedrock model
bedrock_model = BedrockModel(
    model_id="<YOUR_MODEL_ID>",
    region_name="eu-west-2",
    temperature=0.3,
)

system_prompt = """
Weather Information
    - You can also make HTTP requests to the National Weather Service API.
    - Process and display weather forecast data for locations in the United States.
"""

# Create the agent with tools
local_agent = Agent(
    system_prompt=system_prompt,
    model=bedrock_model,
    tools=[http_request],
)

# Ask the agent a question
local_agent("what is the weather in new york?")

Now let's break it down.

⚙️ Step 1: Configure Logging

import logging

logging.getLogger("strands").setLevel(logging.DEBUG)

logging.basicConfig(
    format="%(levelname)s | %(name)s | %(message)s",
    handlers=[logging.StreamHandler()]
)

What is happening here?

First, we configure Python's built-in logging module.

logging.getLogger("strands").setLevel(logging.DEBUG)

This tells Strands to emit detailed debugging information.

The DEBUG level provides maximum visibility into agent execution.

We then configure how logs appear in the terminal:

logging.basicConfig(
    format="%(levelname)s | %(name)s | %(message)s"
)

Example:

DEBUG | strands.agent | Processing user request
INFO | strands.tools | Executing HTTP request

This makes logs easy to read and troubleshoot.

⚙️ Step 2: Configure the Bedrock Model

bedrock_model = BedrockModel(
    model_id="<YOUR_MODEL_ID>",
    region_name="eu-west-2",
    temperature=0.3,
)

Here we create the LLM that powers our agent.

Parameters

Parameter	Description
model_id	Bedrock model identifier
region_name	AWS Region
temperature	Controls response randomness

A lower temperature produces more consistent and predictable responses.

⚙️ Step 3: Define the Agent's Role

system_prompt = """
Weather Information
    - You can also make HTTP requests to the National Weather Service API.
    - Process and display weather forecast data for locations in the United States.
"""

The system prompt acts as the agent's instructions.

It tells the model:

What task it should perform
Which information sources are available
How it should behave

In this case, the agent is focused on retrieving weather information.

⚙️ Step 4: Add the HTTP Tool

tools=[http_request]

The http_request tool gives the agent the ability to access external APIs.

Without tools, the agent can only rely on its training data.

With tools, it can fetch live information from the internet.

For weather data, the agent can query APIs and process real-time forecasts.

⚙️ Step 5: Create the Agent

local_agent = Agent(
    system_prompt=system_prompt,
    model=bedrock_model,
    tools=[http_request],
)

This combines:

The model
The instructions
The available tools

into a working AI agent.

▶️ Run the Agent

Invoke the agent using:

local_agent("what is the weather in new york?")

The agent will:

Analyze the request
Decide whether a tool is needed
Call the HTTP tool
Retrieve weather information
Generate a final response

📊 Example Debug Output

When running the script, you'll see logs similar to:

DEBUG | strands.agent | Processing user request
DEBUG | strands.agent | Selecting tool
INFO  | strands.tools | Executing HTTP request
INFO  | strands.tools | Response received
DEBUG | strands.agent | Generating final answer

The exact output may vary depending on the model and SDK version.

🔍 Understanding the Log Levels

DEBUG

Most detailed level.

Useful during development.

DEBUG | Agent selecting tool

INFO

General execution information.

INFO | HTTP request executed

WARNING

Something unexpected happened, but execution continues.

WARNING | Missing optional parameter

ERROR

Execution failed.

ERROR | Failed to call external API

💡 Why Developers Love Logs

Imagine your agent gives an incorrect answer.

Without logs:

❌ No idea what happened.

With logs:

✅ See which tool was selected

✅ Inspect API requests

✅ Inspect responses

✅ Find failures quickly

✅ Improve prompts and tools

Logs dramatically reduce debugging time.

🎯 Key Takeaways

Logging provides visibility into agent execution
DEBUG logs help trace reasoning and tool usage
Python's built-in logging module works seamlessly with Strands
Logs make troubleshooting faster and easier
Observability is essential for production-ready AI agents

📚 Source Code

GitHub Repository:

https://github.com/d3vjamal/strands-agents-labs

🚀 Next Lab

In the next lab, we'll explore custom tools and learn how to extend Strands Agents with capabilities tailored to your own applications.

Lab 02 — HTTP Tools Integration; Strands Agentic AI

Jamal — Fri, 29 May 2026 19:21:09 +0000

Building My First AI Agent with Strands Agents: Part 1 link

🎯 Objective

Give your agent the ability to fetch live data from the internet using the http_request tool. In this lab the agent calls the US National Weather Service API to answer a weather question.

📖 Background

Most useful agents need to reach out to external services. The http_request tool lets an agent make GET/POST/PUT/DELETE requests to any URL. The agent decides which URL to call, parses the response, and presents it in natural language.

🔑 Key Concepts

Concept	Description
`http_request`	Built-in Strands tool for making HTTP calls
System Prompt	Guides the agent on which APIs to use and how to interpret responses
API chaining	The agent may make multiple HTTP calls (e.g. get coordinates → get forecast)

⚙️ Prerequisites

AWS credentials configured
Internet connectivity (the agent calls api.weather.gov)
Dependencies installed (uv sync)

Lab 02 : Agentic ai with http_request tool

# This lab is to teach you about http_request tool

from strands import Agent
from strands.models.bedrock import BedrockModel
from strands_tools import file_read, file_write, http_request

# Configure the Bedrock model
bedrock_model = BedrockModel(
    # Set your preferred model ID here (e.g., "global.amazon.nova-2-lite-v1:0")
    model_id="<YOUR_MODEL_ID>",
    region_name="eu-west-2",
    temperature=0.3,
)


system_prompt = """
Weather Information
    - You can also make HTTP requests to the National Weather Service API.
    - Process and display weather forecast data for locations in the United States.
"""

# - When retrieving weather information, first get coordinates using https://api.weather.gov/points/{latitude},{longitude},  or
#         https://api.weather.gov/points/{zipcode}, then use the returned forecast URL. You can make additional http requests as well.

# Create the agent with tools
local_agent = Agent(
    system_prompt=system_prompt, # Define a system Prompt
    model=bedrock_model,
    tools=[http_request],  # Add your custom tools here
)


local_agent("what is the weather in new york?")

▶️ How to Run

uv run labs/02-http-tools/agent.py

🧪 Exercises

Try a different city — Change "new york" to another US city and see if the agent resolves the correct API endpoint.
Combine tools — Add file_write so the agent saves the weather report to a file.
Non-US weather — The NWS API only covers the US. Modify the system prompt to use a global weather API like OpenWeatherMap instead.
Error handling — Disconnect from the internet and observe how the agent reacts.

ALL LAB EXCERSIZE GitHub Notes

📚 Further Reading

Building My First AI Agent with Strands Agents

Jamal — Fri, 29 May 2026 19:06:35 +0000

An agent is a program that uses a large-language model (LLM) to decide which actions to take based on a user's request. Strands Agents wraps this loop into a simple Python API.

If you've been trying to build Agentic AI applications recently, you've probably noticed a major problem: boilerplate overload. Frameworks like LangChain or LangGraph are incredibly powerful, but sometimes you just want a clean, fast, lightweight, and model-agnostic way to build production-ready agents.

Enter Strands Agents—a lean, modern open-source SDK designed to let developers build robust AI agents without the architectural bloat.

In this 4-part series, we are going to explore how to take Strands from a blank screen to a production-grade multi-agent system. Let's get our hands dirty with Part 1!

🚀 Quick Start

1. 🛠️ Prerequisites

Before we write code, let's set up a clean playground.

Make sure you have:

Python 3.10+
AWS account with access credentials (AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY) and access granted to the amazon.nova-2-lite-v1 (or another Bedrock model) on Amazon Bedrock
uv package manager

2. 🤖 What Is Agentic AI?

Agentic AI refers to autonomous software systems powered by artificial intelligence that can perceive their environment, make decisions, and take actions independently to achieve specific goals.

3. 📦 Installation

Step 1: Clone the Repository

git clone https://github.com/d3vjamal/strands-agents-labs.git
cd strands-agents-labs

*Lab 1: Run your first agent
*

from strands import Agent
from strands_tools import file_read, file_write
from dotenv import load_dotenv
from strands.models.bedrock import BedrockModel
import os

load_dotenv()


bedrock_model = BedrockModel(
    # Set your preferred model ID here (e.g., "global.amazon.nova-2-lite-v1:0")
    model_id="<YOUR_MODEL_ID>",
    region_name="eu-west-2",
    temperature=0.3,
)

system_prompt = "You are a an agent which can read and write files to current directory"

# Create the agent with tools
local_agent = Agent(
    system_prompt=system_prompt, # Define a system Prompt
    model=bedrock_model,
    tools=[file_read, file_write],  # Add your custom tools here
)


local_agent("can you create a weather.md file, with the content about current temperature in kolkata India right now?, if not able find weather put reason of it")

Run your first lab :

uv run labs/01-your-first-agent/agent.py

📖 Background

In this lab the agent is asked to create a markdown file with weather information. Because the agent does not have internet access, it must reason about what it can do (write a file) and what it cannot do (fetch live data) — a great first lesson in tool-aware reasoning.

🔑 Key Concepts

Concept	Description
`Agent`	The core class that ties together a model, tools, and a system prompt
`system_prompt`	Instructions that shape the agent's personality and capabilities
`BedrockModel`	Model provider connecting to Amazon Bedrock
`file_read` / `file_write`	Built-in Strands tools for local file operations
`load_dotenv()`	Loads AWS credentials from a `.env` file

Part 2 : HTTP tool integration

Fix AWS amplify React app error on Access Denied error

Jamal — Fri, 18 Dec 2020 03:07:32 +0000

When I deployed my build react app on AWS amplify, the first landing page is able to load. However, when you defined a path in your router, and try to access it, you would hit Access Denied error:
like /signin first page loaded but unable to go /signup route or any other routes .

Here, what i did,

Go AWS amplify console, select “ Rewrites and redirects ”, add a new rewrite and redirects, click on “ Open text editor ”, and add the below rule:

[{
    "source": "</^[^.]+$|\\.(?!(css|gif|ico|jpg|js|png|txt|svg|woff|ttf)$)([^.]+$)/>",
    "target": "/index.html",
    "status": "200",
    "condition": null
}]

Looks like this:

Try again to access your url, it should work now.

Stackoverflow answer:
https://stackoverflow.com/questions/63546586/access-denied-error-from-protected-routes-from-react-app-hosted-on-aws-amplify

Docker Node Alpine Image Build Fails on node-gyp

Jamal — Wed, 23 Sep 2020 09:23:28 +0000

Docker node:7.9-alpine unable to build package due python is not installed :Resolved

I'm attempting to Dockerize a node.js application(Typescript). I'm using the node:12.18.4-alpine Docker image as a base.

I go this

gyp ERR! configure error

gyp ERR! stack Error: Can't find Python executable "python", you can set the PYTHON env variable.
gyp ERR! stack at PythonFinder.failNoPython (/usr/local/lib/node_modules/npm/node_modules/node-gyp/lib/configure.js:484:19)
gyp ERR! stack at PythonFinder. (/usr/local/lib/node_modules/npm/node_modules/node-gyp/lib/configure.js:406:16)
gyp ERR! stack at F (/usr/local/lib/node_modules/npm/node_modules/which/which.js:68:16)
gyp ERR! stack at E (/usr/local/lib/node_modules/npm/node_modules/which/which.js:80:29)
gyp ERR! stack at /usr/local/lib/node_modules/npm/node_modules/which/which.js:89:16
gyp ERR! stack at /usr/local/lib/node_modules/npm/node_modules/isexe/index.js:42:5
gyp ERR! stack at /usr/local/lib/node_modules/npm/node_modules/isexe/mode.js:8:5
gyp ERR! stack at FSReqCallback.oncomplete (fs.js:159:21)
gyp ERR! System Linux 3.10.0-957.el7.x86_64
gyp ERR! command "/usr/local/bin/node" "/usr/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "configure" "--fallback-to-build" "--module=/code/server/node_modules/bcrypt/lib/binding/bcrypt_lib.node" "--module_name=bcrypt_lib" "--module_path=/code/server/node_modules/bcrypt/lib/binding" "--napi_version=4" "--node_abi_napi=napi" "--napi_build_version=0" "--node_napi_label=node-v67"
gyp ERR! cwd /code/server/node_modules/bcrypt
gyp ERR! node -v v11.9.0
gyp ERR! node-gyp -v v3.8.0
gyp ERR! not ok
node-pre-gyp ERR! build error
node-pre-gyp ERR! stack Error: Failed to execute '/usr/local/bin/node /usr/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js configure --fallback-to-build --module=/code/server/node_modules/bcrypt/lib/binding/bcrypt_lib.node --module_name=bcrypt_lib --module_path=/code/server/node_modules/bcrypt/lib/binding --napi_version=4 --node_abi_napi=napi --napi_build_version=0 --node_napi_label=node-v67' (1)
node-pre-gyp ERR! stack at ChildProcess. (/code/server/node_modules/bcrypt/node_modules/node-pre-gyp/lib/util/compile.js:83:29)
node-pre-gyp ERR! stack at ChildProcess.emit (events.js:197:13)
node-pre-gyp ERR! stack at maybeClose (internal/child_process.js:978:16)
node-pre-gyp ERR! stack at Process.ChildProcess._handle.onexit (internal/child_process.js:265:5)
node-pre-gyp ERR! System Linux 3.10.0-957.el7.x86_64
node-pre-gyp ERR! command "/usr/local/bin/node" "/code/server/node_modules/bcrypt/node_modules/.bin/node-pre-gyp" "install" "--fallback-to-build"
node-pre-gyp ERR! cwd /code/server/node_modules/bcrypt
node-pre-gyp ERR! node -v v11.9.0
node-pre-gyp ERR! node-pre-gyp -v v0.12.0
node-pre-gyp ERR! not ok
Failed to execute '/usr/local/bin/node /usr/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js configure --fallback-to-build --module=/code/server/node_modules/bcrypt/lib/binding/bcrypt_lib.node --module_name=bcrypt_lib --module_path=/code/server/node_modules/bcrypt/lib/binding --napi_version=4 --node_abi_napi=napi --napi_build_version=0 --node_napi_label=node-v67' (1)
npm WARN backend-botmanagementservice@1.0.0 No description
npm WARN backend-botmanagementservice@1.0.0 No repository field.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.2.7 (node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.2.7: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
........

my docker file was

 #MY first stage, that is the Builder
FROM node:12.18.4 AS ts-sample-builder
WORKDIR /app
COPY . .
RUN npm install
RUN npm run clean
RUN npm run build
# My Second stage, that creates an image for production
FROM node:12.18.4 AS ts-sample-prod
WORKDIR /app
COPY --from=ts-sample-builder ./app/dist ./dist
COPY package* ./
RUN npm install --production
CMD npm run start-prod
EXPOSE 3001

To reduce image size I change node version node:12.18.4-alpine then it caches issues as I mentioned above.

When using alpine, you need to install build dependencies for some node modules to be able to be built natively. It should probably be documented
Note:
if just use the base as node:12 or any other version your image size will be more than 1GB some cases.

How to speed up Node re-builds by leveraging Docker multi-stage builds
if you are using alpine, you need to install build dependencies for some node module to be able to be built natively.

Example

FROM node:8.12-alpine
EXPOSE 8080
WORKDIR /app
COPY . .
#python
RUN apk add --no-cache --virtual .gyp \
        python \
        make \
        g++ \
    && npm install \
    && apk del .gyp
CMD ["npm", "start"]

Docker and Node.js Best Practices

I will suggest you for checking bcrypt $ bcryptjs npm docs.
node-gyp only works with stable/released versions of node. Since the bcrypt module uses node-gyp to build and install, you'll need a stable version of node to use bcrypt. If you do not, you'll likely see an error that starts with:

In the end, It resolves all issues like slow build &Python is not installed &, etc.

#My first stage, that is the Builder
FROM  node:12.18.4-buster AS build
#RUN apk add --update --no-cache \
#    python \
#    make \
#    g++
COPY . .
# If you have native dependencies, you'll need extra tools
RUN npm install
#RUN npm install
RUN npm run build
RUN npm prune --production
#CMD npm run start-prod
#EXPOSE 3001
## My Second stage, that creates an image for production
FROM node:12.18.4-alpine
WORKDIR /app
COPY --from=build ./dist ./dist
COPY --from=build ./node_modules ./node_modules
CMD npm run start-prod
EXPOSE 3001

It worked for me!

learn more about multi staging.

Using Multi-Stage Builds to Simplify And Standardize Build Processes

Add Me to Search: Google Launches Virtual Business Cards

Jamal — Wed, 12 Aug 2020 17:01:47 +0000

Google is testing virtual business cards in search results that show up when a person’s name is searched for.

Now rolling out in India, Google’s new ‘people cards’ let individuals highlight themselves in search results like never before.
For searchers, it can be challenging to find information about specific people if they don’t have a strong online presence.

Google India Tweet :

Google aims to address these challenges with people cards:

Today, we are solving these challenges with a new feature called people cards. It’s like a virtual visiting card, where you can highlight your existing website or social profiles you want people to visit, plus other information about yourself that you want others to know.

People cards are designed for business professionals, performers, influencers, entrepreneurs, job hunters, freelancers, or anyone looking to grow their presence online.

The prime purpose of people cards is to allow individuals to have a public profile on Google Search that will be displayed on top of all results. It was initially spotted as profile cards in February.

Google claims that with people cards, it is aiming to provide “helpful and reliable information” to the public. Thus, it gives the option to all users to flag abuse, impersonation, or even low-quality content, if they find anything odd through people cards. The search giant is also touting to have a combination of human review and automated techniques in place to flag policy violating content. Furthermore, only one people card is allowed per Google Account to limit fake profiles.

Individuals who have already created their cards on Google have the ability to opt-out of the experience anytime. In case of people who share the same name, Google Search will show multiple modules.

How secure is People Cards?

To make sure people find reliable and helpful information, the tech giant has put together several protections and controls. It has also added safeguard mechanisms to protect against offensive content.

There is a feedback button with the help of which users can identify and report low-quality information or a card that they believe was created by an impersonator.

For people looking to find someone on Search with their name, the card will be available. There will be a module with the name, profession and location which users can tap to see their card.

For people who share the same name, the Search will show multiple modules. The unique information will help users distinguish between different individuals to find accurate information.

How to create your own people card on Google

To create your own people card, sign into your Google Account and search for “add me to Search”. You'll now see a prompt saying, “Add yourself to Google Search.” Tap that prompt and then you'll be asked to provide your phone number that will be verified through a six-digit unique code to begin the process.

Google said that for every new card, the user must authenticate the account with a unique mobile number. He/she will have complete control of the information to be included on the card and can opt-out of the experience anytime, which will stop their details from appearing in Search.

Image credit:Google Image search

How to create your People Card on Google Search

Step 1: To create a People Card, users will first need to sign in to their Google Account, search for their name on Google Search

Step 2: Tap on the "add me to Search" option that appears on the page

Step 3: Upload an image of yourself from your Google account, add a description and links to social profiles or websites. You can even include your phone number or email address if you want it on your virtual visiting card

Step 4: Tap on the "save" option and that's it.