DEV Community: Laura Salinas

Predicting Your AI Agent's Cost

Laura Salinas — Fri, 27 Feb 2026 17:31:46 +0000

I spent 2025 speaking at various developer/tech events around North America and out of all the feedback I received there was one thing that kept resurfacing:

Agents sounds interesting-- but how can I better predict the costs as I experiment?

Today I'm hoping to shed some light on how you can predict costs for agents you develop and deploy on AWS. The tools and methods I'll cover are specific to deploying agents using AWS services, so be sure to check pricing with any third-party tools, extensions etc to get a full picture of what your costs can be if you're using those within your applications as well.

Suffice it to say, estimating costs before you go to production is tricky because agent costs are emergent, basically they depend on how many steps the agent takes, how long the context grows, what tools it invokes, and how often it's called. I'll address the elements that we can control and share best practices for areas that are controlled/modified as you develop.

Pricing Out Your Agent

The cost of your agent is not simply the amount of input and output tokens consumed during user queries. What I've realized from speaking to developers of all levels, is there's a fundamental misunderstanding of what "counts" when you're pricing out an agent for a particular project. There are additional costs in the agent workflow that can include (amongst others):

1) System Prompts
2) Tool Schemas
3) Retrieved Context
4) Intermediate Reasoning Steps
5) Tool Call Results

Now this isn't a post about managing your context or contextual engineering, so if you want to take a side quest and learn more about managing context for your agents, I recommend checking out the blog "On Contextual Engineering" by an AWS Gen AI Specialist.

Alright with those primers out of the way, let's discuss how you can track and predict the cost of your agent proof of concept before you take it to production.

AWS Pricing Calculator

The first place to start with back of the napkin math is the AWS Pricing Calculator. As it relates to building and deploying agents on AWS, the recommended pathway as of this write up is to use Amazon Bedrock AgentCore. If you have not heard of AgentCore don't fret, it's still relatively new in the world of AWS having been generally released on October 13, 2025. If you want to brush up on essentials first I cover my first impressions with a simple demo in a previous post:

Laura Salinas for AWS

Sep 10 '25

First Impressions with Amazon Bedrock AgentCore

#aws #beginners #agents #ai

Comments 3

7 min read

Within the calculator you can toggle various components AgentCore offers such as Runtime, Gateway, Memory, Identity, Observability, Browser Tools and Code Interpreter.

For a basic agent you can start calculating costs with Runtime for basic functionality, and perhaps toggle Memory if you're looking to add native short-term (STM) or long-term (LTM) memory to the agent.

⚠️ Note: This does not yet factor in LLM usage which would require adding Amazon Bedrock estimates to your calculation to get a full picture.

Here's a conservative example for a proof of concept I'm working on only with AgentCore Runtime costs factored in:

With this first pass you can start to understand month over month what your agent costs begin to look like. Of course this is not an exact science, as your agent grows over time and its use in the larger application stabilizes, your costs may look different than initial calculations in the calculator.

AWS Cost Explorer

Ok, so you have a basic idea of what it could cost. Now let's dive one step further (this requires your AWS account) and learn how to track & understand charges once you are building. My favorite way to do this natively with no extra 3rd party tooling is with the built in Cost Explorer tool in the AWS console.

Here's what you get from using Cost Explorer

Interactive graph visuals
Ability to drill down by service, region, API call and more
Review data 3yrs in the past and forecast ahead up to 1yr
Easily save reports and exports as CSVs

Tracking

The first thing I like to do when diving into my project costs is setting the appropriate filters in the Report parameters pane.

Date Range: Specific periods I tested the agent
Granularity: Daily
Dimension: I rotate between these to see details about specific usage

a. Usage type

b. API Operation

Typically you won't see values trending negative, but I am demonstrating this in a Free Tier account so I am not being charged for any of this sample workload, the blue bars in these graphs are AWS credits applying to the account.

Forecasting

From the same Report parameters pane you can forecast by selecting how many months into the future you want the algorithm to run through. This can help paint a picture of what expected costs may look like if your agent utilization remains the same over time. Obviously with spikier workloads and high traffic scenarios this is a bit harder to predict over time but you can at the very least find a baseline usage model to grow/shrink from.

Bonus Round! 🤑

I know what you're thinking: isn't this all a little archaic to be doing manually...?

Well you can actually try out an MCP server built exclusively for AWS Pricing to enable your coding assistant to connect and use this information on your behalf.

I'm using the Kiro Agentic IDE and can one-click install the pricing MCP server for ease of use as I chat with the agent while I code.

Kiro gives me some detailed information on how I can think about pricing the agent:

And even takes it one step further to generates a sample pricing example that I can use to plug-and-play with my values:

Additional Resources 📚

Using Amazon Bedrock with AWS Free Tier for the 10,000 AIdeas Competition 🛠️

Laura Salinas — Tue, 06 Jan 2026 16:00:44 +0000

If you're gearing up for the AWS 10,000 AIdeas Competition (running December 5, 2025 to January 21, 2026), you're probably thinking about two things: building something awesome and not breaking the bank while you experiment.

Well I have some good news for you builders: Alongside the new AWS Free Tier, if you want to inject large language models (LLMs) into your application and take advatange of state of the art frontier models from folks like Anthropic, Meta, Amazon and others, Amazon Bedrock will be your best friend. With the new AWS Free Tier you've got some runway to build without worrying about surprise bills. Let's walk through how to maximize your free credits to build a competitive application without emptying your wallet.

What's This Hackathon All About?

The Global 10,000 AIdeas Competition is one of the largest developer competitions in AWS history, inviting developers worldwide to build innovative AI applications using AWS tools. You can join the competition to compete for $250,000 in cash prizes as well as recognition at AWS re:Invent 2026 and across AWS channels.

The requirement is simple: pitch an application idea for one of the five competition tracks: workplace efficiency, daily life enhancement, commercial solutions, social impact, or creative expression. Your initial submission is a written pitch—no code required at this stage—that describes what you want to build and why it matters.

If selected as a semi-finalist, that's when you'll build your app. Your finished app needs to use the agentic IDE Kiro for at least part of development, stay within AWS Free Tier limits, and be completely original and not yet published. For more details and FAQs about the competition you can head to the announcement post.

The New Free Tier: Everything You Need to Know

Now let's dig into how to use free tier for this competition. AWS recently revamped Free Tier for new accounts (created after July 15, 2025), so here's how it breaks down:

$100 in credits when you sign up
Up to $100 more in credits by completing five onboarding activities (including one specifically for Bedrock!)
Total: Up to $200 in credits
Duration: 6 months (or until you exhaust your credits)

One of those extra $20 credit activities? Using Amazon Bedrock in the playground. So literally just experimenting with LLMs in the Bedrock console earns you credits. How easy is that?!

It's important to note that Amazon Bedrock itself is not in the Always Free tier—you will be using your free credits to pay for Bedrock usage if you chose to add this service to your application.

How Amazon Bedrock Pricing Works

Before we dive into optimization, let's quickly break down how Bedrock charges you (because understanding this is half the battle):

Text models: Pay per token (both input and output)
Image models: Pay per image generated
Embeddings: Pay per input token

Bedrock offers three main pricing tiers:

