Getting Started with SageMaker AI Notebooks: Building Agents with Strands Agents

Building AI Agents on AWS doesn't require a complex deployment pipeline. With a SageMaker AI notebook instance and the open-source Strands Agents SDK, developers can quickly assemble a smart assistant capable of calling tools and executing tasks right inside a familiar JupyterLab environment. This article is based on a hands-on tutorial from the Dev.to community, walking through the entire process from environment preparation to running the Agent, with additional notes on cost and permission considerations worth paying attention to.

Why Use the SageMaker + Strands Agents Combination

Strands Agents is an open-source Python SDK whose core idea is to connect AI models with external tools. Rather than simply answering questions, it enables the model to "do things" — understand a user request, decide which tool to call, take the result, and organize it into a natural language response.

Think of it as a personal assistant: you ask "What's the weather in Bangalore?", the AI determines it needs to check the weather, calls a real weather API, and finally tells you the current temperature, humidity, and wind speed. The entire process involves autonomous decision-making by the model, with no hard-coded logic.

Choosing a SageMaker AI notebook as the development environment offers several practical advantages: no need to configure AWS credential chains locally, execution roles that naturally integrate with IAM permission management, and JupyterLab's interactive debugging that makes the tool-calling process intuitive to trace. The companion Amazon Bedrock provides model hosting capabilities; this example uses amazon.nova-lite-v1:0 as the foundation model.

The Technical Positioning of the Strands Agents SDK

Strands Agents is a lightweight Agent framework open-sourced by AWS in 2025, adopting a "model-driven" rather than "flow-orchestration" design philosophy. Traditional workflow-based frameworks require developers to predefine state machines or DAGs to determine tool-calling order, whereas Strands hands decision-making authority to the model itself: by describing available tools in the system prompt, the model outputs structured tool-calling intents during inference, and the SDK executes them and feeds the results back to the model, forming a multi-turn loop until the task is complete. Its core abstractions are just three — Agent (the orchestration container), @tool (functions as tools), and Model Provider (the model backend, in this case BedrockModel). This minimalist design lowers the barrier to entry, but it also means the Agent's behavior depends heavily on the model's own instruction-following and tool-selection capabilities; switching to a weaker model may result in frequent erroneous or missed tool calls.

The Role of Amazon Bedrock

Bedrock is AWS's model hosting service, providing foundation models from multiple vendors — Anthropic Claude, Amazon Nova, Meta Llama, Mistral, and others — through a unified API, with no need to deploy inference endpoints yourself. It bills by token usage, completely independent of the SageMaker notebook's compute costs. Calling Bedrock requires the IAM permission bedrock:InvokeModel, and each model must be explicitly enabled in the target region — this is the most common pitfall for newcomers, because the console displays the model list, but calling a model that hasn't been enabled returns an AccessDeniedException directly.

Environment Preparation: Creating a Notebook Instance

After entering the AWS console, find the Notebooks entry in the left panel and click to create a notebook instance. Give it a name and keep the remaining configurations at their defaults. The instance status will transition from Pending to InService, typically requiring a few minutes of waiting.

Once the instance is ready, click "Open JupyterLab" to enter the IDE, select the conda_python3 kernel in the Notebooks area to create a new ipynb file, right-click to rename it SimpleAgent.ipynb, and you're ready to start writing code.

Cost Control Cannot Be Overlooked

The tutorial author dedicates an entire section to emphasizing cost issues, which are easily overlooked in practice:

• Billing method: Billed based on notebook runtime, storage usage, and other AWS services combined
• Free tier: Eligible users can get 250 hours of ml.t3.medium usage per month for the first two months
• Instance selection: Start with a smaller instance during development
• Stop promptly: Stop immediately when done, but note that storage charges may still accrue after stopping
• Bedrock is billed separately: Calling models incurs additional costs, calculated separately from notebook costs
• Budget alerts: Set up AWS Budgets to monitor spending

Complete Steps for Building the Agent

Step 1: Install Dependencies

In the first cell, install the Strands Agents, boto3, and requests libraries. The latter two are used for AWS service calls and weather API requests, respectively.

Step 2: Configure the Bedrock Connection

After importing the necessary modules, read the AWS region and model ID from environment variables, providing default values. The code performs early credential verification via STS's get_caller_identity(), printing the current identity ARN and configuration information.

The tutorial specifically reminds: in a SageMaker environment, prioritize using the notebook's execution role and do not hard-code access keys.

Step 3: Create a Calculator Tool

Define a calculate function using the @tool decorator. For safety, the function only allows digits and basic operator characters, and passes an empty __builtins__ dictionary when using eval to restrict the execution scope.

Further Notes on eval Security

The tutorial uses eval to execute expressions and clears __builtins__, which is a minimal sandboxing measure. Clearing __builtins__ can block access to built-in functions like __import__, open, and exec, and combined with the preceding character whitelist validation (allowing only digits and +-*/.()), it can stop the vast majority of injection attempts. But it is not absolutely safe: Python's eval can still potentially bypass restrictions through object attribute chains (such as ().__class__.__bases__), so this is only demonstration-level protection. In production, you should switch to ast.literal_eval (which only supports literals), dedicated expression parsing libraries (such as simpleeval or numexpr), or simply move the computation logic into an isolated container or sandbox service for execution. What this example really aims to convey is this principle: tool function inputs come from model generation and must be treated as untrusted input, consistent with the mindset for handling user-submitted data in web development.