On-Demand - Pay as you go, no commitments (this is what you'll use)
Batch Mode - 50% discount for non-urgent workloads using certain models
Provisioned Throughput - Reserved capacity (this is overkill for this competition)

For this competition, we recommended you use only on-demand standard tier pricing, which means every API call counts. The good news? You can predict costs pretty accurately since these calculations are token-based.

If you're curious, you can check out the official pricing page for Amazon Bedrock which includes even more details than the ones I mention here.

Which Models Should You Use?

Here's where some strategy comes in. Not all models are created equal when it comes to cost, and choosing wisely can make your $200 credits go way further.

Budget-Friendly Champions 🏆

All prices in this blog are referencing the US-East-1 (N. Virginia) region.

Amazon Nova Micro ($0.000035/1K input tokens, $0.00014/1K output tokens)

The cheapest of the Amazon models
Great for simple tasks, routing, or classification

Amazon Nova Lite ($0.00006/1K input tokens, $0.00024/1K output tokens)

Still incredibly affordable
Solid reasoning capabilities
My pick for most hackathon use cases where you need good performance without burning through credits

Meta Llama 3.3 70B ($0.00072/1K input tokens, $0.00072/1K output tokens)

Great price-to-performance ratio
Strong at reasoning and tool use
Flat pricing (same rate for input and output) makes cost prediction easy

Where to Splurge (Strategically) 🤑

Claude Sonnet 4.5 ($0.0033/1K input tokens, $0.0165/1K output tokens)

More expensive, but incredibly capable
Use for complex reasoning tasks where quality really matters
Great for your demo/presentation application where you want to wow the judges

Claude Haiku 4.5 ($0.0011/1K input tokens, $0.0055/1K output tokens)

Faster and cheaper than Sonnet
Good middle ground for production-like scenarios
My pick for a model if you're wanting to splurge

I'll leave a knowledge nugget for those wanting more info on Claude Haiku 4.5, this deep dive article by Anthropic shows just how performant and affordable this model is.

The Power Move: Intelligent Prompt Routing

Here's a pro tip that can save you up to 30% on costs: use Bedrock's Intelligent Prompt Routing. This feature automatically routes simple queries to cheaper models (like Nova Lite or Haiku) and complex queries to more capable models (like Sonnet or Nova Pro).

For a customer service agent, this means basic questions like "What are your hours?" go to the cheap model, while "I need help troubleshooting this complex integration issue" gets routed to the smart (expensive) model.

There is a cost associated with this cool feature, but at $1 per 1,000 requests it might be worth experimenting with it! For more detailed info check out the documentation page.

Maximizing Your Free Credits: Battle-Tested Tips

1. Start with Nova Lite or Nova Micro

Build your application with these models first. Get the logic working, nail your tool integrations, and perfect your prompts. Only upgrade to more expensive models when you're confident your application works well.

2. Use Batch Mode for Testing

If you have large test suites or want to evaluate multiple prompt variations, try using Batch mode for a 50% discount compared to on-demand. It's not real-time, but for development and testing, it can be quite useful.

3. Optimize Your Prompts

Shorter prompts = fewer tokens = lower costs. Every word counts. Be concise in your system prompts and examples.

4. Implement Prompt Caching

Avoid making redundant API calls. If your agent asks the same question multiple times, cache the response. This feature might not be available with all models so double check the documentation to learn more.

5. Monitor Costs in Real-Time

Head to the AWS Cost Explorer and filter by:

Granularity: Daily
Dimension: Usage Type (This shows exactly which models are costing you money)
Service: Bedrock

Check this daily during development. I can't stress enough how easy this is to do, you don't want to burn through $150 of credits on day three and realize it on day ten...

6. Set Up Budget Alerts

Go to AWS Budgets and create a budget.

For this specific competition you can set something up to simulate the burn rate of your free tier credits.

Create a budget for $200 with alerts at:

50% ($100 spent)
75% ($150 spent)
90% ($180 spent)

This way you get early warning before things get out of hand.

⚡️Bonus: setting up a cost budget is another one of those five onboarding tasks for the new Free Tier, so you automatically unlock another $20/$100 in extra AWS Credits by doing so!

7. Use the Playground First

The Bedrock playground in the console lets you test prompts without writing code. It's the same cost, but way faster for iteration. Plus, remember—using it earns you $20 in credits!

Regional Considerations

Not all models are available in all regions. The most model variety is in:

us-east-1 (N. Virginia) - Best option for maximum model access
us-west-2 (Oregon) - Good alternative with most models

Stick to these regions for the competition if you can to avoid any "model not available" headaches.

Final Thoughts

I know this may seem like a lot, so if you're more of a visual/video learner we actually have FREE, live learning sessions this week from AWS experts that will cover how to use AWS Free Tier!

Click below to register and attend one that fits your schedule:

Americas - January 6, 12 pm PT (GMT-8) Register
Europe, Middle East, Africa - January 7, 12 pm London Time (GMT+0) Register
Asia Pacific, Japan, China - January 7, 12 pm AEDT (GMT+11) Register

Now go build something cool. And seriously, set up those budget alerts first. Your wallet will thank you 😉

Additional Resources 📚

Build Multi-Agent Systems Using the Agents as Tools Pattern

Laura Salinas — Tue, 18 Nov 2025 00:23:43 +0000

In my last post I covered the Graph pattern and how structured, deterministic workflows can orchestrate multiple agents like a symphony orchestra following a conductor's score.👇🏼

Laura Salinas for AWS

Oct 31 '25

Strands Multi-Agent Systems: Graph

#aws #agents #ai #learning

Comments 1

5 min read

In this final post in this multi agent series, I'm diving into Agents as Tools. I'll share code snippets and examples that you can follow along with to build your own multi-agent system.

The Recap

While Graphs provide structured coordination through dependencies and Swarms enable autonomous collaboration, the Agents as Tools pattern brings hierarchical delegation to multi-agent orchestration. Instead of a single agent trying to handle everything, tasks are delegated to the most appropriate specialized agent.

One thing to note here, when using the Strands framework we are leaving the reasoning, decision making and tool selection to the model used at invocation time. When a query comes in, the agent’s LLM will parse the question and decide on a plan. We can thank Strands’s model-driven loop for this!

What Is an "Agents as Tools" System?

Agents as Tools is an architectural pattern where specialized AI agents are wrapped as callable functions that can be used by other agents. This creates a clear hierarchical structure with two distinct types of agents:

The Orchestrator Agent acts like a manager. It handles user interaction, understands requests, and determines which specialized agent to call. Think of it as the traffic controller for your multi-agent system.

Specialized Tool Agents are the domain experts. Each performs specific tasks when called by the orchestrator, bringing deep expertise in their focused area.

Key characteristics of the Agents as Tools pattern:

Separation of concerns - Each agent has one focused responsibility
Hierarchical delegation - Clear chain of command (orchestrator routing requests)
Modular architecture - Add, remove, or modify specialists independently
Optimized performance - Agents have tailored prompts and tools for their domain

The benefits of this pattern lie in its simplicity. Unlike Swarms where agents collaborate dynamically, or Graphs where execution follows dependencies, Agents as Tools uses straightforward function calls. The orchestrator simply decides which specialist to invoke based on the user's request.

How Agents as Tools Work

The pattern relies on three core components working together:

The @tool Decorator transforms your Python function into a tool that other agents can use. This is the key mechanism that wraps specialized agents as callable functions.

Specialized Agents are created within these tool functions. Each has a focused system prompt and relevant tools for its domain. They process specific types of requests when called.

The Orchestrator Agent receives the tool functions in its tools list. It reads the tool docstrings (which is why they're crucial!) to understand when to use each specialist.

Here's the flow:

User sends a request to the orchestrator
Orchestrator analyzes the request against available tool docstrings
Orchestrator selects and calls the appropriate specialized agent
Specialized agent processes the request with its domain expertise
Result flows back through the orchestrator to the user

Creating Specialized Tool Agents

Let's break down how to create specialized agents using the @tool decorator:

from strands import Agent, tool
from strands_tools import retrieve, http_request

# Define a specialized system prompt
RESEARCH_ASSISTANT_PROMPT = """
You are a specialized research assistant. Focus only on providing
factual, well-sourced information in response to research questions.
Always cite your sources when possible.
"""

@tool
def research_assistant(query: str) -> str:
    """
    Process and respond to research-related queries.

    Args:
        query: A research question requiring factual information

    Returns:
        A detailed research answer with citations
    """
    try:
        # Strands Agents SDK makes it easy to create a specialized agent
        research_agent = Agent(
            system_prompt=RESEARCH_ASSISTANT_PROMPT,
            tools=[retrieve, http_request]  # Research-specific tools
        )

        # Call the agent and return its response
        response = research_agent(query)
        return str(response)
    except Exception as e:
        return f"Error in research assistant: {str(e)}"

The key elements to notice:

Clear, descriptive docstrings - The LLM reads these to understand when to invoke your tool. Be detailed about what the agent handles and what parameters it expects.

Focused system prompt - Each specialized agent should have a tightly focused prompt that defines its expertise and boundaries.

Error handling - Always include try-except blocks to gracefully manage any issues that arise during execution.

Creating the Orchestrator

The orchestrator is the brain of your multi-agent system. Here's an example of how to build it:

from strands import Agent
from .specialized_agents import research_assistant, product_recommendation_assistant, trip_planning_assistant

# Define the orchestrator system prompt with clear tool selection guidance
MAIN_SYSTEM_PROMPT = """
You are an assistant that routes queries to specialized agents:
- For research questions and factual information → Use the research_assistant tool
- For product recommendations and shopping advice → Use the product_recommendation_assistant tool
- For travel planning and itineraries → Use the trip_planning_assistant tool
- For simple questions not requiring specialized knowledge → Answer directly

Always select the most appropriate tool based on the user's query.
"""

# Strands Agents SDK allows easy integration of agent tools
orchestrator = Agent(
    system_prompt=MAIN_SYSTEM_PROMPT,
    callback_handler=None,
    tools=[research_assistant, product_recommendation_assistant, trip_planning_assistant]
)

Notice something important: we're passing the specialized agent functions—those we decorated with @tool directly into the orchestrator's tools list. The Strands SDK handles all the complexity of making this work on our behalf.

The orchestrator's system prompt is critical. It should provide clear guidance on when to use each specialist, similar to training instructions for a manager coordinating a team.

When to Use Agents as Tools

Agents as Tools is ideal when you have clearly defined specialist domains and need hierarchical delegation. It performs well when you want a simple, maintainable architecture where adding new capabilities means adding new tool functions.

Use Agents as Tools when:

You have distinct domain expertise that can be cleanly separated
A hierarchical structure makes sense for your use case
You want straightforward routing logic
Each task type can be handled by a single specialist
You're building a customer service system, virtual assistant, or help desk

Best Practices 💡

From implementing the Agents as Tools pattern, here are some best practices:

Write crystal-clear docstrings - The LLM uses these to decide when to invoke your tool, so be descriptive and specific
Keep system prompts tightly focused - Each specialized agent should know exactly what it's responsible for and nothing more
Include comprehensive error handling - Every tool function should gracefully handle failures and return meaningful error messages
Give explicit routing guidance - Your orchestrator prompt should clearly explain when to use each specialist
Use consistent response patterns - Make sure all your specialized agents return responses in a similar format

Comparing the Multi-Agent Patterns

Now that we've covered all three patterns in this series, here's when to choose each:

Use Swarm when:

The problem benefits from exploration and brainstorming
Agents need to dynamically decide who should handle what
Collaboration and handoffs are central to the solution
The optimal agent sequence isn't known upfront

Use Graph when:

You have a clear workflow with known dependencies
Deterministic execution order is important
You need conditional branching or parallel processing
You're modeling a business process

Use Agents as Tools when:

You have clearly defined specialist domains
A hierarchical structure with a coordinator makes sense
You want simple, straightforward routing
Each task type maps to a single specialist

Often, you'll combine these patterns! For example, you might use Agents as Tools as your top-level pattern, with some specialists internally using a Graph or Swarm for their complex tasks.

Wrapping Up

This completes our journey through Strands multi-agent patterns! We've covered Swarms for autonomous collaboration, Graphs for structured orchestration, and now Agents as Tools for hierarchical delegation.

Each pattern has its strengths, and knowing when to use which is key to building effective multi-agent systems. Don't be afraid to mix and match patterns to solve your specific use case. As a reminder I have a FREE 2hr video course that you can enroll in to learn all about multi-agent systems at your own pace with step by step code examples.

Don't forget to give me a 🦄 if you got this far and let me know what else you're learning about in these agentic times!

Happy building!

Additional Resources 📚

Strands Multi-Agent Systems: Graph

Laura Salinas — Fri, 31 Oct 2025 17:00:00 +0000

In my last post I covered the Swarm pattern and how multiple specialized agents can collaborate dynamically like an ant colony.👇🏼

Laura Salinas for AWS

Oct 24 '25

Strands Multi-Agent Systems: Swarm

#aws #agents #ai #learning

Comments

5 min read

In this post we'll dive deeper into another of those patterns, Graph. I'll share code snippets and a the repo with examples that you can follow along.

Strands Multi-Agent Systems: Graph

While Swarms are all about autonomous collaboration and dynamic handoffs, the Graph pattern brings structure and determinism to multi-agent orchestration. You can think of it as the difference between a jazz band improvising together versus a symphony orchestra following a conductor's score. While both can be powerful, they ultimately serve different purposes.

What Is a Graph Multi-Agent System?

A Graph in Strands is a deterministic directed graph based agent orchestration system. In this system, agents are nodes in a graph and each node is executed based on edge dependencies. In practice what this means is the output from one node is passed as input to connected and dependent nodes.

Unlike sequential workflows where agents simply pass results down a line, or swarms where agents collaborate dynamically, graphs provide structured coordination. Each agent knows exactly when to execute based on the completion of its dependencies.

Key characteristics of the Graph pattern:

Deterministic execution order based on graph structure
Output propagation along edges between nodes
Clear dependency management between agents
Conditional logic for dynamic workflows
Support for cyclic patterns with proper safeguards
Nested multi-agent systems (like another Graph as a node!)

The benefits of this pattern are its predictability. You define your agents, specify their relationships (dependencies), and let the graph handle the execution orchestration.

How Graphs Work

Every graph consists of three core components working together:

GraphNode represents a node on the graph with:

A unique identifier
The executor (your actual Agent instance)
Dependencies on other nodes
Execution status tracking
Performance metrics

GraphEdge defines the connections between nodes, specifying:

Source and target nodes
Optional conditions that determine if the edge should be traversed

GraphBuilder provides a simple interface for constructing graphs, letting you:

Add nodes to the graph
Create edges between them
Set entry points for execution
Configure timeouts and max executions
Validate the graph structure

Input Propagation and Context Management

One crucial aspect of graphs is how information flows between agents. The graph automatically builds input for each node based on its dependencies.

Entry point nodes receive the original task as input, while dependent nodes receive a combined input that includes:

The original task description
Results from all completed dependency nodes

This ensures each agent has full context while maintaining clean separation of concerns. In this sample use case with 4 nodes, the report agent, for instance, gets both the original research agent and the fact-checking agent outputs without needing to coordinate directly with those agents.

Here's what the formatted input for a dependent node looks like:

Original Task: [The original task text]

Inputs from previous nodes:
From [node_id]:
- [Agent name]: [Result text]

From [another_node_id]:
- [Agent name]: [Result text]

Practical Implementation

Creating a graph involves defining your agents, building the graph structure, and executing it:

Step 1: Define Your Agents

# Create specialized agents
researcher = Agent(name="researcher", system_prompt="You are a research specialist...")
analyst = Agent(name="analyst", system_prompt="You are a data analysis specialist...")
fact_checker = Agent(name="fact_checker", system_prompt="You are a fact checking specialist...")
report_writer = Agent(name="report_writer", system_prompt="You are a report writing specialist...")

Step 2: Build the Graph Structure

# Build the graph
builder = GraphBuilder()

# Add nodes
builder.add_node(researcher, "research")
builder.add_node(analyst, "analysis")
builder.add_node(fact_checker, "fact_check")
builder.add_node(report_writer, "report")

# Add edges (dependencies)
builder.add_edge("research", "analysis")
builder.add_edge("research", "fact_check")
builder.add_edge("analysis", "report")
builder.add_edge("fact_check", "report")

# Build the graph
graph = builder.build()

Step 3: Execute and Analyze Results

# Execute the graph on a task
result = graph("Research the impact of AI on healthcare and create a comprehensive report")

# Access the results
print(f"Execution order: {[node.node_id for node in result.execution_order]}")

# Get performance metrics
print(f"Total nodes: {result.total_nodes}")
print(f"Completed nodes: {result.completed_nodes}")
print(f"Failed nodes: {result.failed_nodes}")
print(f"Execution time: {result.execution_time}ms")
print(f"Token usage: {result.accumulated_usage}")

The graph returns detailed results including execution status, which agents participated, individual agent outputs, performance metrics, and token usage statistics.

Common Graph Topologies

There are three common graph patterns you might encounter:

Sequential Pipeline: Good for quality control workflows where each step builds on the previous one. Research → Analysis → Review → Report.

Parallel Processing: A coordinator distributes work to multiple specialists, then aggregates results. Great for comprehensive analysis from different perspectives/specialiazed agents.

Branching Logic: A classifier determines which specialized branch to take. Useful for routing different types of requests to appropriate specialists.

Conditional Edges

One powerful feature of graphs is conditional edges. Like you saw in the branching topology, they let you create dynamic workflows based on intermediate results:

def only_if_research_successful(state):
    """Only traverse if research was successful."""
    research_node = state.results.get("research")
    if not research_node:
        return False

    # Check if research result contains success indicator
    result_text = str(research_node.result)
    return "successful" in result_text.lower()

# Add conditional edge
builder.add_edge("research", "analysis", condition=only_if_research_successful)

When to Use Graph

A Graph is ideal when you need a structured process with conditional logic, branching, or loops with deterministic execution flow. It performs well for modeling business processes or any task where the next step is decided by the outcome of the current one.

Best Practices 💡

From exploring the graph pattern, here are some best practices:

Leverage conditional edges - Create dynamic workflows based on intermediate results
Handle failures gracefully - Think about how node failures affect the overall workflow
Nest strategically - Use Swarms within Graphs for complex workflows combining structure and collaboration
Set appropriate limits - Use timeouts and max executions, especially for cyclic graphs

Swarm vs. Graph: When to Choose Which?

Now that we've covered two patterns, you might be wondering when to use each:

Use Swarm when:

The problem benefits from exploration and brainstorming
You want agents to dynamically decide who should handle what
Collaboration and handoffs are central to the solution
The optimal agent sequence isn't known upfront

Use Graph when:

You have a clear workflow structure with known dependencies
Deterministic execution order is important
You need conditional branching or feedback loops
Different parts of the workflow can run in parallel
You're modeling a business process

In the last post of this series we'll dive deeper into the Agents as Tools pattern, so stay tuned for that!

Don't forget to give me a 🦄 if you got this far and let me know what pattern you're most excited to try in the comments!

Additional Resources 📚

Strands Multi-Agent Systems: Swarm

Laura Salinas — Fri, 24 Oct 2025 14:00:00 +0000

In my last post I started introducing the concept of multi agent systems and gave a brief overview of the 5 patterns you can explore with Strands Agents 👇🏼

Laura Salinas for AWS

Oct 19 '25

Multi-Agent Systems with Strands Agents

#aws #agents #ai #learning

Comments

4 min read

In this post we'll dive deeper into one of those patterns, Swarm. I'll share coding snippets and a the repo with examples that you can follow along.

What Is Swarm Intelligence?

Think about an ant colony: thousands of individual ants, each following simple rules, yet together they build complex structures, find optimal food sources, and adapt to challenges. No single ant directs the colony, yet collective intelligence emerges.

Agent swarms apply this same principle found in nature to artificial intelligence. Instead of one powerful agent trying to solve everything, we create multiple specialized agents that work together as a team. Each agent has its own expertise, but they share knowledge and can coordinate their efforts.

Key characteristics of agent swarms:

Self-organizing teams with shared working memory
Tool-based coordination between agents
Autonomous collaboration without central control
Dynamic task distribution based on agent capabilities
Collective intelligence through shared context

This pattern often leads to emergent intelligence, or the idea that a group of specialized agents working together can solve problems more effectively than even the most sophisticated single agent. Why you may ask? Well the theory lies in the understanding that as agents work together, they're approaching unexpected behaviors, creativity, and problem-solving capabilities that were not explicitly coded by their developers.

How Swarms Work

In the Strands Agents framework, each agent in a swarm has access to four critical components:

Full Task Context - Every agent sees the complete problem
Agent History - They know which agents have worked on the task
Shared Knowledge - They access insights from other agents
Handoff Capability - They can transfer control to specialist agents

Coordination Mechanisms

Effective coordination is what separates a swarm from just multiple agents working separately. The Strands framework provides built-in coordination tools to make this easy to accomplish.

The Handoff Tool allows agents to transfer control precisely. For example, a handoff tool can give an agent named coder the context and let it implement the necessary Python code.

# Handoff Tool Description: Transfer control to another agent in the swarm for specialized help.
handoff_to_agent(
    agent_name="coder",
    message="I need help implementing this algorithm in Python",
    context={"algorithm_details": "..."}
)

Shared context ensures every agent has the full picture. When an agent receives a handoff, they see:

The handoff message explaining why they were called
The original user request
Which agents worked on this previously
Shared knowledge from all previous agents
List of other available specialists

Swarms in Strands also support multi-modal inputs—not just text, but images as well. This means your swarm can analyze diagrams, process reports, and generate a comprehensive analysis all in one workflow.

Here's an example of a multi-modal agent swarm:


from strands import Agent
from strands.multiagent import Swarm
from strands.types.content import ContentBlock

# Create agents for image processing workflow
image_analyzer = Agent(name="image_analyzer", system_prompt="You are an image analysis expert...")
report_writer = Agent(name="report_writer", system_prompt="You are a report writing expert...")

# Create the swarm
swarm = Swarm([image_analyzer, report_writer])

# Create content blocks with text and image
content_blocks = [
    ContentBlock(text="Analyze this image and create a report about what you see:"),
    ContentBlock(image={"format": "png", "source": {"bytes": image_bytes}}),
]

# Execute the swarm with multi-modal input
result = swarm(content_blocks)

Practical Implementation

Creating a swarm involves three key steps:

Step 1: Define Your Agents

# Create specialized agents
researcher = Agent(name="researcher", system_prompt="You are a research specialist...")
coder = Agent(name="coder", system_prompt="You are a coding specialist...")
reviewer = Agent(name="reviewer", system_prompt="You are a code review specialist...")
architect = Agent(name="architect", system_prompt="You are a system architecture specialist...")

Step 2: Create a swarm and configure behavior and safety parameters

# Create a swarm with these agents, starting with the researcher
swarm = Swarm(
    [coder, researcher, reviewer, architect],
    entry_point=researcher,  # Start with the researcher
    max_handoffs=20,
    max_iterations=20,
    execution_timeout=900.0,  # 15 minutes
    node_timeout=300.0,       # 5 minutes per agent
    repetitive_handoff_detection_window=8,  # There must be >= 3 unique agents in the last 8 handoffs
    repetitive_handoff_min_unique_agents=3
)

Step 3: Execute and Analyze Results

# Execute the swarm on a task
result = swarm("Design and implement a simple REST API for a todo app")

# Access node history
print(f"Node history: {[node.node_id for node in result.node_history]}")

The swarm constructor can return detailed results including execution status, which agents participated, individual agent outputs, performance metrics, and token usage statistics.

When to Use Swarm

A Swarm is ideal when your problem can be broken down into sub-tasks that benefit from different specialized perspectives. It's best for exploration, brainstorming, or synthesizing information from multiple sources through collaborative handoffs.

Context Management at Scale 📊

One challenge worth mentioning with swarms is managing shared context at scale. When every agent has access to the full context, things can get bloated quickly.

Strands has an interesting solution to this with the use_llm tool. This allows you to have dynamic LLMs that perform specific tasks and return just the results, keeping the main agent's context lean. You can check out more details in the Strands community built tools.

Best Practices 💡

From my exploration of swarm patterns, here are some best practices to keep in mind:

Create specialized agents - Define clear roles for each agent in your swarm
Set appropriate timeouts - Base these on task complexity and expected runtime
Enable repetitive handoff detection - Prevent ping-pong behavior between agents

In the coming weeks we'll dive deeper into Graph and Agents as Tools patterns, so stay tuned for that!

Don't forget to give me a 🦄 if you got this far and let me know what pattern you're most excited to try in the comments!

Additional Resources 📚

Multi-Agent Systems with Strands Agents

Laura Salinas — Sun, 19 Oct 2025 20:26:48 +0000

As AI agents continue to evolve, I've been diving deep into multi-agent systems and specifically how we can leverage certain patterns to tackle complex problems that single agents simply can't handle alone. Think of it like assembling a team of specialists rather than relying on one generalist to do everything.

In this post I'll walk through the fundamentals of multi-agent systems and introduce some key patterns you should know about.

What Are Multi-Agent Systems? 🤖

At its core, a multi-agent system is composed of multiple autonomous agents that interact with each other to achieve a mutual goal—one that's typically too complex or too large for any single agent to reach alone.

Core Principles

Three key principles govern effective multi-agent systems:

Orchestration - A controlling logic or structure to manage the flow of information and tasks between agents. This is like having a conductor in an orchestra, ensuring everyone knows when to play their part.

Specialization - Each agent has a specific role or expertise, and a set of tools that it can use. Rather than having generalist agents, we create specialists. One might excel at data analysis, another at natural language processing, and another at writing code.

Collaboration - Agents communicate and share information to build upon each other's work. This isn't just parallel processing—it's true collaboration where agents build upon each other's contributions.

Architectural Designs 🏗️

Multi-agent systems can be organized into three main types, each suited to different types of problems:

Hierarchical Systems use a central orchestrator agent that interprets the overall task, decomposes it into subtasks, and delegates those to worker agents, each optimized for a particular domain. This mirrors traditional organizational structures with clear chains of command.

Broadcast Systems share information broadly across all agents simultaneously. This ensures everyone has the same context, but can lead to information overload.

Graph-Based Systems allow for complex communication patterns where agents form networks of relationships. These agents may operate independently or with other agents by sharing information, dividing responsibilities, and collectively reasoning toward a goal.

Fundamental Patterns 🎯

Now let's explore the five primary patterns of multi-agent systems. Each has distinct characteristics and use cases:

Pattern 1: Swarm

The Swarm pattern represents a dynamic, collaborative team of agents that autonomously hand off tasks. A developer provides a pool of agents, and the agents themselves decide the path.

Key Characteristics:

Autonomous decision-making about handoffs
Emergent execution paths
Shared context across all agents

Pattern 2: Workflow

The Workflow pattern represents a structured coordination of tasks across multiple AI agents, where each agent performs specialized functions in a defined sequence or pattern. Here, a developer defines all tasks and their dependencies in code.

Key Characteristics:

Predictable execution
Excellent for repeatable processes
Efficient parallel processing

Pattern 3: Graph

The Graph pattern combines structure with flexibility. A structured, developer-defined flowchart where an agent decides which path to take. Developers define all nodes (agents) and edges (transitions) in advance, but the actual path is determined dynamically by the agents.

Key Characteristics:

Structured yet flexible
Conditional logic and branching
Error handling through defined paths

Pattern 4: Agent as Tool

An architectural pattern where specialized AI agents are wrapped as callable functions (tools) that can be used by other agents.

Key Characteristics:

Clear separation of concerns
Hierarchical delegation
Modular architecture that's easy to maintain

Pattern 5: Agent-to-Agent (A2A) Protocol

Announced in April 2025, this pattern represents a breakthrough in multi-agent architecture. It's an open standard that enables AI agents from different platforms, organizations, and implementations to discover, communicate, and collaborate seamlessly.

Unlike the previous patterns which operate within a single system, A2A creates a distributed ecosystem where agents can work across organizational and technical boundaries. Each A2A-enabled agent exposes an "agent card", which is a standardized description of its capabilities, skills, and interfaces.

Key Characteristics:

Multi-agent workflows across platforms
Agent marketplaces for discovering and using agents from different providers
Cross-platform integration
Distributed AI systems at scale

Collaboration, Negotiation, and Emergent Behavior 🌟

What makes multi-agent systems truly powerful is how agents collaborate and sometimes negotiate to achieve optimal outcomes.

Collaboration Mechanisms

Each pattern handles collaboration differently. In Graph systems, a single, shared dict object is passed to all agents, who can freely read and modify it. In Swarm systems, a "shared context" or working memory is available to all agents, containing the original request, task history, and knowledge from previous agents.

Negotiation and Decision Making

In swarm patterns especially, agents must negotiate who should handle what tasks. This isn't pre-programmed though, the agents use their understanding of the problem and their capabilities to make these decisions autonomously.

Emergent Behavior

Perhaps most interesting is emergent behavior. These are complex problem-solving patterns that arise from simple agent interactions. A swarm might develop unexpected but effective solution paths that no single developer anticipated.

For instance, in a customer service swarm, agents might develop novel escalation patterns based on customer sentiment analysis, creating more effective resolution paths than any pre-defined workflow.

Choosing the Right Pattern 🎨

Choosing the right pattern is critical for building an effective system. Consider:

Deterministic vs. emergent behavior - Do you need predictable outcomes or are you exploring possibilities?
Problem complexity - How many moving parts and dependencies exist?
Parallel execution requirements - Can tasks run simultaneously or must they be sequential?
Error handling needs - How critical is it to have defined error paths?
Cross-platform requirements - Do you need agents from different organizations to collaborate?

As AI systems become more sophisticated, multi-agent architectures will enable us to tackle increasingly complex challenges by harnessing the collective intelligence of specialized AI agents working in harmony.

In the coming weeks I'm planning to dive deeper into Swarm, Graph and Agents as Tools patterns, so stay tuned for that!

Don't forget to give me a 🦄 if you got this far and let me know what pattern you're most excited to try in the comments!

Additional Resources 📚

First Impressions with Amazon Bedrock AgentCore

Laura Salinas — Wed, 10 Sep 2025 23:28:36 +0000

As we continue to see AI agents progress in their capabilities and versatility, I've been hearing from developers that most of their experience deploying agents remains local and experimental. Whether you're developing agents with tools like Strands Agents, Crew AI, LangGraph and others, the fact of the matter is moving from PoC to production-ready is mystifying, if not impossible at scale.

In this post I'll cover some basics on a new AWS service to address this and my first experience using it.

Now, as we look at this challenge I mentioned with PoC → Production, it's not surprising to see the preview launch of Amazon Bedrock AgentCore trying to fill this much needed gap for developers.

For those who aren't aware, on July 16th AWS announced AgentCore to enable developers to deploy AI agents at scale using the well know ideals of a flexible, scaleable infrastructure and essential security controls (amongst other things).

Of the many interesting things to come with this announcement is a somewhat unique mental model for an AWS service- AgentCore presents itself as a modular (think Lego pieces) toolbox of components allowing developers to pick what components they need and use them together or independently as their use case changes.

In addition to its modularity, AgentCore is attempting to set itself apart by offering both model and agent framework choice (i.e., you don't have to use Amazon Bedrock and you can use open source frameworks).

Understanding AgentCore Components 🧩

Here's a simple breakdown of the 7 AgentCore components that are in preview:

AgentCore Runtime: a secure, serverless runtime for deploying and scaling AI agents and tools using any open-source framework, any protocol, and any model.
AgentCore Identity: a secure, scalable agent identity and access management capability. Compatible with existing identity providers, eliminating needs for user migration or rebuilding authentication flows.
AgentCore Memory: provides support for both short-term memory for multi-turn conversations and long-term memory that can be shared across agents and sessions.
AgentCore Code Interpreter: enables agents to securely execute code in isolated sandbox environments. Offers advanced configuration support and seamless integration with popular frameworks.
AgentCore Browser: provides a fast, secure, cloud-based browser runtime to enable AI agents to interact with websites at scale.
AgentCore Gateway: a secure way for agents to discover and use tools along with easy transformation of APIs, Lambda functions, and existing services into agent-compatible tools.
AgentCore Observability: helps developers trace, debug, and monitor agent performance in production through unified operational dashboards. Support for OpenTelemetry compatible telemetry and detailed visualizations of each step of the agent workflow.

As of this post, the preview for Bedrock AgentCore is currently only available in US East (N. Virginia), US West (Oregon), Asia Pacific (Sydney), and Europe (Frankfurt).

My experience with AgentCore Runtime 🔨

I took a day to hack with AgentCore knowing absolutely nothing about it, and though I can't say it was a completely user-friendly experience, I'll walkthrough some areas I did enjoy and what I hope the team working on it can improve as it prepares for general availability.

I started my AgentCore journey by going to the place I figured had the best setup for a true beginner: the official AWS Samples GitHub, from here there were several options for what I wanted to learn-

1) Hosting Agents on Runtime
2) Hosting an MCP Server on Runtime
3) Advanced Concepts
4) Hosting TypeScript based MCP on Runtime

I opted for the first option and the tutorials here come in three flavors as seen below

I've been working quite a bit with the Strands Agents framework and wanted to use my Antropic API key, so I followed the OpenAI example for my hack as it was the closest to what I wanted to do.

Note: While I'm usually a fan of Jupyter Notebooks I found this one a bit challenging to follow and noticed it adds a lot of complexity to what is already a somewhat complex service to use. I've given feedback to the team but wanted to share my 2 cents if you're also using some of these notebook tutorials.

The example in the notebook creates a tool for the agent which I opted out of and instead use a pre-existing Strands tool for AWS use. My code looks a bit different than what you'll find in the notebook. For context here is what my agent.py file looks like and how I prepared it for use with AgentCore Runtime.

⚠️Note: The use_aws tool looks for my AWS profile locally to authenticate using ~/.aws/credentials, you'll need that setup before attempting to use this tool or any others that require AWS account use.

import os
from bedrock_agentcore.runtime import BedrockAgentCoreApp
from strands import Agent
from strands.models.anthropic import AnthropicModel
from strands_tools import use_aws 

app = BedrockAgentCoreApp()

model = AnthropicModel(
    client_args={
        "api_key": os.getenv("api_key"),
    },
    # **model_config
    max_tokens=1028,
    model_id="claude-sonnet-4-20250514",params={"temperature": 0.3,}
)