Step 4: Create a Weather Tool

This tool calls the free Open-Meteo API, with no key required. The process has two steps: first resolve the city name into latitude and longitude via the geocoding API, then fetch current weather data using the forecast API.

The return information includes temperature, apparent temperature, humidity, wind speed, precipitation, and observation time. The code includes a built-in mapping table from WMO weather codes to readable descriptions, covering 28 weather conditions from clear skies to thunderstorms with hail. Exception handling distinguishes between network request failures and data parsing exceptions, returning clear error descriptions rather than throwing stack traces in both cases.

One thing to note: the notebook environment must have outbound internet access.

Step 5: Assemble the Agent

Use BedrockModel to specify the model and region, and pass the model, tool list, and system prompt when creating the Agent instance. The system prompt requires the assistant to: use tools when helpful, explain answers concisely and clearly, indicate weather results come from Open-Meteo with the observation time attached, and honestly report API errors rather than fabricating data.

Steps 6–9: Testing the Agent's Capabilities

The tutorial designs progressive test cases:

1. A pure calculation question, "25 * 8" — verifies calculator tool invocation
2. A pure weather question, "weather in Bangalore" — verifies weather tool invocation
3. A combined question, "What's the temperature in Bangalore? Convert it to Fahrenheit and show the calculation process" — verifies the agentic workflow of multi-tool collaboration
4. A custom question — letting readers explore on their own

The third case best demonstrates the Agent's value: the model needs to first call the weather tool to get the temperature in Celsius, then call the calculator tool to complete the unit conversion.

Permission Configuration and Troubleshooting

The most common failure causes for Strands Agents integration with Bedrock center on permissions and region configuration:

AccessDeniedException: You need to enable the target model in the Bedrock console, and confirm that the SageMaker role has the bedrock:InvokeModel permission.

ValidationException or model unavailable: Check whether the model ID and region match. Some models are not available in all regions; you can modify it in the configuration cell or override it via environment variables.

No AWS credentials: Attach an IAM execution role to the SageMaker environment, or configure a standard credential chain. Never write access keys directly into the notebook text.

The tutorial provides an example inline policy that can be attached to AmazonSageMaker-ExecutionRole, granting the two actions bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream, with the resource limited to the nova-lite model ARN in the corresponding region.

A useful tip: notebooks use the us-east-1 region by default, so if your Bedrock model is enabled in another region, you need to explicitly set AWS_REGION or AWS_DEFAULT_REGION.

How the Agent Autonomously Selects Tools

When the Agent receives a request like "What's the temperature in Bangalore? Convert it to Fahrenheit and show the calculation process", what happens underneath is a multi-turn ReAct-style loop: the model first outputs its first round of reasoning, determines it needs weather data, and thus issues a weather_tool(city="Bangalore") call request; the SDK executes that function and appends the returned JSON result as a new round of messages into the context; after reading the Celsius temperature, the model issues calculate(expression="28*9/5+32"); once it has the value, it finally generates a natural language response. There are no hard-coded if-else branches throughout the process — tool selection is determined entirely by the model based on tool names, docstring descriptions, and parameter schemas. Therefore, whether a tool function's docstring is written clearly directly determines whether the model uses the right tool at the right time — this is an aspect many people overlook when debugging Agents. If you find the model answering directly from memory when it should be calling a tool, you usually need to strengthen the "must use tools" constraint in the system prompt, or improve the tool descriptions.

Wrapping Up and Key Takeaways

After completing the experiment, be sure to stop and delete the notebook instance, and remember to back up the ipynb file before deleting. The tutorial author provides the complete notebook file for download, which can be imported via the JupyterLab upload button.

Looking back at the entire process, this approach helps developers master several key capabilities: building an Agent with the Strands Agents framework and Bedrock, writing Python tool functions and integrating them into the Agent, connecting to real APIs to fetch dynamic data, understanding how the Agent autonomously selects tools based on question type, and the decisive role of IAM permissions when accessing Bedrock services.

For engineers who want to quickly experience the AI Agent development workflow, this is a cost-controlled, clearly structured entry path.

One-line Summary

Quickly build AI Agents capable of calling tools using SageMaker notebooks and the Strands Agents SDK.

Paragraph Summary

This article walks through the complete process of building an AI Agent on AWS using a SageMaker AI notebook and the open-source Strands Agents SDK. Strands Agents exposes Python functions to the model via the @tool decorator, letting the model autonomously decide which tool to call, and combines with Amazon Bedrock's nova-lite model for inference. The article proceeds step by step through environment preparation, dependency installation, Bedrock connection, defining calculator and weather tools, Agent assembly, and progressive testing, and validates multi-tool collaboration with a combined question. It also highlights two common pitfalls: cost control (billing by runtime and storage, Bedrock billed separately) and permission configuration (bedrock:InvokeModel, model region enablement, credential chain practices), providing engineers with a cost-controlled entry path.