agent = Agent(model=model, tools =[use_aws])

@app.entrypoint

def strands_agent_anthropic(payload):
    """
    Invoke the agent with a payload
    """
    user_input = payload.get("prompt")
    response = agent(user_input)
    return response.message["content"][0]['text'].replace('\\n', '\n')

if __name__ == "__main__":
    app.run()

Main things to highlight here are lines of code you need in order to prepare your agent to work with Runtime, they're listed in the notebook, but I'll share here for simplicity as well:

Import the Runtime App with from bedrock_agentcore.runtime import BedrockAgentCoreApp
Initialize the App in your code with app = BedrockAgentCoreApp()
Decorate the invocation function with the @app.entrypoint decorator
Let AgentCore Runtime control the running of the agent with app.run()

Once this is complete I need to deploy the agent to Runtime. This can be done in one of two ways, either manually (several more steps, more to manage and requires experience with docker) OR using the AgentCore starter toolkit which is a CLI toolkit that manages a lot of the deployment steps for you. For those that want to maintain full control over their agent's implementation, this section of the documentation describes how to deploy agents to Runtime without the toolkit.

Using the starter toolkit the next steps are fairly straightforward.

1) Configure the agent with default values using: agentcore configure -e agent.py in the terminal.
2) Host the agent in Runtime using: agentcore launch in the terminal.

If all goes well on the backend I should see a success message on the terminal that looks like this:

To invoke the agent I can use agentcore invoke '{"prompt": "how many VPCs do I have in us-west-2?"}' in the terminal (this is an example prompt for my particular agent which uses a Strands tool to extract information in my AWS account)

Looks like everything is working well because I can see the results from that agent interaction in my terminal:

Now let me quickly cover the painpoints I discovered along the way...

Challenges, pain points etc. 😵‍💫

In using the sample notebooks there is no mention of enabling observability for the agent which is a requirement as stated in step 1 of the getting started documentation.

TLDR; you need to enable CloudWatch Transaction Search in order for AgentCore Runtime to properly invoke your agent.

This led to several hard to debug/track invokation errors in my terminal.

My particular agent was performing a boto3 operation using EC2 and thus required IAM permissions that are not default. Finding the IAM execution role for the agent to edit these permissions was particularly tricky.

FYI you can find this agent execution role in one of three ways:

1) Searching the IAM AWS console for “agentcore'” and working backwards to find the role

2) Open the hidden yaml file generated at time of configuration and look under ‘execution role’

3) Navigate to the AgentCore AWS console → agent runtime → agent name → versions → IAM service role

Overall once I was setup correctly to use Runtime things did work smoothly and the start toolkit was valuable, however there is still a lot of room for folks to get tripped up when using this and unfortnatley the examples themselves need some sharpening to avoid common pitfalls.

In the coming weeks I'm looking to explore other components of AgentCore such as Memory and Gateway so stay tuned for that.

Don't forget to give me a 🦄 if you got this far and let me know what else you'd like to see a write up on in the comments!

Additional Resources 📚

Using Strands Agents with Anthropic API 🧬

Laura Salinas — Tue, 08 Jul 2025 21:00:40 +0000

It's been a few weeks since I talked about using Strands Agents for the first time and I wanted to add a quick update on two pieces I've been experimenting with this week.

Using Anthropic as a model provider instead of Amazon Bedrock
Using other helpful built-in tools

If you haven't already setup Strands, check out my last post to get started.

Laura Salinas for AWS

Jun 23 '25

First Impressions with Strands Agents SDK 🧬

#aws #beginners #learning #opensource

Comments 5

6 min read

Using Anthropic as a model provider

As a refresher from my last post, Strands Agents can be used with a variety of model providers including Amazon Bedrock (which I covered last) as well as Anthropic, OpenAI, Ollama, LiteLLM and more.

Today I'm testing integration with my Anthropic API and continuing to use some of the built-in tools Strands offers.

To get started, I head to the Strands model provider documentation and install the optional Anthropic dependency with pip install 'strands-agents[anthropic]'.

Now I can import the dependency in my Python application with from strands.models.anthropic import AnthropicModel.

I test that the integration works by executing a simple sample:

import os
from strands import Agent
from strands.models.anthropic import AnthropicModel
from dotenv import load_dotenv

model = AnthropicModel(
    client_args={
        "api_key": os.getenv("api_key"),
    },
    # **model_config
    max_tokens=1028,
    model_id="claude-sonnet-4-20250514",
    params={
        "temperature": 0.3,
    }
)

agent = Agent(model=model)
response = agent("What was the most visited city in the world in 2024?")

The response in my terminal:

Using other built-in tools

In my last post I touched on the http_request tool which gives my agent the ability to Make API calls, fetch web data, and call local HTTP servers. This time I wanted to check out the use_aws tool which gives my agent the ability to interact with AWS Services across a variety of simple to complex use cases.

I have a lot of S3 buckets in my AWS account and it would be nice to get a list of all these buckets before I run an audit on what I can delete. Using natural language I should be able to tell Strands to list all of these for me.

import os
from strands import Agent
from strands.models.anthropic import AnthropicModel
from strands_tools import use_aws
from dotenv import load_dotenv

model = AnthropicModel(
    client_args={
        "api_key": os.getenv("api_key"),
    },
    # **model_config
    max_tokens=1028,
    model_id="claude-sonnet-4-20250514",
    params={
        "temperature": 0.3,
    }
)

agent = Agent(model=model, tools=[use_aws])
query= "List all my S3 buckets in us-west-2"
response = agent(query)

The response in my terminal:

When I execute the file I see Strands understands it's been asked a question it needs to use a tool for, and appropriately goes through the use_aws option to generate the response. While I explicitly called out the region as us-west-2, the response explains that the list_buckets operation in the tool extracts all S3 buckets across my account by default, hence the other ones that are populating in the response.

⚠️Note: The use_aws tool looks for my AWS profile locally to authenticate from ~/.aws/credentials, you'll need that setup before attempting to use this tool or any others that require AWS account use.

That's it for this quick update, don't forget to give me a 🦄 if you got this far and let me know what else you'd like to see in the comments!

Additional Resources 📚

First Impressions with Strands Agents SDK 🧬

Laura Salinas — Mon, 23 Jun 2025 06:00:00 +0000

It's been exactly 3 months since I last wrote about agents and the industry has certainly made leaps since then. With the release of more support for agentic workflows across CSPs (cloud service provider), this felt like the right time to dive into one of the options still warm on the press, Strands Agents SDK.

I first heard about Strands as I logged back into work after a week vacation in Japan. Talk about bleeding edge, I'm away for 7 days and suddenly there's a brand new open source SDK that's making a splash.

If you somehow missed this announcement last month, I highly recommend giving the official launch blog a read to get familiar.

The TLDR 👉🏼 Strands Agents is an open source SDK that takes a model-driven approach to building and running AI agents in just a few lines of code (and seriously in <10 lines I'm up and running).

Best part yet? This isn't just a 'stay in your prototype and experiment' type of solution. Teams at AWS have already been using Strands Agents in stealth mode before the public release. In fact, if you've gotten your hands on Q CLI for an agentic coding experience, then you're already reaping the benefits of an AWS team that built and shipped with Strands Agents in just 3 weeks 🤯

With that background, I wanted to play around with Strands Agents to see how quickly I could get started and what my first impressions are so far. Let's go 🤘🏼

Setup

Pretty straightforward, in the documentation you can find instructions on installation.

I create a new python file in my local repository and create a virtual environment to install packages related to this project.

Core functionality using pip3 install strands-agents
Built in tools using pip3 install strands-agents-tools

⚠️ Note: I'm using AWS as the model provider to run Strands which means I've already set up AWS credentials and enabled model access. The default model provider for Strands is Amazon Bedrock and the default model is Claude 3.7 Sonnet in the US Oregon (us-west-2) region. I don't cover AWS CLI setup here, but check out the docs if you haven't done that first.

Creating your first agent

With setup and model provider access complete I can get started building my first agent.

From the Strands documentation I start my python file with the skeleton code needed (again this is <10 lines to get to basic use)

from strands import Agent

# Create an agent with default settings
agent = Agent()

# Ask the agent a question
agent("Tell me about agentic AI")

Running this with python3 strands-agent.py and I see Strands goes to work using Claude 3.7 Sonnet to pose the query "Tell me about Agentic AI". We see a quick response in my terminal.

Now that I know things are working we can get a bit more creative.

Building complexity in agents

Let's say I want to create an agent that helps new pet parents find a dog that best meets their lifestyle. Maintaining the same idea as the example code above, we create an agent, dog_breed_helper, and use the following system prompt.

You are a dog breed expert specializing in helping new pet parents decide what breed meets their lifestyles. Your expertise covers dog behavior, dog training, basic veterinary care, and dog breed standards.

    When giving recommendations:
    1. Provide both benefits and challenges of owning that breed
    2. Give examples when necessary
    3. Avoid jargon, but indicate when complex concepts are important

Your goal is to help pet parents make an informed decision about their choice in a dog.

⚠️ There's certainly room for improvement in this system prompt, but the point here is to experiment and show you how easy it is to contextualize and ground an agent.

To test this agent I use a query like "Which dog should I adopt as a first time owner if I have an office job m-f 9-5, like to hike on weekends and don't know much about training?"

I execute the file, python3 dog_breed_agent.py and the results are below.

Next, I want to test one of the capabilities of Strands Agents that allows me to take my dog helper agent to the next level. This capability is to integrate tools to extend my agent's own knowledge.

If you're not yet familiar with the term- "Tools" are what transform a basic conversational agent into a truly useful assistant that can interact with the world. In this example, I'll explore using the built-in tools provided by the Strands SDK. Tools allow my agent to interact with external systems, access data and manipulate its environment.

To learn more you can check out which built-in tools Strands offers to get started quickly.

For my small experiment today I want to enhance my agent by having it search for information on the web. I can use the built in http_request tool to do this.

To enable this tool use in my python application I add from strands_tools import http_requestand then add the function call to my system prompt tools=[http_request]. I change my query to reflect both items I need help with.

My updated python file looks like so:

from strands import Agent
from strands_tools import http_request

# Create a basic agent with a specialized system prompt
dog_breed_helper = Agent(
    system_prompt="""You are a dog breed expert specializing
    in helping new pet parents decide what breed meets their lifestyles. Your expertise
    covers dog behavior, dog training, basic veterinary care, and dog breed standards.

    When giving recommendations:
    1. Provide both benefits and challenges of owning that breed. 
    2. Only provide 3 recommendations at a time.
    3. Give examples when necessary
    4. Avoid jargon, but indicate when complex concepts are important

    Your goal is to help pet parents make an informed decision about their choice in a dog.
    """,
    tools=[http_request]
)

query= """
Answer these questions:
1. Which dog should I adopt as a first time owner if I have an office job m-f 9-5, like to hike on weekends and don't know much about training?
2. Search wikipedia for the top 5 most popular dog breeds of 2024
"""
response = dog_breed_helper(query)

💡 What I notice when I execute the file is Strands automatically knows which tool(s) to invoke based on the context of our conversation. When I say search the web it knows it needs to call the http_request tool to answer the question. This behavior is really impressive and opens up a lot of room to make these agents more than just simple text generators.

⚠️ Note: I did run into some throttling limits when experimenting with the http_request tool. If your queries are hanging longer than a few seconds you may see an error like the one I had which indicates AWS usage for the ConverseStream API is at capacity.
"An error occurred (ThrottlingException) when calling the ConverseStream operation (reached max retries: 4): Too many tokens, please wait before trying again."
You can have Strands switch to another model by passing the model ID string directly. I tried Sonnet 3.5 by adding model="anthropic.claude-3-5-sonnet-20240620-v1:0" to my agent definition.

When executing correctly, the response I receive from my agent is the following:

Answering the first question

Answering the second question

Learnings

Creating an agent was easy and straightforward with functioning python app in <10 lines and <10min
Adding complexity to agents using Strands can also be done easily whether through pre-built tools or adding custom tools
Errors from model providers (in my case Amazon Bedrock) are still a challenge, make sure to understand your service/model quotas as you experiment
Be open to switching to another version of a model if responses are lagging or being throttled

Let me know in the comments what your use cases for Strands Agents could be and leave a 🦄 if you made it this far!

Additional Resources 📚

Cost-effective security controls for Amazon Bedrock

Laura Salinas — Mon, 28 Apr 2025 22:12:13 +0000

In my last post I discussed my tips for tracking and forecasting Amazon Bedrock costs on the management console 👇🏼

Laura Salinas for AWS

Apr 17 '25

Amazon Bedrock Pricing 101 💰

#aws #ai #beginners #learning

Comments

5 min read

and after some discussions with readers on and offline, folks were wondering how they could also limit a user's Bedrock access (to models, to features, etc) via IAM policies.

The intent here is to adhere to both organization security policies and to budget constraints for developers experimenting and using AWS.

Let's jump in and see how this can be done 🤘🏼

Refresher on IAM

I hope if you're reading this you're intimately familiar with AWS IAM or Identity Access Management, as it's the foundation for controlling access to AWS resources. From authentication to authorization, IAM provides the necessary infrastructure to get this done.

You might be familiar with Amazon Bedrock access by way of the managed IAM policy AmazonBedrockFullAccess which provides users with unrestricted access to the entire suite of features available within the Bedrock service.

⚠️ This doesn't inherently mean access to all foundation models (FMs) by default. A user will still need to request access to FMs and accept EULAs to use models within Bedrock.

The practice of having users inherit a managed FullAccess policy is what we want to prevent for the purposes of this use case (and in general to adhere to AWS best practices for least privilege permissions).

Putting it all together

The behavior I want to demonstrate is a user having restricted access to Bedrock in order to prevent surprise usage spikes from simple mistakes- like using a model that management has deemed "too expensive," using features not approved, or exceeding use of a particular model.

For this demonstration I have created a user in IAM Identity Center . To prevent UI errors from the Bedrock console, at the time of creation this user is given the managed AmazonBedrockReadOnly policy. This will help prevent listing and reading errors in the UI as I click through. You can inspect the full details of that policy here.

In the console, I can test whether this user is functional by logging into the identity center access portal for my user Bedrock-Test.

With only this policy attached, upon logging in I cannot use any AWS services.

⚠️ A reminder, if you're not able to access FMs, a user has to first request access and accept EULAs before attempting to use any models within Bedrock.

I test this by attempting to chat with a model in the playground.

As we further scope this policy, I want to allow a user to experiment with Bedrock only on the console playground and only with a certain model. I do this by listing the specific actions I want to allow and on Anthropic's Claude Opus model as the only resource.

⚠️ Before using any of these sample policies confirm you have permission to test IAM policies in your organization, and are working in a controlled environment (i.e., not prod). These IAM policies have been generated with Q Developer as a demonstration and should be subject to additional review before utilization. Note that this policy is scoped to a single account and thus requires an account ID.


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "BedrockPlaygroundOnlyAccess",
            "Effect": "Allow",
            "Action": [
                "bedrock:InvokeModel",
                "bedrock:InvokeModelWithResponseStream"
            ],
            "Resource": [
                "arn:aws:bedrock:*:*:foundation-model/anthropic.claude-3-opus-20240229-v1:0",
                "arn:aws:bedrock:*:<Account ID>:inference-profile/*"
            ]
        }
    ]
}

Limiting use of features

To confirm I only have access to the playground and no other features of Bedrock, I try creating a Bedrock Agent and a Bedrock Guardrail and see that I am denied access to both while under this user.

Limiting use of models

In this example I want to allow a user to have the same access above, but they should also be allowed to use the DeepSeek-R1 model in the playground. To do this, I add the JSON below to the policy I used previously. I indicate the behavior by allowing the action explicitly and using the ARN of the model in the resource field.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "BedrockPlaygroundOnlyAccess",
            "Effect": "Allow",
            "Action": [
                "bedrock:InvokeModel",
                "bedrock:InvokeModelWithResponseStream"
            ],
            "Resource": [
                "arn:aws:bedrock:*:*:foundation-model/anthropic.claude-3-opus-20240229-v1:0",
                "arn:aws:bedrock:*:*:foundation-model/deepseek.r1-v1:0",
                "arn:aws:bedrock:*:<Account ID>:inference-profile/*"
            ]
        }
    ]
}

When I try the same prompt above but with the DeepSeek-R1 model, I can see my access is also allowed, and the query is processed.

Limiting use for a model

After some investigating, it seems there isn't currently a way to do this via IAM policies for Bedrock. At the time of writing, there is no direct IAM condition that limits the number of API calls or tokens for this use case. There may be other ways to tackle this via a combination of AWS Service Quotas and/or AWS Budgets, but I'll have to look into that for another day.

Leave a comment if you've explored this challenge or have some ideas about what a stopgap is for limiting Bedrock use on a per-model call/token basis.

Takeaways 💡

1/ To ensure best practices are followed, the AWS recommendation is to use Identity Center to manage authentication via existing IdP when possible.

2/ You can use IAM Access Analyzer during policy creation to review for various aspects like validating grammar and best practices. (You can locate these findings at the bottom of the JSON creation pane on the console)

3/ There are still some challenges in limiting API calls directly for Bedrock. The service team is aware of this limitation and actively working on a solution.

Additional Resources 📚

Amazon Bedrock Pricing 101 💰

Laura Salinas — Thu, 17 Apr 2025 21:24:58 +0000

I don't know about you, but I hear a lot about how difficult it can be to predict & track costs when using Amazon Bedrock 🥵

I spent the last ~2yrs as a solutions architect helping customers in the the ML startup space understand how they can take advantage of this easy to use, LLM APIs at your fingertips service, and I think the #☝🏼 question was still:

This is great-- but how can we better predict and forecast our costs as we experiment?

Today I'm hoping to pull back the curtain and share everything I do to monitor Bedrock costs in my account, and what I have been recommending to customers for years.

AWS Pricing Calculator

Tried and true, the first place to start is with the pricing calculator. For all its hiccups, the calculator has come a long way since I first started using it in 2018, and it remains easy to use to forecast costs without needing an AWS account. With a single plug and play input field for token count you can generate an estimate and depending on your use case, add additional context for model customization in the other fields.

The 🐘 in the room? At this time the pricing calculator only supports estimates with first party Amazon Titan or Amazon Nova models.

For 3rd party models like Anthropic, Mistral, Meta, etc (arguably the most used on Bedrock) you'll still have to reference the Amazon Bedrock Pricing page for the specific model version and its per token price.

AWS Cost Explorer

Ok, let's dive one step deeper (and one that requires your AWS account) into tracking & understanding Bedrock charges. My favorite way to do this is with the built in Cost Explorer tool in the management console.

First off, why I like this approach?

Interactive graph visuals
Ability to drill down by service, region, API call and more
Can review data 3yrs in the past and forecast ahead up to 1yr
Easily save reports and exports as CSVs

Tracking

The first thing I like to do when diving into my Bedrock costs is set the appropriate filters in the Report parameters pane.

Date Range: YTD (unless I'm drilling down on a specific date/time)
Granularity: Monthly (again, unless I'm investigating a specific issue)
Dimension: This one varies but here are the main ones I use.

a. Usage type - I love the granularity here, and it also displays region which is helpful when operating across multiple regions and looking for a quick snapshot.

b. API Operation - The values here more closely match the verbiage of the bill which makes troubleshooting service charges easier.

c. Tag - Very helpful if you're in the practice of tagging workloads by team, project, business unit, etc. (Which you should be 😉)

Forecasting

From the same Report parameters pane you can do forecasting easily by selecting how many months into the future you want the algorithm to run through.

There's a bit of data analytics science under the hood for this prediction algorithm, you can read more about that here if you're curious.

AWS Billing Console

While most of my use for service charge troubleshooting happens in cost explorer, sometimes it helps to see the line items in your bill directly.

For bill access head to the Bills console. In the service name search field you'll want to enter Bedrock Service and Bedrock. This will pickup both 3P and 1P model charges alongside any other native Bedrock features (like guardrails).

One other aspect in the billing console I'd like to point out is the Usage Quantity column. For Bedrock specifically this is where you can find token count!

AWS Budgets

I won't lie to you I haven't used budgets in my own AWS account, but I recommend it often given how powerful it can be for alerting before a major bill spike. You can also create actions based on budget breaches or approximations on a budget that's been set.

For more information on configuring budget actions check out the documentation.

For those of you who are visual learners, this tutorial on setting budget alerts provides a great walkthrough as well.

Takeaways 💡

As with all things AWS, use the right tool for the right job. For quick and dirty inspection I prefer cost explorer, for more intricate things there are plenty of third party tools to explore in the AWS marketplace (over 5000 hits on 'cost management' alone)
Use multiple dimensions in cost explorer to help triage costs across several services (e.g. S3 + CloudFront spikes)
Tagging and setting budget alerts will be your best friend to prevent a billing jump scare

Additional Resources 📚

AWS Cloud Financial Management Blogs

Sound off in the comments if you have other pricing challenges you've observed with Bedrock or anything else you'd like to learn about!

First Impressions with Nova Act SDK 🤔

Laura Salinas — Thu, 10 Apr 2025 19:16:50 +0000

It's been a little over a week since the announcement of the Nova Act SDK which is currently in research preview (US Only). I carved out my lunch break to see how quickly I could get up and running. Join me below to see how far I get in about an hour 🙈.

Setup

You'll need to first request access to Nova via your Amazon login (Amazon the one you shop from 📦, not your AWS account). You may be placed on a waitlist if you don't see access granted immediately, keep an eye on your email if that's the case.

With access granted head to the Nova Act SDK. You'll see there are three steps outlined. Installing the SDK, setting up an API key and a first workflow sample.

I head to the onboarding guide for more info on how to interact with the SDK and how to authenticate.

⚠️ I had some minor trouble here using the API key as an environment variable. Thinking I'd get ahead of the curve I created a .env file with the API key so that my vscode project could pick it up, but that kept throwing errors. TL;DR- just use export NOVA_ACT_API_KEY="your_api_key" before you start a session in terminal and it'll make the SDK happy. Below the error I kept getting.

You can use the SDK in a Python script or directly from the terminal with the standard Python shell.

Example Usage

I'm currently learning Japanese as a hobby and to feel a little more comfortable on my upcoming trip next month, so I figured let's test Nova Act by asking it to help me with some flashcards for practicing hiragana with diacritical marks (Duolingo just isn't enough 😭)

My first attempt looks like this:

from nova_act import NovaAct

with NovaAct(starting_page="https://www.google.com") as nova:
    nova.act("search google for Japanese hiragana with diacritical " \
    "marks flashcards, find ones that can print well.")

Which leads the agent to Google, it searches for my query and then opens the first web result which is Quizlet. So far so good. I see the agent describing it's thinking process in my terminal and it starts checking for a print button on the site.

As it does so a popup captcha appears prompting for a click to confirm humanity which... feels hilarious for this first use of Nova Act. Now, things go a little off the rails here- Nova Act understands there is a popup but gets stuck in a loop where it can't close the popup and can't continue to navigate the page either. I give it a few seconds before exiting the script.

💡 So, first lesson learned here- some sites are definitely detecting the use of agents and this behavior currently breaks Nova Act (unless you get crafty which...during this quick hack I didn't 🙂)

I'm curious if I try prompting it to avoid sites and instead go directly to google images if I can get better results.

Attempt two looks like this:

from nova_act import NovaAct

with NovaAct(starting_page="https://www.google.com") as nova:
    nova.act("search google images for flashcards for japanese " \
    "hiragana with diacritical marks. Find ones that can print well.")

This worked well, except I forgot to give the agent something specific to do so once it finds the images tab so it scrolls endlessly until I stop the script.

Attempt three looks like this:

from nova_act import NovaAct

with NovaAct(starting_page="https://www.google.com") as nova:
    nova.act(

        "Search google images for flashcards for japanese hiragana " \
        "with diacritical marks."
        "Right click or secondary click an image."
        "In the context menu click 'Open image in new tab'."
        )

I spent a over 30min trying to figure out the correct way to prompt Nova Act so it would perform a right-click otherwise known as a secondary-click for the context menu and couldn't find a way...

Learnings

While the functionality of a web capable agent is promising, like most difficulties with agents/AI automation, finding the right way to tell the model to do what you want is still challenging. I wanted to get more done with this example, but I couldn't justify spending more time to figure out how to get the model to understand a concept as simple to a human as a right click 🖱️

Stay tuned for more as I continue to tinker with Nova Act (and perhaps come back to finish up this example...)

(PS- I have already given this missing context menu action feedback to the Nova Act team! PFR in the works 🔨)

Additional Resources 📚

GitHub Samples