DEV Community: AWS

Bigger AI models aren't always better. Here's how to actually choose.

Rohini Gaonkar — Fri, 15 May 2026 16:58:32 +0000

In the previous post, I showed you two models answering the same question. One hallucinated confidently. The other knew when to stop.

And a bunch of you asked: okay, but which one should I actually use?

Haiku, Sonnet, Opus. Micro, Lite, Pro. Mini, Small, Large. There are dozens of models and they all sound like perfume brands. How are you supposed to pick one?

That's this post. I'm going to take one prompt, run it through two models (one small, one large), and show you what's different. Then I'll give you a simple framework for choosing the right one.

The demo: same prompt, two models

I went back to the recipe from the first post. Same recipe. Same question. Two different model sizes.

The prompt:

"I'm cooking this for six people on Saturday. One is vegan, one is gluten-free. Adapt the recipe for me, give me a shopping list, and a timeline starting from 4pm."

The small model

Quickly, it gave me a shopping list, a timeline, and basic adaptations. Nothing fancy, but everything I asked for. If I just need a quick answer and I'm going to double-check it anyway, this works.

For a lot of everyday tasks, this is genuinely all you need.

The large model

Same prompt but a very different response.

It added a whole "Strategy for the vegan guest" section explaining why you should make a parallel pot instead of adapting the main dish. It gave me a timeline starting from the night before. Separated prep into phases. Told me to keep the rice pots separate so nothing touches the vegan side. Scaling math for going from 4 servings to 6. It even gave me an oven method AND a stovetop method as alternatives.

More thorough and more considerate. But did I need all of that for a Saturday dinner? Maybe or maybe not.

There are medium-sized models in between these two and they exist in every family. I'll tell you when to reach for them later.

But the contrast between small and large is where our today's lesson lives.

Why models come in sizes

Let's take a simple example.

My son is two. If I ask him what he wants for dinner, he says "pasta." Done in two seconds without any deliberation.

If you ask me what to make for dinner, I'm thinking: what's in the fridge, what did we have yesterday, does he need more protein today, is it too late to start something that takes 40 minutes, should I batch-cook for tomorrow. Ten variables that will take me five minutes. I will give you a better answer, but slower.

Models work the same way.

A model's "size" is roughly how many parameters it has.

Think of parameters as the variables it can hold in its head when making a decision. More variables, more nuance, more ability to handle complex tasks. Fewer variables, faster and cheaper, but less sophisticated.

My son doesn't need ten variables to pick dinner. He just needs to decide. And for a lot of tasks, that's all you need from a model too. A fast answer. Not a perfect one.

Training a big model costs more. Running a big model costs more per question. And it's slower, because there are more variables to weigh for every single response.

So why not just always use the biggest one? Two reasons.

First, cost.

If you're building something that handles thousands of requests, the difference between a small model and a large model is the difference between a reasonable bill and a terrifying one.

Second, and this is the one people miss: bigger isn't always better.

For simple tasks, a big model can actually overthink it. Give you more than you asked for. Take longer to say something the small model said in two seconds.

The model families you see (Haiku/Sonnet/Opus, Micro/Lite/Pro) are just size tiers from the same provider. Same architecture, different capacity. Like buying a car in compact, sedan, or SUV. Same manufacturer. Different trade-offs. You don't take the SUV to grab milk. You don't take the compact on a cross-country road trip with three kids.

Tokens and pricing: how you actually pay

Models don't charge by the question. They charge by the token.

What's a token? It's a chunk of text. Not quite a word, not quite a letter, but roughly three-quarters of a word.

Take the sentence: "Adapt this recipe for a gluten-free vegan." Seven words but nine tokens. Some words get split, some punctuation becomes its own token.

You don't need to memorise this. Just know: token count and word count aren't the same thing. A full page of text is around 400 tokens. A million tokens is roughly a 750,000-word book.

There's a free tool called Tiktokenizer where you can paste text and see exactly how a model breaks it into tokens. It's weirdly satisfying. Try it.

One thing that surprised me: different models tokenize the same text differently. I sent the exact same prompt and recipe to both models. The small one counted 6,548 input tokens. The large one counted 16,685. Same words, different tokenizers under the hood.

And here's the thing: you get charged twice. Once for the tokens you send in (your question). And once for the tokens the model sends back (its answer). Input tokens and output tokens. They're priced separately, and output is always more expensive, because that's where the model is doing the work.

Real numbers

On Amazon Bedrock, for the Claude family (pricing as of May 2025, check current prices here):

Model	Size	Input (per 1M tokens)	Output (per 1M tokens)
Haiku	Small	~$1	~$5
Sonnet	Medium	~$3	~$15
Opus	Large	~$5	~$25

That's 5x more expensive from small to large. Same question, same answer, but 5x the price on both sides.

If you're asking one question yourself, who cares. The difference is fractions of a cent. But if you're building an app that handles ten thousand requests a day, each one generating a few hundred output tokens, that 5x multiplier turns into real money fast.

The best model is the model you can afford to run at the scale you need.

Where it breaks: when bigger is worse

Let's go back to the large model's response and look at the over-engineered parts. The timeline starting from the night before. "Marinate chicken in yogurt and spices, overnight is best." Fry the vegan portion first in clean oil, then fry the chicken onions in separate oil. Keep the rice pots separate. An oven method AND a stovetop method as alternatives.

The small model? A simple table. 4:00pm, start marinating. 4:05, fry onions. 5:15, into the oven. 7:00, serve. Done.

Opus is doing project management for my Saturday dinner. And here's the real cost of that overthinking.

The small model: 18 seconds, about 1,900 output tokens.
The large model: 44 seconds, 2,700 output tokens.

40% more output. 2.4x slower. And about 10x more expensive for that single request.

For a Saturday dinner, this is overkill. And if I were building an app that answers recipe questions for thousands of users, I'd be paying for all that extra thinking on every single request.

This is the trade-off. Bigger models are smarter, but "smarter" isn't always what you need. Sometimes you need fast, cheap, and good enough.

How to actually choose

Here's how I think about it.

First, the biggest factor: cost. We just saw a 5x difference between small and large. And that's per token. When the big model also generates 40% more tokens per response, it compounds fast. That alone narrows the field for most people. If you're building something, cost is the thing that decides what's even on the table.

If you can't afford to run it at the scale you need, it doesn't matter how good it is.

Start there. What can you actually sustain?

Then, once cost has set your boundaries, three questions help you pick within them.

1. How complex is the task?
Summarising an email? Small model. Writing a legal brief? Big model. Adapting a recipe? Probably medium.

2. How many times will you run it?
If it's one question from you personally, use whatever you want. If it's an app serving thousands of users, speed matters just as much as quality. Start small, upgrade only when the quality isn't good enough.

3. What are the stakes?
If a wrong answer ruins dinner, that's low stakes. If a wrong answer means bad financial processing logic that costs you millions, that's high stakes. Higher stakes, bigger model, plus verification on top.

That's it. Cost sets the ceiling. Complexity, volume, and stakes help you pick the floor. You don't need to memorise model names. You need to know what you're optimising for.

What about picking a provider?

I've been showing models from different providers. Claude, Nova, Llama. How do you pick a family?

Honestly? Pick the one that's available where you already work. If you're on AWS, you have access to all of them through Bedrock. If you're somewhere else, use what's there. The concepts are the same. Don't overthink the brand. Overthink the task.

One thing that confuses a lot of us early on: models and products are not the same thing. Claude is a model. But Claude inside Kiro (a coding IDE) behaves differently from Claude in the Bedrock Playground, which behaves differently from Claude on claude.ai. Same model underneath.

But each product wraps it with different instructions, tools, and context that shape how it responds. Kiro's Claude is tuned for writing code. The Playground's Claude is general-purpose. Same brain, different job description.

So when you see dozens of AI "products" out there, many of them are the same few models dressed up for different use cases. The model decides how smart it is. The product decides what it's pointed at, and priced accordingly.

Try it yourself

If you're just getting started: models come in sizes. Bigger is smarter but slower and more expensive. For most everyday tasks, a medium model is the sweet spot. Try a few and see which one feels right for what you're doing.

If you're more on the builder side: start with the smallest model that gives acceptable quality. Only upgrade when you can point to a specific failure the bigger model fixes. Don't start big and optimise down. Start small and justify up. And remember, you can use different models for different parts of the same system. The router doesn't need to be the same size as the reasoner. The model that decides which tool to call doesn't need to be the same one that processes the result.

Start small. Justify up.

What's next

We are going to talk why model forgets what you told it. Ride Along.

This post is part of the "Learning AI Out Loud" series, a cloud architect learning AI from first principles.

Follow along with the series

Creating Your First Lambda Function

Eric D Johnson — Fri, 15 May 2026 06:00:00 +0000

So you want to build your first serverless function? Let's do it. No fluff, no detours — just you, AWS SAM, and a working Lambda function running on your machine in minutes. We're not even going to deploy to AWS yet. Let's just get it working locally first.

What You'll Need

Two things:

AWS SAM CLI installed — SAM (Serverless Application Model) is the tool we'll use to create, build, and test our function. Follow the install guide for your operating system.
Docker or Finch installed — SAM uses a container runtime to simulate Lambda locally. You have two options:
- Docker Desktop — The most common option. Install it and make sure it's running.
- Finch — A lightweight open source alternative from AWS. Install it with brew install finch.

Verify your setup

Check that SAM is installed:

sam --version

If you chose Finch, initialize and start the VM:

finch vm init
finch vm start

SAM automatically detects Finch when Docker isn't running — no extra configuration needed. If you have both installed, SAM uses Docker by default. To make Finch the default on macOS, run:

sudo /usr/libexec/PlistBuddy -c "Add :DefaultContainerRuntime string finch" /Library/Preferences/com.amazon.samcli.plist

Verify your container runtime is working:

docker --version   # or: finch --version

That's it. No AWS account needed yet. We're staying local for now.

Step 1: Initialize Your Project

Open your terminal and run:

sam init

SAM is going to walk you through a few questions. For this blog, I'm using the TypeScript template, but you can choose any runtime and template you'd like — Python, Java, Go, whatever you're comfortable with. The prompts, project structure, and file names will vary depending on what you pick. Here's what I chose:

Template source — Choose 1 - AWS Quick Start Templates
Quick start template — Choose 1 - Hello World Example
Use the most popular runtime and package type? — N
Runtime — Choose 12 - nodejs24.x
Package type — Choose Zip
Starter template — Choose 2 — Hello World Example TypeScript
Enable X-Ray tracing? — N (we'll keep it simple for now)
Enable CloudWatch Application Insights? — N
Enable Lambda Insights? — N
Project name — Hit Enter to accept the default, or name it whatever you like

SAM just scaffolded an entire serverless project for you. Let's look at what we got:

sam-app/
├── template.yaml          # The blueprint for your infrastructure
├── samconfig.toml         # SAM deployment configuration
├── hello-world/           # Your function code lives here
│   ├── app.ts             # Your actual Lambda function
│   ├── package.json       # Dependencies
│   └── tests/             # Unit tests
│       └── unit/
│           └── test-handler.test.ts
└── events/
    └── event.json         # A sample test event

The two files that matter most:

template.yaml — This describes your Lambda function and any AWS resources it needs. Think of it as the blueprint.
app.ts — This is your actual function code. The thing that runs when your Lambda gets invoked.

Understanding the template

Let's look at the key part of template.yaml — the function resource:

Resources:
  HelloWorldFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: hello-world/
      Handler: app.lambdaHandler
      Runtime: nodejs24.x
      Architectures:
        - x86_64
      Events:
        HelloWorld:
          Type: Api
          Properties:
            Path: /hello
            Method: get
    Metadata:
      BuildMethod: esbuild
      BuildProperties:
        Minify: true
        Target: "es2020"
        Sourcemap: true
        EntryPoints:
          - app.ts

Here's what's going on:

Type: AWS::Serverless::Function — This tells SAM to create a Lambda function. SAM handles all the underlying CloudFormation resources for you.
CodeUri: hello-world/ — Points to the folder where your function code lives.
Handler: app.lambdaHandler — Tells Lambda which file and function to run. In this case, the lambdaHandler export in app.ts.
Runtime: nodejs24.x — The Node.js version your function runs on.

The magic is in the Events section. By adding an event with Type: Api, SAM automatically creates an API Gateway for you — no extra configuration needed. You didn't define an API Gateway resource anywhere, but SAM sees that your function wants to respond to HTTP requests at GET /hello and wires it all up behind the scenes. One line, and you've got a fully managed API endpoint in front of your Lambda.

The Metadata section tells SAM how to build your TypeScript code. Instead of running tsc and bundling manually, SAM uses esbuild — a JavaScript/TypeScript bundler. It compiles your TypeScript, minifies the output, generates sourcemaps for debugging, and packages it all up. You don't need to install esbuild yourself — SAM handles it during sam build.

Step 2: Build It

cd sam-app
sam build

SAM grabs your code, installs any dependencies, and packages everything up. You'll see a .aws-sam folder appear — that's your build output. You don't need to touch it.

Don't have the runtime installed on your machine (e.g., no Node.js)? No problem — just add --use-container and SAM will build inside a Docker/Finch container instead:

sam build --use-container

SAM will automatically pull down a container image that matches your function's runtime, build your code inside it, and output the packaged result to .aws-sam just like a normal build. You get the exact same Lambda environment without installing anything on your machine.

Step 3: Test It Locally

Here's the fun part. Run your Lambda function right on your machine:

sam local invoke

You should see a response like:

{"statusCode": 200, "body": "{\"message\": \"hello world\"}"}

That's your Lambda function running locally. No AWS account, no deployment, no charges. Just your code doing its thing.

Make It Yours

Let's make a quick change so you can see the full loop — edit, build, test. Open hello-world/app.ts and find this line:

message: 'hello world',

Change it to:

message: 'hello Lambda',

Now rebuild and invoke again:

sam build
sam local invoke

{"statusCode": 200, "body": "{\"message\": \"hello Lambda\"}"}

That's the workflow. Change your code, build, test — all local, all instant.

Want to test it as an API instead? Run:

sam local start-api

This spins up a local API Gateway. Open your browser and hit http://127.0.0.1:3000/hello and you'll see:

{"message": "hello Lambda"}

You now have a fully functional serverless API running on your laptop.

What Just Happened?

In about 5 minutes, you:

Scaffolded a serverless project with a single command
Learned how the SAM template automatically wires up a Lambda function and API Gateway
Built your TypeScript code with esbuild — no manual setup needed
Ran a Lambda function locally
Made a code change and saw it reflected instantly
Spun up a local API endpoint and hit it from the browser

All without touching AWS. All free. All on your machine.

Ready to Deploy? Let's Go Live.

You've got it working locally. Now let's put it in the cloud so the rest of the world can use it. For this part, you'll need a couple more things set up.

Additional Requirements

An AWS account — Head to aws.amazon.com/free and sign up. New customers get up to $200 in credits and a Free Plan that lets you explore AWS for up to 6 months at no cost. On top of that, Lambda has its own always-free tier — 1 million requests and 400,000 GB-seconds of compute per month.
AWS CLI installed and configured — This is how your machine talks to your AWS account. First, install it from the AWS CLI install guide. Then follow the Setting up the AWS CLI guide to configure your credentials. For most new users, you'll want the IAM user with short-term credentials option — it's the recommended approach for getting started securely.

Once you're set up, verify it's working:

aws sts get-caller-identity

If you see your account ID, you're connected.

Step 4: Deploy It

From your project directory, run:

sam deploy --guided

The --guided flag walks you through the deployment settings the first time. Here's what to expect:

Stack Name — Give it a name (like my-sam-app)
AWS Region — Pick your closest region (e.g., us-east-1)
Confirm changes before deploy — Y
Allow SAM CLI IAM role creation — Y (SAM needs to create a role for your function)
Disable rollback — N
Save arguments to config file — Y (so you don't have to answer these again)

SAM will show you a changeset — a preview of what it's about to create. Type Y to confirm, and watch it go.

When it's done, you'll see an Outputs section with a URL. That's your live API endpoint. Copy it, paste it in your browser, and...

{"message": "hello Lambda"}

🎉 Your Lambda function is live on AWS.

Clean Up

Don't want to leave resources hanging around? Tear it all down with:

sam delete

SAM removes everything it created. Clean slate.

What Just Happened?

In about 10 minutes, you:

Scaffolded a serverless project with a single command
Learned how the SAM template automatically wires up a Lambda function and API Gateway
Built your TypeScript code with esbuild — no manual setup needed
Tested your function locally and made a code change
Spun up a local API and hit it from the browser
Deployed it to AWS with a real, live URL
Cleaned it all up with one command

SAM handled all the heavy lifting — the CloudFormation stack, the IAM roles, the API Gateway, the packaging. You just answered a few questions.

What's Next?

You've got the basics down. From here you can:

Add more functions to your template.yaml
Connect your Lambda to DynamoDB, S3, or other AWS services
Set up environment variables and custom permissions
Explore event-driven architectures with SNS, SQS, and EventBridge

Want to keep learning? Check out Serverless Land — the go-to hub for all things Lambda and serverless with patterns, tutorials, and best practices. Or dive into the Sessions with SAM YouTube playlist that goes deeper into everything AWS SAM can do.

But that's for next time. For now, celebrate — you just went serverless. 🚀

The new Agent Toolkit for AWS includes 20+ agent skills, but your agent might never load them without this one file

Esin Saribudak — Thu, 14 May 2026 12:00:00 +0000

The Agent Toolkit for AWS gives your coding agent access to the AWS MCP and curated skills, but without updating the rules file, your agent might answer from model training data instead of using its new tools.

Last updated: May 15, 2026

If you're like me, sometimes you get so excited to try something new that you don't read all the way through the docs before you start using it. Last week, the Agent Toolkit for AWS had just been released, I had the README open, and two minutes later I was asking my agent to design a serverless backend in my Kiro IDE.

But the agent didn't touch any of the tools I had just configured. It answered from training data and gave me a reasonable API Gateway + Lambda + DynamoDB architecture, but never reached for the MCP documentation search or the aws-core skills I had installed. I had to prompt it to use the MCP server and skills before it gave them a go.

I had skipped one important file in my rush to try out this new toolkit, and it turned out to be the file that made my agent reach for these tools predictably.

What's in the toolkit

The Agent Toolkit for AWS was released on May 6, 2026. It works with Claude Code, Codex, Kiro, and any agent that supports MCP, and it has three layers:

The MCP Server gives your agent access to 300+ AWS APIs through one endpoint, plus sandboxed Python execution and real-time doc search (no AWS credentials needed for searching docs).
Skills are packaged domain expertise, including architecture decision tables, service comparison matrices, deployment workflows, and troubleshooting guides (20+ available today).
A rules file tells the agent to use layers 1 and 2 before answering from memory.

I had layers 1 and 2 set up but skipped layer 3, so the agent had all the tools and none of the instructions to use them.

Setup takes two minutes — follow the README's quick start for your agent (Kiro, Claude Code, Codex, or other MCP-compatible agents).

The file I skipped

There's a rules file in the toolkit repo's rules/ directory, which I missed when setting it up. The README's quick start section doesn't mention it, and I was already typing prompts by the time I could have noticed. But there's a difference between "can discover skills" and "will proactively load them before answering." The rules file bridges that gap. It's 17 lines and tells the agent to:

Prefer the AWS MCP Server for all AWS interactions
Before starting a task, check whether a relevant AWS skill is available
Load the skill with retrieve_skill and prefer its guidance over general knowledge
When uncertain about API parameters, permissions, or limits, verify against documentation rather than guessing

For more information on where to put the rules file for different agents, check out the docs here.

Before I added this file, the agent had passive access to skills, but after I dropped it in, skill loading became the agent's first move on any AWS question and it started pulling architecture decision tables before writing code.

For a simple CRUD app like the one I was building, the AWS MCP skills refined the implementation rather than redirected it. The LLMs have gotten so good that their general knowledge already gets you to the right architecture much of the time (in my case, API Gateway + Lambda + DynamoDB + Cognito). Where the skills added value was in specificity and confidence. Here's what I got before and after:

	Before (no rules file)	After (rules file added)
Architecture advice	Three options presented (serverless, containers, Amplify) with a general "Option 1 is the sweet spot" recommendation	One specific architecture with a decision table explaining why each component was chosen over its alternatives
API Gateway type	"API Gateway" (unspecified which type)	"HTTP API specifically, because REST API is overkill unless you need WAF or caching"
Auth approach	"Cognito or roll your own with Lambda + bcrypt + JWT"	"JWT authorizer with Cognito because HTTP API has native JWT support, no Lambda authorizer needed"
Function pattern	Not mentioned	"One function per route" (skill best practice)
Constraints flagged	None	30s hard timeout, 10 MB payload limit, no WAF on HTTP API, silent Forbidden on JWT scope mismatch
Source of guidance	Model training data	AWS documentation + `aws-serverless` skill's service selection tables
Level of specificity	Told me what to build	Told me which variant to build and why that variant over the alternatives

The skills would be even more useful than general LLM knowledge for more complex architectures involving things like event processing or multi-pattern designs, where the pattern selection flowcharts and service comparison tables would change the agent's choices rather than validate them.

What this taught me about coding agents and skills

Giving a coding agent access to tools is not the same as telling it when to use them. Skills are designed to be loaded on demand, which means something has to tell the agent when to demand them. Without a rule, the agent treats skills like reference books on a shelf: available if it decides to look, but not part of its default workflow. The rules file is what changes "available on request" into "check this before you start."

Guardrails

If you're wondering, "Is it safe to let an agent call AWS APIs?", that's a great question to be asking. The good news is that you can scope down what the agent is allowed to do separately from your own permissions, so even if your IAM role can create and delete resources, you can restrict the agent to read-only. Every request the agent makes through the MCP server gets logged, so you can trace which agent action caused it. And the skills have been tested as full end-to-end workflows before shipping, so when your agent follows a skill's steps, those steps are verified to produce the expected result.

Thanks for reading!

If you made it this far, thanks for spending the time. Let me know if you've tried Agent Toolkit for AWS and what you think!

Lambda Just Got a File System. I Put AI Agents on It.

Eric D Johnson — Wed, 13 May 2026 15:50:28 +0000

You've written this code before. An S3 event fires, your Lambda function wakes up, and the first thing it does is download a file to /tmp. Process it. Upload the result. Clean up /tmp so you don't run out of space. Repeat for every file, every invocation, every function in your pipeline.

S3 Files changes that. You mount your S3 bucket as a local file system, and your Lambda code just uses open(). I built a set of AI code review agents that share a workspace through a mounted S3 bucket, orchestrated by a durable function, and the file access code is the most boring part of the whole project. That's the point.

The /tmp Tax

If you've built anything on Lambda that touches S3 data, you know the pattern. You need a file. S3 doesn't give you files. It gives you objects. So you download the object to /tmp, do your work, and upload the result back.

# The old way: every Lambda developer has written this
import boto3

s3 = boto3.client("s3")

def lambda_handler(event, context):
    bucket = event["bucket"]
    key = event["key"]

    # Download to /tmp
    local_path = f"/tmp/{key.split('/')[-1]}"
    s3.download_file(bucket, key, local_path)

    # Do your actual work
    with open(local_path) as f:
        content = f.read()
    result = process(content)

    # Upload the result
    s3.put_object(Bucket=bucket, Key=f"output/{key}", Body=result)

    # Clean up so you don't fill /tmp
    os.remove(local_path)

That's a lot of ceremony for "read a file and write a file." And it gets worse when you have multiple functions that need to work with the same data. Each one downloads its own copy. Each one manages its own /tmp. If you're processing a large repo or a dataset, you're burning through the 10GB /tmp limit fast.

I'd be doing you a disservice if I didn't mention the libraries that make this less painful. Tools like s3fs and smart_open abstract some of this away. But they're still making API calls under the hood. Your code is still talking to S3 through an SDK, not through a file system.

S3 Files for Lambda

S3 Files is a new feature that mounts your S3 bucket as a local file system on your Lambda function. Your code reads and writes files at a mount path like /mnt/workspace, and S3 Files handles the synchronization back to the bucket. Changes you write show up in S3 within minutes. Changes made to S3 objects appear on the file system within seconds.

# The new way: just file paths
from pathlib import Path

WORKSPACE = Path("/mnt/workspace")

def lambda_handler(event, context):
    # Read directly from the mount
    content = (WORKSPACE / "source" / "app.py").read_text()
    result = process(content)

    # Write directly to the mount
    (WORKSPACE / "output" / "result.json").write_text(result)

No boto3 for file access. No /tmp management. No upload step. The file system IS the interface.

Under the hood, S3 Files is built on Amazon EFS. It delivers sub-millisecond latency for actively used data by caching your working set on high-performance storage. For large sequential reads, it streams directly from S3. You get file system semantics with S3 durability and economics.

Here's the thing, though. S3 Files requires a VPC. Your Lambda function needs to be in the same VPC as the mount targets, and you need a NAT gateway for outbound internet access.

I'll be honest: as a serverless guy, I generally avoid VPCs. But AWS has removed most of the hurdles over the years. VPC-attached Lambda functions no longer have the cold start penalty they used to. The networking setup is boilerplate you write once. And for what S3 Files gives you, the tradeoff is worth it. Get yourself a reusable network template and move on.

What We're Building

I wanted to test S3 Files with something more interesting than "read a CSV." So I built a serverless code review system. You point it at a public GitHub repo, and three things happen:

A durable orchestrator function clones the repo to a shared S3 Files workspace
A security review agent and a style review agent analyze the code in parallel
The results land in the same workspace as JSON files, synced back to S3

All three Lambda functions mount the same S3 bucket. The orchestrator writes files. The agents read them. No S3 keys passed between functions. No downloading to /tmp. The file system is the coordination layer.

The agents use the Strands Agents SDK with Amazon Bedrock. Each agent gets custom file tools that operate on the mount path, and Claude decides which files to read, what to analyze, and what to write. The orchestrator uses Lambda durable functions to coordinate the workflow with automatic checkpointing.

The full source is on GitHub: singledigit/lambda-s3-files-example

The SAM Template

The IaC is the part that took the most iteration. S3 Files is brand new, and the CloudFormation resource types aren't in the linter yet. Here's what I learned.

The Resource Chain

You need five resources to get S3 Files working with Lambda:

S3 Bucket with versioning enabled (required)
IAM Role for S3 Files to access the bucket
S3 Files FileSystem that bridges the bucket to NFS
Mount Targets in each AZ (network endpoints)
Access Point that controls POSIX identity for Lambda

The resource types are AWS::S3Files::FileSystem, AWS::S3Files::MountTarget, and AWS::S3Files::AccessPoint. Your IDE's CloudFormation linter won't recognize them yet. Ignore the red squiggles.

The IAM Role Gotcha

The S3 Files IAM role trusts elasticfilesystem.amazonaws.com, not s3files.amazonaws.com. This tripped me up. S3 Files is built on EFS, so the trust relationship goes through the EFS service principal.

S3FilesRole:
  Type: AWS::IAM::Role
  Properties:
    Path: /service-role/
    AssumeRolePolicyDocument:
      Version: '2012-10-17'
      Statement:
        - Sid: AllowS3FilesAssumeRole
          Effect: Allow
          Principal:
            Service: elasticfilesystem.amazonaws.com
          Action: sts:AssumeRole
          Condition:
            StringEquals:
              aws:SourceAccount: !Ref AWS::AccountId
            ArnLike:
              aws:SourceArn: !Sub 'arn:aws:s3files:${AWS::Region}:${AWS::AccountId}:file-system/*'

The role needs S3 permissions to read and write the bucket. Scope it to your specific bucket ARN with aws:ResourceAccount conditions.

The Access Point

This is the important part for Lambda. The access point controls the POSIX identity your function runs as and creates a writable root directory. Without it, Lambda can mount the file system but can't write to it.

S3FilesAccessPoint:
  Type: AWS::S3Files::AccessPoint
  Properties:
    FileSystemId: !GetAtt S3FileSystem.FileSystemId
    PosixUser:
      Uid: '1000'
      Gid: '1000'
    RootDirectory:
      Path: /lambda
      CreationPermissions:
        OwnerUid: '1000'
        OwnerGid: '1000'
        Permissions: '755'

The CreationPermissions property is crucial. It auto-creates the /lambda directory with the right ownership when a client first connects. Without it, the root directory is owned by root (UID 0), and Lambda (running as UID 1000 through the access point) can't create subdirectories.

Lambda Configuration

On the Lambda side, FileSystemConfigs takes the access point ARN (not the file system ARN) and a local mount path:

OrchestratorFunction:
  Type: AWS::Serverless::Function
  DependsOn:
    - MountTargetA
    - MountTargetB
  Properties:
    FileSystemConfigs:
      - Arn: !GetAtt S3FilesAccessPoint.AccessPointArn
        LocalMountPath: /mnt/workspace
    VpcConfig:
      SecurityGroupIds:
        - !GetAtt NetworkingStack.Outputs.LambdaSGId
      SubnetIds:
        - !GetAtt NetworkingStack.Outputs.PrivateSubnetAId
        - !GetAtt NetworkingStack.Outputs.PrivateSubnetBId

The DependsOn on the mount targets is important. Lambda can't mount the file system until the mount targets are available, and they take about five minutes to create.

What I'd Do Differently

S3 Files is genuinely good for this use case. Shared file access between Lambda functions without the ceremony of S3 API calls. But a few things to know:

Consistency model matters. S3 Files provides close-to-open consistency. If Function A writes a file and Function B reads it immediately, B might not see the latest version. For my use case, the orchestrator writes first and the agents run after, so ordering is natural. If you need real-time coordination between concurrent writers, you'll want a different pattern.

VPC adds complexity. Not much, but some. You need subnets, security groups, NAT gateway for internet access. Template it once and reuse it.

Cold starts are fine. VPC-attached Lambda functions used to add 10+ seconds of cold start. That's been fixed for years. My functions cold-start in under 2 seconds with the file system mount.

The full code is at github.com/singledigit/lambda-s3-files-example. Clone it, deploy it, point it at a repo. The agents will tell you what they think.

Built-in Token Counting: Telemetry for Production AI Agents

Elizabeth Fuentes L — Wed, 13 May 2026 07:00:00 +0000

Strands Agents provides native telemetry and cost tracking out of the box. Stop writing custom token counters.

Building AI agents is easy. Deploying them to production is where most teams hit a wall.

One of the first questions from finance: "How much will this cost per request?"

Most agent frameworks make you build your own token counter. Strands Agents gives you one.

The Problem with Custom Token Counting

Every AI application needs cost monitoring. But tracking tokens across:

Multiple model calls
Tool invocations
Prompt caching
Multi-agent workflows

...requires custom infrastructure most teams rebuild from scratch.

Native Telemetry in Strands Agents

Strands Agents includes production-grade telemetry by default:

from strands import Agent
from strands_tools import calculator

# Create an agent with tools
agent = Agent(tools=[calculator])

# Invoke the agent with a prompt and get an AgentResult
result = agent("What is the square root of 144?")

# Access metrics through the AgentResult
print(f"Total tokens: {result.metrics.accumulated_usage['totalTokens']}")
print(f"Execution time: {sum(result.metrics.cycle_durations):.2f} seconds")
print(f"Tools used: {list(result.metrics.tool_metrics.keys())}")

# Cache metrics (when available)
if 'cacheReadInputTokens' in result.metrics.accumulated_usage:
    print(f"Cache read tokens: {result.metrics.accumulated_usage['cacheReadInputTokens']}")
if 'cacheWriteInputTokens' in result.metrics.accumulated_usage:
    print(f"Cache write tokens: {result.metrics.accumulated_usage['cacheWriteInputTokens']}")

No configuration. No custom code. It just works.

What You Get

Every AgentResult includes:

Metric	Description
`inputTokens`	Tokens sent to the model
`outputTokens`	Tokens generated by the model
`totalTokens`	Total cost (input + output)
`cacheReadInputTokens`	Tokens read from cache (Bedrock prompt caching)
`cacheWriteInputTokens`	Tokens written to cache

Multi-Agent Token Tracking

For multi-agent systems (executor → validator → critic), aggregate metrics across all agents:

from strands.multiagent import Swarm

swarm = Swarm([executor, validator, critic])
result = swarm("Query")

total_tokens = 0
for node_result in result.results.values():
    usage = node_result.result.metrics.accumulated_usage
    total_tokens += usage['totalTokens']

print(f"Total cost across all agents: {total_tokens} tokens")

Per-Cycle Tracking

For agents that run multiple reasoning cycles, track tokens per cycle:

from strands import Agent
from strands_tools import calculator

agent = Agent(tools=[calculator])

# First invocation
result1 = agent("What is 5 + 3?")

# Second invocation
result2 = agent("What is the square root of 144?")

# Access metrics for the latest invocation
latest_invocation = result2.metrics.latest_agent_invocation
cycles = latest_invocation.cycles
usage = latest_invocation.usage

# Or access all invocations
for invocation in response.metrics.agent_invocations:
    print(f"Invocation usage: {invocation.usage}")
    for cycle in invocation.cycles:
        print(f"  Cycle {cycle.event_loop_cycle_id}: {cycle.usage}")

# Or print the summary (includes all invocations)
print(result2.metrics.get_summary())

For a complete list of attributes and their types, see the EventLoopMetrics API reference.

Why This Matters

Cost visibility is the difference between a prototype and production AI.

With Strands telemetry:

✅ Budget AI workloads before deployment
✅ Identify expensive queries in production
✅ Optimize prompts with real token data
✅ Track prompt caching savings

All without writing a single line of telemetry code.

Works with All Model Providers

Token tracking works regardless of your model provider:

Amazon Bedrock (Claude, Llama, Mistral)
OpenAI (GPT-4, GPT-3.5)
Anthropic API
Ollama (local models)

Same API, same metrics, zero config changes.

Try It

pip install strands-agents

Full documentation: strandsagents.com/docs/user-guide/concepts/agents/

Gracias!

🇻🇪🇨🇱 Dev.to Linkedin GitHub Twitter Instagram Youtube

Elizabeth Fuentes LFollow

I help developers build production-ready AI applications through hands-on tutorials and open-source projects.

S3 Account Regional Namespaces with CDK

Sean Boult — Tue, 12 May 2026 19:07:20 +0000

So you learned about the new S3 bucket account regional namespace feature and you're thinking "this is amazing, let me try in CDK."

Well... This is where you'll learn that the L2 Bucket construct has not yet been updated to allow for this.

Currently there are the following items which are tracking the long term fix.

You should give both of these a 👍 to help them get prioritized and shipped.

Workaround

Good news there is a workaround! By using the L1 construct as an escape hatch we can then pass in bucketNamePrefix and bucketNamespace.

import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as s3 from 'aws-cdk-lib/aws-s3';

export class Cdk101Stack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // WORKAROUND: use the L1 bucket construct
    new s3.CfnBucket(this, "ConfigBucket", {
      bucketNamePrefix: "config",
      bucketNamespace: "account-regional",
    });
  }
}

After deploying this you'll see your new bucket with {name}-{account}-{region}-an (the an suffix indicates account namespace).

That will work if you only need to deploy the bucket. But if you need an L2 reference (IBucket), use s3.Bucket.fromCfnBucket to convert it.

Full code demo:

import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as s3 from 'aws-cdk-lib/aws-s3';
import * as s3deploy from 'aws-cdk-lib/aws-s3-deployment';
import * as path from 'path';

export class Cdk101Stack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // NOTE: workaround for the following CDK issues
    // https://github.com/aws/aws-cdk/issues/37760
    // https://github.com/aws/aws-cdk/pull/37386
    const cfnBucket = new s3.CfnBucket(this, "ConfigBucket", {
      bucketNamePrefix: "config",
      bucketNamespace: "account-regional",
    });

    const bucket = s3.Bucket.fromCfnBucket(cfnBucket);

    // Upload a config file to the bucket on deploy
    new s3deploy.BucketDeployment(this, 'DeployConfig', {
      sources: [s3deploy.Source.asset(path.join(__dirname, '../config'))],
      destinationBucket: bucket,
    });

  }
}

Hope this blog helped you get a workaround for now and once aws-cdk-lib is patched I'll update this blog.

Happy coding 😃!

Follow AWS for more articles like this

AWS Follow

Articles written by current and past AWS Developer Advocates to help people interested in building on AWS. Opinions are each author's own.

Prompt AI Coding Assistants to Build Production-Ready Agents: 8 Essential Patterns

Elizabeth Fuentes L — Mon, 11 May 2026 07:00:00 +0000

When you ask an AI assistant like Kiro (AWS's AI coding assistant), Claude Code, or ChatGPT to "build me an agent," you get working code. But you don't see the architecture decisions happening behind the scenes. The agent responds to queries, but it might waste tokens in reasoning loops, hallucinate answers from incomplete data, or freeze on slow APIs. These failures are silent until production.

When you prompt AI coding assistants to build agents, they make architecture decisions silently—choosing retrieval strategies, validation approaches, and error handling patterns. These 8 patterns give you the vocabulary to specify production-grade decisions in your prompts, preventing hallucinations and token waste before code is generated.

This post closes two series I wrote documenting the most expensive agent failures in production: Stop AI Agent Hallucinations (5 techniques) and Why AI Agents Fail (3 failure modes). If you know these 8 patterns, you can guide AI assistants to avoid them from the start.

This isn't a step-by-step implementation guide. It's a reference for knowing what exists so you can recognize when to use each pattern based on your use case.

Working code for all 8 techniques: Linked in each section

Why This Matters

AI coding assistants generate agent code in seconds. Kiro, Claude Code, Cursor, and ChatGPT can scaffold tools, configure LLM calls, and wire up retrieval systems faster than manual coding.

But speed creates a problem: you get working code without seeing the tradeoffs.

When you prompt "build a booking agent with RAG," the assistant makes decisions:

Which retrieval strategy? (vector similarity, graph queries, hybrid)
How to handle large outputs? (truncate, summarize, external storage)
What validation runs before tool execution? (none, prompts, framework hooks)
How to handle slow APIs? (block, timeout, async patterns)

Your prompt doesn't specify these. The assistant picks defaults. Those defaults create the failure modes this post documents.

The 8 Failure Patterns

Hallucination Failures (5 patterns):

GraphRAG - Vector RAG fabricates statistics from incomplete chunks
Semantic Tool Selection - Too many tools, agent picks wrong ones
Neurosymbolic Guardrails - Agent ignores business rules in prompts
Runtime Guardrails (Steering) - Agent violates rules, needs correction not blocking
Multi-Agent Validation - Single agent claims success when operations fail

Silent Token Waste (3 patterns):

Memory Pointer Pattern - Large data overflows context, causes truncation
Async HandleId Pattern - Slow APIs block agent indefinitely
DebounceHook + Explicit States - Agent loops same tool call without progress

You don't implement all 8. You learn what they solve, then specify the ones your use case needs when prompting.

What Are These 8 Patterns?

These patterns solve the most expensive production failures: hallucinations from incomplete data (GraphRAG, Semantic Tool Selection, Guardrails, Steering, Multi-Agent), and silent token waste (Memory Pointers, Async HandleId, DebounceHook). You learn what each solves, then specify the ones your use case needs when prompting AI assistants. This prevents debugging black-box code in production.

Measured Impact from Production

Pattern	Result	Source
GraphRAG	Exact counts vs fabricated approximations	RAG vs GraphRAG
Semantic Tool Selection	86.4% fewer errors, 89% lower token costs	Tool Selection
Memory Pointers	20M tokens reduced to 1,234 tokens	IBM Materials Science study
Async HandleId	18-second block eliminated, no 424 timeouts	MCP Timeouts
Explicit States	14 calls reduced to 2 (7x improvement)	Reasoning Loops

Pattern 1: GraphRAG for Precise Queries

What Is GraphRAG?

GraphRAG replaces vector similarity with graph database queries for structured data. When your agent needs exact counts, aggregations, or relationship traversal, GraphRAG translates natural language to Cypher queries that return precise results from structured data instead of hallucinated statistics from incomplete text chunks. Use it for structured queries, keep vector RAG for semantic search.

What Breaks

Vector RAG fabricates statistics. Ask "How many hotels in Miami have pools and breakfast?" and vector similarity retrieves 3 text chunks mentioning Miami, pools and breakfast. The LLM sees incomplete data, calculates from samples, and returns "approximately 120 hotels" (fabricated from 3 chunks out of 200 hotels).

Out-of-domain queries return hallucinated answers instead of admitting no data exists.

The Fix

Replace vector retrieval with graph queries for structured data. Store hotels, amenities, and relationships in Neo4j. The LLM translates "hotels with pools and breakfast" into Cypher:

MATCH (h:Hotel)-[:HAS_AMENITY]->(a:Amenity)
WHERE a.name IN ['pool', 'breakfast']
RETURN count(DISTINCT h)

Result: 133 hotels (exact count from database).

Out-of-domain query: "No hotels found in Antarctica" instead of fabricating results.

What to Tell Your AI Assistant

"Build a travel agent using GraphRAG. For structured 
queries (hotels, amenities, availability), translate to Cypher 
and execute against the graph. Only use vector RAG for unstructured descriptions. Return exact counts from graph traversal."

When to Use

Structured data with relationships (products, inventory, locations)
Queries requiring counts, aggregations, or multi-hop traversal
Domains where fabricating statistics creates legal/financial risk

Full details: RAG vs GraphRAG: When Agents Hallucinate Answers

Learn more: Neo4j Cypher Documentation

Pattern 2: Semantic Tool Selection

What Is Semantic Tool Selection?

Semantic tool selection uses vector embeddings to filter tools before the LLM sees them. When your agent has 10+ tools, sending all descriptions on every call increases error rates (agent picks wrong tools) and token costs (paying for unused descriptions). Semantic filtering embeds tool descriptions offline, then at runtime matches the query to top-5 relevant tools, reducing errors by 86.4% and costs by 89%.

What Breaks

With 50 tools, two failures occur: (1) agent picks wrong tools because descriptions overlap, and (2) token costs explode from sending all 50 tool descriptions on every LLM call.

Measured impact: Error rates increase with tool count, token costs scale linearly.

The Fix

Use vector embeddings to filter tools before the LLM sees them. Embed tool descriptions offline. At runtime, embed the user query, compute similarity, pass only top-5 relevant tools to the agent.

Results from production:

Errors reduced: 86.4%
Token costs reduced: 89%
Latency: <10ms for tool filtering

What to Tell Your AI Assistant

"Build a multi-tool agent with semantic tool selection At 
runtime, embed the query, retrieve top-5 similar tools, pass only 
those to the agent. Keep conversation memory, dynamically swap tools."

When to Use

Agents with 10+ tools
Tools with overlapping descriptions
Cost-sensitive applications

Full details: Reduce Agent Errors and Token Costs with Semantic Tool Selection

Pattern 3: Neurosymbolic Guardrails (Block)

What Are Neurosymbolic Guardrails?

Neurosymbolic guardrails enforce business rules at the framework level, below the LLM's control. When prompts alone cannot enforce constraints (max guests, valid dates, budget limits), guardrails use pre-execution hooks to validate parameters and cancel invalid operations. Rules live in code, not prompts, so the LLM cannot bypass them. Use blocking guardrails for hard constraints that cannot be violated.

What Breaks

Prompts cannot enforce business rules. Even with clear docstrings ("max_guests must be ≤10"), the LLM passes max_guests=15 under pressure because prompts are suggestions, not constraints. The agent violates rules silently.

The Fix

Use framework hooks to validate parameters before tool execution. If validation fails, cancel the tool call and return corrective guidance. Rules live in code at the framework level, below the LLM's control.

Measured impact: Zero violations in 100-query test (vs. 12 violations with prompts alone).

What to Tell Your AI Assistant

"Build a booking agent with guardrails using Strands Agents hooks. 
Create a BeforeToolCallEvent hook that validates:
- max_guests ≤ 10
- check_in_date > today
- budget > 0

If validation fails, cancel the tool call with event.cancel_tool() 
and return error message. Do not rely on prompts for validation."

When to Use

Business rules that cannot be violated (compliance, legal, financial)
Validation requiring computation (date math, inventory checks)
Rules that change frequently

Full details: AI Agent Guardrails: Rules That LLMs Cannot Bypass

Pattern 4: Runtime Guardrails (Steer, Don't Block)

What Is Steering vs Blocking?

Steering guardrails return corrective guidance instead of blocking operations. When the agent violates a soft rule (format issues, parameter adjustments, data redaction), steering returns instructions via Guide() so the agent self-corrects and retries. This differs from blocking guardrails (Pattern 3) which stop workflows entirely. Use steering for rules where the agent can fix itself, blocking for hard constraints.

What Breaks

Hard guardrails (Pattern 3) block operations and stop workflows. For soft rules where the agent can self-correct (format issues, parameter adjustments, redacting sensitive data), blocking creates friction. The agent could fix the problem itself if given guidance.

The Fix

Use Agent Control to return corrective guidance via Guide() instead of blocking. When the agent violates a soft rule, the control plane returns instructions: "Adjust parameter X to Y and retry." The agent self-corrects and completes the task without human intervention.

Difference from Pattern 3:

Block (Pattern 3): Hard constraints, workflow stops
Steer (Pattern 4): Soft rules, agent self-corrects

What to Tell Your AI Assistant

"Build a booking agent with Agent Control for soft rules. Connect 
to Agent Control server. For soft rules (parameter formatting, 
date adjustments, data redaction), return Guide() with correction 
instructions instead of blocking. Agent should retry with fix applied.

Use hard blocks (Pattern 3) only for compliance rules that cannot 
be violated under any circumstance."

When to Use

Rules where agent can self-correct (format, adjust parameters)
Workflows where blocking creates poor UX
Rules managed centrally via API/dashboard (update without redeploying)

Full details: Runtime Guardrails for AI Agents: Steer, Don't Block

Pattern 5: Multi-Agent Validation

What Is Multi-Agent Validation?

Multi-agent validation deploys specialized agents with different roles (Executor, Validator, Critic) that cross-check each other's work. Single agents optimize for appearing successful, not verifying outcomes. Multiple agents with different optimization functions catch errors the others miss. Executor performs tasks, Validator cross-checks against ground truth, Critic provides final review before returning to the user.

What Breaks

Single agents cannot self-validate. When an agent books a hotel, it claims "Success: Booked Grand Plaza Hotel" even if the API returned an error or the hotel doesn't exist in the database. The agent optimizes for appearing successful, not verifying outcomes.

The Fix

Deploy multiple agents with different roles: Executor performs tasks, Validator cross-checks against ground truth, Critic provides final review. Agents share context and hand off control autonomously when their role completes.

Measured impact: Multi-agent catches errors single agent misses (e.g., booking non-existent hotels).

What to Tell Your AI Assistant

"Build a multi-agent system using Strands Swarm with 3 agents:
1. Executor: Books hotels, searches flights
2. Validator: Cross-checks operations against database
3. Critic: Final review before returning to user

Agents share context via swarm.context. Use autonomous handoffs. 
Agents decide when to hand off based on task completion."

When to Use

High-stakes operations (financial, medical, legal)
Tasks where "appears successful" differs from "actually successful"
Complex workflows with multiple verification points

Full details: How to Stop AI Agents from Hallucinating Silently with Multi-Agent Validation

Pattern 6: Memory Pointer Pattern

What Is the Memory Pointer Pattern?

The Memory Pointer Pattern stores large data outside the LLM context and passes short references instead. When tools return 200KB+ logs or 1000-row database results, passing them directly causes silent truncation. Memory pointers store data in agent.state, return a pointer to the LLM, and provide separate tools that resolve pointers to access full data. IBM reduced 20M tokens to 1,234 tokens using this pattern.

What Breaks

Context window overflow occurs when tools return more data than the LLM can process (200KB+ logs, 1000-row database results). The agent doesn't crash. It silently truncates data, loses context, produces incomplete answers.

Real production case (IBM Materials Science):

Before: 20 million tokens, workflow failed
After: 1,234 tokens, workflow succeeded

The Fix

Store large data in agent.state, pass short references to the LLM. Tools return pointers like "logs-app-server". Subsequent tools resolve pointers to access full data. LLM only sees: "Data stored as logs-app-server. Use analyze_errors(pointer)."

Data in context reduced: 214KB → 52 bytes

What to Tell Your AI Assistant

"Build a log analysis agent using Memory Pointer Pattern. When 
fetch_logs returns >20KB:
1. Store in agent.state with unique pointer ID
2. Return to LLM: 'Data stored as logs-{app}. Use analyze_logs(pointer).'
3. Implement analyze_logs(pointer) that resolves from agent.state

Never pass large data directly to LLM context."

When to Use

Tools returning large outputs (logs, database queries, files)
Workflows with multiple processing steps on same large data
Cost-sensitive applications

Full details: AI Context Window Overflow: Memory Pointer Fix

Pattern 7: Async HandleId Pattern

What Is the Async HandleId Pattern?

The async handleId pattern prevents slow external APIs from blocking your agent. When an API takes 30+ seconds, synchronous calls freeze the entire agent. Async handleId returns a job ID immediately, letting the agent continue with other tasks. A separate check_status tool polls for results when ready. This eliminates 424 timeout errors and keeps agents responsive.

What Breaks

External APIs that take 30+ seconds block the agent indefinitely. No other tools can run. After ~7 seconds, many implementations return 424 timeout errors, freezing the workflow.

The Fix

Tools return immediately with a job ID instead of waiting. Agent stores handleId and continues. Separate check_status(job_id) tool polls for results asynchronously.

Measured impact:

Before: 18-second API blocks agent, 424 timeout
After: Tool returns <1 second, agent polls when ready

What to Tell Your AI Assistant

"Build an agent with async handleId pattern for slow APIs:

1. start_analysis(data): Submit job, return job_id immediately
2. check_status(job_id): Poll for results

Agent calls start_analysis, stores job_id, continues with other 
tasks, calls check_status when ready. Do not implement blocking calls."

When to Use

External APIs with >5 second response times
Batch processing (video analysis, large transforms)
Any system outside your control

Full details: Fix MCP Timeouts: Async HandleId Pattern

Pattern 8: DebounceHook + Explicit States

What Prevents Reasoning Loops?

Reasoning loops occur when ambiguous tool feedback ("more may be available") signals that retrying might help. Two fixes work together: explicit terminal states (return SUCCESS/FAILED so the LLM knows when to stop) and DebounceHook (framework hook that blocks duplicate calls). Production tests showed explicit states reduced calls from 14 to 2, while DebounceHook provides a safety net for edge cases.

What Breaks

Agents loop calling the same tool repeatedly without progress. Ambiguous feedback like "Found 3 results. More may be available" signals that retrying might help. The agent loops indefinitely.

Real production case: 847 reasoning steps at $47/minute, no answer delivered.

The Fix (Two Parts)

Part A: Explicit Terminal States

Return clear SUCCESS or FAILED states. Change "More may be available" to "SUCCESS: Found all 3 matching flights."

Part B: DebounceHook Safety Net

Framework hook tracks recent tool calls. When same (tool_name, input) appears twice, block third attempt.

Measured impact (travel booking demo):

Ambiguous feedback: 14 calls
Explicit SUCCESS: 2 calls (7x reduction)
DebounceHook: 12 calls (2 blocked)

What to Tell Your AI Assistant

"Build a travel agent with anti-loop protection:

1. All tools return explicit states:
   - SUCCESS: [clear completion]
   - FAILED: [clear error]
   Never return 'more may be available'

2. Implement DebounceHook:
   - Track last 3 tool calls as (tool_name, input)
   - If same pair appears twice, block third attempt
   - Return 'BLOCKED: Duplicate detected'

This prevents loops without manual retry limits."

When to Use

Agents prone to retry loops (search, API aggregators)
Cost-sensitive applications where unbounded retries are expensive
Production systems where infinite loops create availability risk

Full details: How to Prevent AI Agent Reasoning Loops from Wasting Tokens

Example: Generic vs Informed Prompting

❌ Generic Prompt

"Build a customer support agent that searches our knowledge base 
and books appointments"

What you get:

Vector RAG (may hallucinate on structured queries)
Synchronous booking API (may timeout)
No validation (can book invalid times)
Single agent (claims success even when booking fails)

Result: Works in demo, fails in production.

✅ Informed Prompt

"Build a customer support agent:

Knowledge Base:
- Use Neo4j GraphRAG for structured queries (pricing, features)
- Use vector RAG only for semantic search (descriptions)

Booking:
- Validate appointment_time > now() before booking
- Use async handleId for booking API (10+ seconds)
- Return explicit states: SUCCESS / FAILED

Validation:
- Multi-agent: Executor (search/book), Validator (cross-check), 
  Critic (final review)
- Use Strands Swarm for autonomous handoffs

Loop Prevention:
- DebounceHook blocks duplicate calls
- All tools return terminal states"

What you get:

GraphRAG prevents hallucinations
Async prevents timeouts
Guardrails prevent invalid bookings
Multi-agent catches false successes
DebounceHook prevents loops

Result: Production-ready agent.

Common Mistakes

Mistake 1: Assuming Defaults Are Best Practices

Problem: "Build a production agent" assumes the assistant knows what production means.

Fix: Specify patterns: "Use GraphRAG, guardrails, async patterns."

Mistake 2: Relying Only on Prompts for Validation

Problem: "Make sure max_guests < 10" in system prompt gets ignored under pressure.

Fix: "Implement BeforeToolCallEvent hook that validates and cancels invalid calls."

Mistake 3: Not Recognizing When Patterns Apply

Problem: Agent works in demo, breaks on edge cases.

Fix: Know the 8 patterns. When you see hallucinations, timeouts, or loops, you'll recognize which pattern solves it.

My Thoughts

AI coding assistants will keep improving at generating working code. But working code and production-ready architecture remain different targets.

The gap isn't the assistant's capability. It's the prompt's specificity.

Next Steps

If You're Building a New Agent

Identify which patterns apply (use symptom checklist)
Specify patterns in your prompt
Verify generated code implements them
Test failure modes (timeouts, invalid inputs, non-existent data)

If You're Debugging an Existing Agent

Identify the symptom (hallucinations, loops, timeouts, rule violations)
Map symptom to pattern (see Step 1: Recognize the Symptom)
Prompt your assistant to add the pattern: "Add DebounceHook to prevent loops"
Verify fix with targeted tests

Learn More (Full Implementation Guides)

Each pattern has a complete guide with working code:

GraphRAG: RAG vs GraphRAG: When Agents Hallucinate Answers
Semantic Tool Selection: Reduce Agent Errors and Token Costs
Neurosymbolic Guardrails: AI Agent Guardrails: Rules That LLMs Cannot Bypass
Runtime Guardrails (Steering): Runtime Guardrails for AI Agents: Steer, Don't Block
Multi-Agent Validation: Stop AI Agents from Hallucinating Silently
Memory Pointers: AI Context Window Overflow: Memory Pointer Fix
Async HandleId: Fix MCP Timeouts: Async HandleId Pattern
DebounceHook: Prevent AI Agent Reasoning Loops

Complete series:

Gracias!

🇻🇪🇨🇱 Dev.to Linkedin GitHub Twitter Instagram Youtube

Elizabeth Fuentes LFollow

I help developers build production-ready AI applications through hands-on tutorials and open-source projects.

Estructuras de datos: ¿Qué son los Stacks (LIFO)?

Axel Espinosa — Fri, 08 May 2026 21:22:09 +0000

¿Alguna vez te has preguntado qué pasa cuando presionas el botón "atrás" en tu navegador? ¿O cómo Ctrl + Z sabe exactamente qué acción deshacer? Detrás de esas funciones hay una estructura de datos que llevas años usando sin darte cuenta: el stack.

En los artículos anteriores vimos los arrays y los strings. Hoy toca hablar de la siguiente pieza: los stacks. Si los arrays son el almacén general, el stack es una pila de platos. Ya lo vas a ver.

Lo que encontrarás en este artículo:

Qué es un stack y qué significa LIFO

Las operaciones básicas: push, pop, peek, size, isEmpty

Cómo implementar tu propio stack en JavaScript

La complejidad Big O de cada operación

Dónde se usan los stacks en la vida real

¿Qué es un stack?

Un stack (o pila) es una estructura de datos que sigue el principio LIFO: Last In, First Out. En español: el último que entra es el primero que sale.

Imagina una pila de libros sobre tu escritorio. Vas apilándolos uno sobre otro. Cuando quieres leer uno, ¿por cuál empiezas? Por el de arriba, no por el de abajo. El último libro que pusiste es el primero que vas a tomar.

Esa es la esencia de un stack. No puedes sacar un elemento del medio o del fondo. Solo trabajas con el que está hasta arriba.

Pero aquí viene el detalle interesante: aunque suene restrictivo, esta limitación es justo lo que hace al stack útil. Cuando solo te importa el último elemento agregado, un stack es la herramienta perfecta.

Operaciones básicas de un stack

Un stack tiene cinco operaciones fundamentales. Estas son las que aparecen en el ADT (Abstract Data Type) de un stack:

push(item): agrega un elemento a la parte superior
pop(): elimina el elemento de arriba y lo devuelve
peek(): mira el elemento de arriba sin eliminarlo
size(): devuelve cuántos elementos hay en el stack
isEmpty(): dice si el stack está vacío o no

Las dos estrellas son push y pop. Con ellas agregas y quitas elementos, siempre desde la misma puerta: la de arriba.

Fíjate en cómo pop() siempre saca el último que entró. En el paso 3 agregamos 🐱, y en el paso 4 pop() nos devuelve 🐱. Si hubiéramos hecho pop() otra vez, nos devolvería 🐶.

Cómo implementar un stack en JavaScript

Dato curioso antes de empezar: los arrays en JavaScript ya se comportan como un stack. Si haces miArray.push(x) y miArray.pop(), estás trabajando como si fuera un stack..

Pero un array te deja hacer cosas que un stack no debería permitir: acceder por cualquier índice, unshift, splice, lo que quieras. Y esa libertad de más es justo lo que queremos esconder.

Así que vamos a implementarlo desde cero. Sin usar .push() ni .pop() del array. Solo lo vamos a usar como almacenamiento indexado y el control lo lleva nosotros. Así se ve qué pasa por debajo.

class Stack {
  constructor() {
    this.items = [];
    this.count = 0; // posición donde iría el próximo elemento
  }

  push(item) {
    this.items[this.count] = item;
    this.count++;
  }

  pop() {
    if (this.isEmpty()) {
      throw new Error("El stack está vacío");
    }
    this.count--;
    const item = this.items[this.count];
    this.items.length = this.count; // recortamos el array
    return item;
  }

  peek() {
    if (this.isEmpty()) {
      throw new Error("El stack está vacío");
    }
    return this.items[this.count - 1];
  }

  size() {
    return this.count;
  }

  isEmpty() {
    return this.count === 0;
  }
}

Probemos cómo se usa:

const miStack = new Stack();

miStack.push("🐶");
miStack.push("🐱");
miStack.push("👻");

console.log(miStack.size()); // 3
console.log(miStack.peek()); // "👻" (solo mira, no elimina)
console.log(miStack.pop()); // "👻" (lo elimina y devuelve)
console.log(miStack.size()); // 2
console.log(miStack.isEmpty()); // false

Así se ve el stack en cada paso:

Puedes probar este código en RunJS o verlo paso a paso en PythonTutor, que también soporta JavaScript.

Vamos a desarmar lo que está pasando:

count lleva la cuenta de cuántos elementos hay. También indica la siguiente posición libre del array. Recuerda que los arrays empiezan en el índice 0, así que cuando el stack está vacío count vale 0 y ese es justo el lugar donde va a caer el primer elemento.
push() coloca el nuevo elemento en la posición count y luego incrementa el contador.
pop() hace lo contrario: decrementa count primero (ahora apunta al último elemento), lee ese valor y recorta el array.
peek() lee la posición count - 1 (el último elemento) sin mover nada.

Por ejemplo, si hacemos push("🐶"), push("🐱"), push("👻"), el array queda así:

Cuando hacemos pop(), el contador baja de 3 a 2 y leemos items[2] que es 👻. Luego hacemos this.items.length = 2 para recortar el array, y listo.

Un truco de los arrays en JavaScript

Fíjate en esta línea: this.items.length = this.count. Podría parecer que solo estamos "cambiando un número", pero en realidad estamos modificando el array. En JavaScript, asignarle un valor menor a .length recorta el array y elimina los elementos que sobran.

Míralo por fuera de la clase:

const numbers = [1, 2, 3, 4, 5];

console.log(numbers.length); // 5

// Definir la longitud
numbers.length = 3;

console.log(numbers); // [1, 2, 3]
console.log(numbers.length); // 3
console.log(numbers[3]); // undefined (los elementos extra se eliminan)

Este es un detalle que muchos desarrolladores desconocen y te abre posibilidades interesantes. En nuestra clase lo usamos para asegurarnos de que el array y el contador count siempre estén sincronizados.

Si te fijas, no usamos los métodos push y pop del array nativo de JavaScript. Solo lo usamos como almacenamiento indexado. Todo el control lo lleva nuestra variable count.

Complejidad Big O de las operaciones

Ya vimos qué hace cada operación. Ahora, ¿cuánto cuestan? Aquí es donde entra Big O, la notación que nos dice cómo crece el tiempo de una operación conforme crece el stack.

Operación	Complejidad en tiempo	Complejidad en espacio
`push()`	O(1)*	O(1)
`pop()`	O(1)	O(1)
`peek()`	O(1)	O(1)
`size()`	O(1)	O(1)
`isEmpty()`	O(1)	O(1)

* Amortizado. Ocasionalmente O(n) cuando el array dinámico necesita crecer por debajo.

Todas las operaciones de un stack son O(1). ¿Por qué? Porque siempre trabajamos con un solo elemento: el de arriba. No importa si el stack tiene 10 o 10 millones de elementos, push y pop tardan lo mismo.

Compara esto con un array, donde insertar al inicio es O(n) porque hay que mover todos los elementos. En un stack no tenemos ese problema porque solo tocamos la punta.

Esta es la razón principal por la que los stacks se usan tanto: son rápidos y predecibles. Si tu problema solo necesita trabajar con el último elemento agregado, un stack te da esa operación en tiempo constante.

Eso sí, rápido no quiere decir infinito. Un stack vive en memoria, así que si crece demasiado va a depender por completo de los recursos del dispositivo donde corra. En celulares, tablets y computadoras con poca RAM esto importa más de lo que crees: un stack que crece sin control puede tronar la app. Los lenguajes hasta tienen un límite específico para el call stack, y si lo rebasas te topas con el famoso stack overflow.

¿Dónde se usan los stacks en la vida real?

Antes de ver ejemplos, quédate con esto:

Regla de oro: cuando lo único que te importa es el último elemento, un stack es la respuesta.

Todo lo que viene a continuación es una variante del mismo patrón. Una vez que lo ves, empiezas a reconocer stacks en todos lados.

Navegador web: botón de "atrás"

Cada vez que visitas una página nueva, el navegador hace push() con la URL. Cuando presionas "atrás", hace pop() y te lleva a la página anterior.

Funciona perfecto porque siempre quieres volver a la última página que visitaste, no a una del medio.

Ctrl + Z: deshacer acciones

Cuando escribes en un editor de texto, cada acción (escribir una letra, borrar, pegar) se agrega a un stack. Cuando presionas Ctrl + Z, la última acción se hace pop() y se deshace. Presionas Ctrl + Z otra vez y la penúltima se deshace.

Mismo patrón: siempre deshaces la acción más reciente.

Call stack de tu programa

Cuando una función llama a otra, que a su vez llama a otra, tu programa va apilando cada llamada en un "call stack". Cuando una función termina, se hace pop() y el control vuelve a la función anterior.

Por eso cuando ves un error con "stack trace" en la consola, estás viendo exactamente eso: el estado del stack de llamadas en el momento del error.

Validación de paréntesis balanceados

Un problema clásico de entrevistas. ¿Cómo verificas que en ((a + b) * (c - d)) todos los paréntesis estén correctamente balanceados? Con un stack. Cada ( hace push, cada ) hace pop. Si al final el stack está vacío, los paréntesis están balanceados.

Cierre

Los stacks son simples: cinco métodos, todos O(1), un solo principio (LIFO). Y justo por eso los encuentras en tantos lugares, desde el botón de atrás hasta el call stack de tu lenguaje de programación.

Si te sirvió el artículo, dale ❤️ y sígueme para no perderte el siguiente. Nos leemos pronto. 🙌🏻

Why does AI lie? Hallucinations explained simply

Rohini Gaonkar — Fri, 08 May 2026 16:37:02 +0000

In the previous post, I showed you an AI doing something genuinely useful, helping me adapt a recipe for a dinner party. We talked about the basic loop: send a prompt to a foundation model, get a response.

Today we're talking about why AI lies to you.

You know how AI sounds confident when it's completely wrong? It's called hallucination, and it's the thing that'll either make you trust AI long-term, or burn you badly.

The demo: same question, two models

I asked two different models the same question in Amazon Bedrock Playground:

"What happened at the recent Lyrids meteor shower?"

Model 1: Amazon Nova Micro 1.0

Nova Micro gave me details. Dates, locations, numbers, all delivered with complete confidence. It didn't hesitate. It didn't caveat. It just answered as if it knew.

But it doesn't know. Its training data ends in 2023. Anything after that is a gap it can't see. It didn't flag that. It just filled the gap with something plausible.

This is hallucination. The model invents something plausible to fill a gap it doesn't know how to admit. It's not lying on purpose. It's doing exactly what it's designed to do: predict what a useful-sounding answer looks like. It has no idea whether the answer is actually true.

Model 2: Claude Haiku 4.5

Same question, newer model, much more recent training.

Haiku told me straight: "I don't have access to current information. My knowledge was last updated in April 2024." Then it offered general facts about the Lyrids and suggested I check recent astronomy websites.

Progress. Newer models are better at recognising the edges of what they know.

I gave it a link to a Space.com article. It told me it can't browse the internet.

So I uploaded the PDF of that website article. There are limits to how big the file size can be so I provided it first few pages only. Then it answered accurately, pulling real details from the source.

So, in this case, we provided some context to the model and it gave me an answer based on that context.

The biography test

I asked Nova Micro:

"Tell me about Rohini Gaonkar."

It didn't hesitate. It told me I'm a "well-known Indian writer, scholar, and cultural critic." That I got my PhD in Comparative Literature from Duke. That I'm a professor at the University of Minnesota. That I've edited influential anthologies on postcolonial theory.

None of this is true. Not one detail.

The model doesn't know who I am. But it knows what an academic biography looks like. So it generated one. Complete with research interests, notable works, and recognition. All fabricated. All confident.

So Haiku knew when to stop. Nova Micro didn't.

But the underlying mechanism is the same in both models: prediction.

One has better guardrails. The other just fills every gap it finds.

Hallucination isn't just about training cutoffs. It's about the model filling gaps anywhere in what it knows. Names it hasn't seen. Niche topics. Combinations it was never taught. Better guardrails help. They don't make the problem disappear.

A note on the name test: I used my own name on purpose. If the model invents something weird about me, the only person affected is me. Be thoughtful if you try this with other people's names, especially private ones, or anyone who hasn't agreed to be part of your experiment. Whatever the model says about them, you've just generated and potentially broadcasted it. So, be cautious.

Why this happens: the architecture

Remember the loop from the last post:

Input (prompt) → Foundation Model → Output (response)

The model predicts what a useful answer looks like, based on everything it learned during training.

During training is the key phrase.

Training ends on a specific date, called the training cutoff. After that, the model is frozen. When you ask it about anything past that date, or anything it never quite learned, it has two options: say "I don't know", or do the thing it's designed to do i.e. predict.

And for a long time, these models weren't great at saying "I don't know". That's not what they were rewarded for in training. They were rewarded for producing fluent, useful-sounding answers. So that's what they produce. Even when the answer is made up.

Hallucination shows up in different flavors: fabricated facts (the biography), outdated information stated as current (the meteor shower), inconsistent reproduction even with the source right there (the quote test). There are others too, wrong attributions, sycophantic agreement (going along with something you said even when it's wrong), confident extrapolation (extending a pattern beyond where the data supports it).

The mechanism is always the same, prediction filling a gap, but knowing the flavor helps you design the right mitigation. We'll get into those mitigations in later posts when we talk about grounding, evaluation, and guardrails.

If you're a builder, this'll feel familiar. Think of a DNS cache. You move your app to a new server, update the DNS record, but for the next hour some users still get routed to the old IP. The cache doesn't know the record changed. It just serves what it has, confidently, because it was designed to always give you an answer fast.

Or autoscaling on the wrong metric. You scale on CPU. CPU is low, so the system thinks everything's fine. Meanwhile your queue is backed up with 10,000 unprocessed messages. The system is optimized to respond to one signal, so it confidently does nothing while things pile up.

An AI model works the same way. It was trained to always produce a helpful-sounding answer. So when it doesn't know something, it still produces a helpful-sounding answer. It doesn't have a "say nothing" instinct. It has a "say something useful-looking" instinct.

Modern models are much better at refusing. But the underlying shape of the problem doesn't go away. The model doesn't know what it knows. It just predicts.

"But ChatGPT can search the web?"

Yes, most chat tools today can look things up online. That's not the model itself doing the searching. It is a tool plugged into the model.

We'll get to how that works in a later post. For today, we're looking at the model on its own. No internet, no tools. Just what it learned.

The fix, and where the fix breaks

I gave Nova Lite the actual article as a PDF and asked it to quote the second paragraph.

It gave me a response. Then I asked the same thing again. Different answer. Same source, same conversation, two different versions of the same paragraph.

Even with the source right there, it didn't pull the paragraph verbatim. I asked the same question twice, same conversation, same document, and got two different versions. It's not retrieving. It's still predicting what that paragraph probably looks like. And prediction isn't deterministic.

This matters because a lot of people think "just give the AI the document and it'll be fine."

It's better but it's not perfect. Things can get complex and messy, especially for anything that depends on exact wording, like legal text, medical dosages, or contract clauses. You still need to verify the responses.

Context reduces hallucination. It doesn't eliminate it.

Three signs you should double-check

If you're using AI day-to-day, here are the tells:

1. Specific details you can't verify. Names, dates, numbers, URLs in an area you can't check. Assume 50/50.

2. Fluency on topics that should be fuzzy. Ask about something niche or recent, get a confident detailed answer, and be suspicious. Real expertise has hedges, hallucination doesn't.

3. Citations. Especially URLs. Models invent sources that look real. If you get a URL, open it. Nine times out of ten it's fine. The tenth time it's a made-up paper.

Try it yourself

If you're more on the builder side:
Remember, hallucinations aren't a bug you patch. They're a property of the system. You mitigate them with grounding (give the model real context), with instructions (tell the model to refuse when unsure), and later, with evaluation. Designing around them is the job.

If you're just getting started:
Remember, AI is NOT a search engine. It's a prediction engine that's really good at sounding right. Treat specific claims the way you'd treat a confident stranger at a party. Friendly, but verify before you repeat them.

Some examples I found on internet, for fun and educational purposes only: (Answers may change as models are catching up)

How many 'r's are in the word strawberry?
If I have to take my car to car wash, and the car wash is 100ft away. Should I drive or go walking?

What's next

Why are there so many of these things? Haiku, Sonnet, Opus. Mini, large, pro. And honestly, which one should you actually pick?

That's the next post. Ride along.

This post is part of the "Learning AI Out Loud" series, a cloud architect learning AI from first principles.

Follow along with the series

I Built My Mom an AI Recipe Helper for Mother's Day

Ifeanyi O. — Fri, 08 May 2026 07:53:25 +0000

A project about a fridge, Strands agents & trying to keep up with Mom's seasons.

My Mom's Problem

My mom has a drawer full of recipes. Yes! Not a folder.... an actual drawer. Torn pages from magazines, things written on the back of envelopes and binders that've been around longer than I have. Whenever she's looking for dinner ideas she pulls something out, sighs and puts it back.

The recipe is not the issue here, that's always fine. It's that she's missing one ingredient or four!

And even if she has everything, the recipe might not fit whatever season she's in at the moment because the other thing is, her eating is a moving target.

One month she's a vegetarian because a friend got her into it, a few months later she's watching her sugar because the doctor mentioned it during a checkup, then it's low sodium or she's "just trying to be a little better with dinners." You just never really know which version is going to be at the stove on a given Tuesday.
But the real question she's always asking, underneath the recipe hunt, is...

What could I make with what I already have, that fits how I'm eating right now, that I won't get bored with?

Now that sounds like problem for an agent! So for Mother's Day this year, I built her one and called it AskMom Recipes. You can try it out here.

What it does in 30 seconds

You open a pink website and tell it what's in your kitchen. You can type it, or you can just take a photo of your groceries on the counter and drop it in.

You also have the option to pick how you're eating this week, for eg. no restriction, vegetarian, low sodium, diabetic-friendly or gluten-free. Then hit the "Suggest recipes" button.
A couple seconds later, you'll get three recipes and each one tells you:

What you already have vs. what you'd need to grab
Simple, unfussy steps (the kind of thing my mom actually cooks)
Why it's good for you, with real nutrition numbers from the USDA
One sentence about where the dish possibly comes from

If you don't love the recipes, you can tap "make it healthier" or "something quicker" or "fewer ingredients" and it adjusts on the fly.

That's it! The rest of this blog is how I built it and the design decisions that made the difference between "okay, cool demo that kinda works" and "something my mom would actually use."

Why an agent and not a prompt

An easy version of this would just be to throw the ingredients into a single prompt, ask for three recipes, done. I tried it, it's fine but there's problems that show up the moment you try to use it for real.
First, the model will happily make up nutrition numbers. Ask it how much protein is in chicken and it'll give you a number, confidently and you'll have no idea if it's right.

Second, it'll cheerfully tell you that tomatoes come from Italy or that pasta is a Chinese invention. Third, if you want to say "actually, make that healthier" the prompt has to start over from scratch because there's no memory.

An agent solves two of those three. As for the made up facts we needed something else which we'll get.

I used Strands Agents, which is a refreshingly simple Python SDK for building agents on Amazon Bedrock. You define your tools as functions, write a system prompt and Strands handles the loop of "model decides what tool to call, tool runs, result goes back to model, repeat."

It's the first agent framework I've used that didn't make me want to throw my laptop.

def build_agent(model_id: Optional[str] = None) -> Agent:

    model_id = model_id or os.environ.get(
        "BEDROCK_MODEL_ID", "anthropic.claude-3-haiku-20240307-v1:0"
    )
    region = os.environ.get("AWS_REGION", "us-east-1")

    model = BedrockModel(
        model_id=model_id,
        region_name=region,
        temperature=0.4,
    )

    return Agent(
        model=model,
        system_prompt=SYSTEM_PROMPT,
        tools=[
            extract_ingredients_from_image,
            extract_ingredients_from_text,
            suggest_recipes,
        ],
    )

With Strands, setting up the agent is almost anticlimactic. There's a model, a prompt and a list of tools. That's the whole thing.

I wanted to flag this, because it took me a few iterations to get right, the tools I gave the agent are not "one tool for everything." They're small, single-purpose and named like verbs.

The tools and why there aren't very many

Everyone always goes tool crazy, when they first build an agent. Each tool feels free so why not just add them all, right? Wrong!

The problem is every tool call is another round trip through the model. The model says "I'd like to call X," you run X, hand the result back, it thinks for a second and says "now I'd like to call Y." Each hop is a few seconds but when you add six tool calls, then your recipe helper takes forty seconds and your API times out.

So I decided to split the work in two:

Things the agent handles (because they genuinely need a model's judgment):

Reading a photo and identifying what's in it
Normalizing messy text like "some chicken, rice, maybe garlic" into a clean list
Generating three healthy recipes that fit the user's preferences

Things Python handles (because they just need a lookup):

Looking up real nutrition numbers
Formatting a recipe card for the frontend

Since Python can fetch faster than the model can ask, why would I let a language model guess when there's a real source? USDA has an API with the actual nutrition numbers.

This one design decision cut request latency from ~34 seconds to ~17 seconds. You get the same quality in half the time with way less money spent on Bedrock tokens and it made the agent more reliable with fewer retries and self corrections that eat tokens for no reason.

The lesson is to use the LLM for the things that need reasoning and use code for the things that need answers.

Preference handling

Alright, back to my mom for a second. The seasons thing, vegetarian one month and low sodium the next taught me more about preference handling that I didn't expect.

The naive approach is a freeform text field that ask you to type your dietary preferences. The problem is the model has to figure out what "watching my sugar a bit" means versus "diabetic-friendly" versus "low-carb." Sometimes it guesses wrong and sometimes the recipes it produces have way too much added.

So I made it a dropdown. Five options:

No restriction
Vegetarian
Low sodium
Diabetic-friendly
Gluten-free

Each one maps to a crisp, one sentence guidance block that gets injected into the recipe prompt:

_PREFERENCE_GUIDANCE = {
    "none": "No dietary restrictions. Focus on healthy, balanced meals.",
    "vegetarian": "Strictly vegetarian: no meat, poultry, or fish.",
    "low_sodium": "Low sodium: minimize salt and high-sodium ingredients like soy sauce or canned broths.",
    "diabetic_friendly": "Diabetic-friendly: low glycemic index, limit added sugars and refined carbs.",
    "gluten_free": "Strictly gluten-free: no wheat, barley, rye, or standard soy sauce.",
}

It's five lines of Python.

A dropdown sounds less impressive than "the AI understands your preferences," but the dropdown is more reliable and trust me, reliable is what my mom needs.

When it comes to agent patterns, the more you can constrain the inputs, the better the outputs. Freeform is cool in demos but more structure is better in real life.

The "send a photo of your groceries" part

I wanted to keep the typed-ingredients path simple, but the photo path is where it gets fun. You take a picture of whatever's on your counter and the agent reads the photo, identifies the food and treats it the same as if you'd typed it in.

Under the hood this is one of Strands' best party tricks. Claude 3 Haiku on Bedrock handles vision natively, so the whole thing is one tool call:

@tool
def extract_ingredients_from_image(s3_key: str) -> List[str]:
    """Look at a photo of groceries and return the ingredients visible in it."""
    bucket = os.environ["UPLOADS_BUCKET_NAME"]
    region = os.environ.get("AWS_REGION", "us-east-1")

    # 1. Fetch image bytes from S3
    s3 = boto3.client("s3", region_name=region)
    obj = s3.get_object(Bucket=bucket, Key=s3_key)
    image_bytes = obj["Body"].read()
    media_type = obj.get("ContentType", "image/jpeg")

    # 2. Ask Bedrock Claude Haiku what's in the photo
    prompt = (
        "List only the food ingredients you can clearly see in this photo. "
        "Return a JSON array of short lowercase names, nothing else. "
        'Example: ["tomato", "onion", "chicken breast"]. '
        "If you can't identify any food, return []."
    )
    bedrock = boto3.client("bedrock-runtime", region_name=region)
    response = bedrock.invoke_model(
        modelId=os.environ["BEDROCK_MODEL_ID"],
        body=json.dumps({
            "anthropic_version": "bedrock-2023-05-31",
            "max_tokens": 400,
            "messages": [{
                "role": "user",
                "content": [
                    {"type": "image", "source": {
                        "type": "base64",
                        "media_type": media_type,
                        "data": base64.standard_b64encode(image_bytes).decode(),
                    }},
                    {"type": "text", "text": prompt},
                ],
            }],
        }),
    )

    # 3. Pull the JSON array back out (defensively)
    text = json.loads(response["body"].read())["content"][0]["text"]
    match = re.search(r"\[.*?\]", text, re.DOTALL)
    if not match:
        return []
    try:
        items = json.loads(match.group(0))
    except json.JSONDecodeError:
        return []
    return [str(x).strip().lower() for x in items if str(x).strip()]

The prompt is boring on purpose. All is says is "List only the food ingredients you can clearly see in this photo. Return a JSON array of short lowercase names, nothing else." I did not give it a personality or tell it to "please think carefully". I also didn't give it examples of how the model should "reason." I just told it what I want and what format I want it in.

The model is very good at ambitious prompts and very good at literal ones. Ambitious prompts return ambitious, chatty and often wrong answers but literal prompts more closely return what you asked for. For this tool, where the output feeds directly into the next step, literal wins every time.

Also, note that the photo gets uploaded straight from the browser to S3 via a pre-signed URL, so my Lambda never has to deal with multipart file uploads. The agent just gets an S3 key and fetches it.

The Architecture

Here's the whole thing, in the order a request flows:

Browser loads static pink site from S3, served through CloudFront.
User submits text and/or photo. If photo, goes straight to S3 as pre-signed URL.
Browser calls POST /ingredients on API Gateway, which hits a Lambda.
Lambda builds a Strands agent with three tools, runs the agent loop.
Agent extracts ingredients (text + vision), then calls suggest_recipes once.
Lambda enriches each recipe in Python, origin lookup, USDA lookup and format.
Session is saved to DynamoDB with a 24-hour TTL for the "refine" follow up.
Recipes come back to the browser.

The whole thing is deployed with AWS CDK in Python, one stack, one make deploy. No Docker needed, no hand-wiring and definitely no clicking around in the console.

What it costs me to keep it running

For my mom's personal deployment, answering a few requests a week:

Bedrock: Tenth of a penny per recipe request.
Lambda: Free.
DynamoDB: Free.
S3 + CloudFront: Couple cents a month for the static site.
USDA API: Free.

I pay less for AskMom per month than for a single coffee. If I published it and a hundred people used it regularly, I'd still be under a few dollars a month!

Try it yourself

If you want to build one for your mom (or your dad, or anyone whose fridge is a mystery), the whole thing is open source.

Repo: github.com/rextheking/askmom-recipes-sample-for-aws-strands

The README walks through the deploy in six steps. You need:

An AWS account with Bedrock access enabled for Claude 3 Haiku in us-east-1
Python 3.12, Node 20/22/24, AWS CDK CLI and the AWS CLI
A free USDA FoodData Central API key (takes 30 seconds to get)

Then it's:

cd infra
make install
make bootstrap     # one time per AWS account
make deploy        # ~5-7 minutes, most of it CloudFront
# paste the ApiUrl into web/config.js
cd ../web
make deploy
# open the CloudFront URL

Note, the first deploy takes a few minutes because CloudFront is slow to propagate. If you're just kicking the tires, there's a -c with_cloudfront=false flag that skips CloudFront and gets you a working API in about 90 seconds.

The Hug

If you build something for your mom this year, I'd love to see it. Tag me or share the repo of whatever weird thing you shipped.

Happy Mother's Day 💖

Credits

Strands Agents for making agent code actually pleasant to write
Amazon Bedrock + Claude 3 Haiku for the model
USDA FoodData Central for free, honest nutrition data
My mom, for the original problem

Build your own daily notification bot on AWS Free Tier

Esin Saribudak — Fri, 08 May 2026 02:04:13 +0000

A Lambda function checks the forecast, Bedrock tells you what to wear, and ntfy.sh pushes it to your phone before you get ready for the day, and it's all Free Tier eligible.

Last updated: May 7, 2026

Every morning before work, you open your weather app. It takes a few seconds to refresh. Then you scroll past the hourly breakdown, the radar map, the air quality index, the pollen count. All you need to know is: what's the high, what's the low, is it going to rain, and what should you wear?

If you're leaving your home for the office every day like I am, this time spent scrolling and thinking every morning adds up. Especially where I live, where it might be 55°F when I leave the house and 88°F by lunch. You need a jacket at 7 AM and regret wearing it by noon. The weather app gives you all the data but none of the interpretation.

This tutorial walks you through building a service that sends you a push notification every morning with the forecast and a clothing recommendation. You deploy it once, and it runs on a schedule. Instead of opening an app and parsing data yourself, the notification just shows up with what you need. It looks like this on your phone:

Austin, TX — Tuesday, May 6
Today: 88°F, Partly Sunny
Tonight: 73°F, Mostly Cloudy
Wind: 10 mph S | Rain: 20%

Light layers today. Short sleeves with a light
jacket for the morning, ditch it by lunch.
No umbrella needed.

Along the way, you'll wire together EventBridge, Lambda, and Bedrock into an app that streamlines a daily task. By the end, you'll have a working notification on your phone and hands-on experience with the same infrastructure that powers production applications. All the AWS services it uses are eligible for the AWS Free Tier.

If you followed the blog post view counter tutorial, this is a good next project. Same tools, different services, and you end up with something you'll use every day. If you haven't built that one, that's fine too — the prerequisites section covers what you need.

What you're building

Here's the application flow:

EventBridge triggers a Lambda function every morning on a cron schedule
Lambda calls the National Weather Service API with your coordinates to get the local forecast
Lambda sends that weather data to Amazon Bedrock (Nova Lite) and asks for a clothing recommendation
Lambda formats the forecast + recommendation into a short message
Lambda sends the message as a push notification to your phone via ntfy.sh, an open source pub/sub service

Three AWS services, two free external APIs, about 230 lines of TypeScript.

Outside the US? The NWS API only covers US locations. If you're elsewhere, swap in Open-Meteo as a drop-in replacement. It's free for non-commercial use, requires no API key, and covers the entire world.

Prerequisites

An AWS account. If you don't have one yet, the Creating an AWS account guide walks you through it. You'll need a credit card on file, but this project stays within Free Tier limits.
Node.js 24 or later
AWS CLI installed and configured
AWS CDK bootstrapped in your account. If you haven't used CDK before, it's an infrastructure-as-code tool. You write TypeScript that describes your AWS resources, and CDK turns it into CloudFormation and deploys it. The bootstrap command creates a staging bucket CDK needs to upload your code, and needs to be run the first time you use it.

npx cdk bootstrap aws://YOUR_ACCOUNT_ID/us-east-1

ntfy app installed on your phone. Download ntfy from the App Store or Google Play. Open it and add a topic name you'll remember (this acts as your private channel, so pick something not easily guessable, like weather-forecast-abc123).

What is ntfy.sh and why use it for notifications

ntfy.sh (pronounced "notify") is an open-source push notification service built on a simple pub/sub model. You subscribe to a topic in the app, and any HTTP POST to that topic's URL shows up as a push notification on your phone. No account required, no API key, no app store approval process.

Project setup

Create a new directory and initialize the project:

mkdir daily-notification-bot && cd daily-notification-bot
npm init -y
npm install aws-cdk-lib constructs @aws-sdk/client-bedrock-runtime
npm install -D aws-cdk tsx typescript @types/node

Create a cdk.json file in the project root:

{
  "app": "npx tsx cdk/app.ts"
}

And a tsconfig.json:

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "NodeNext",
    "moduleResolution": "NodeNext",
    "lib": ["ES2022"],
    "outDir": "dist",
    "rootDir": ".",
    "strict": true,
    "types": ["node"],
    "esModuleInterop": true,
    "skipLibCheck": true,
    "declaration": true
  },
  "include": ["lambda/**/*", "cdk/**/*"]
}

Your project structure:

daily-notification-bot/
├── cdk/
│   ├── app.ts          # CDK entry point
│   └── stack.ts        # Infrastructure definition
├── lambda/
│   └── index.ts        # Lambda function code
├── cdk.json
├── package.json
└── tsconfig.json

Step 1: Define the infrastructure with CDK

Create cdk/stack.ts. This defines all the infrastructure:

import * as cdk from 'aws-cdk-lib';
import * as events from 'aws-cdk-lib/aws-events';
import * as targets from 'aws-cdk-lib/aws-events-targets';
import * as iam from 'aws-cdk-lib/aws-iam';
import { NodejsFunction } from 'aws-cdk-lib/aws-lambda-nodejs';
import { Runtime } from 'aws-cdk-lib/aws-lambda';
import * as path from 'path';
import { fileURLToPath } from 'url';
import { Construct } from 'constructs';

const __dirname = path.dirname(fileURLToPath(import.meta.url));

export class MorningForecastStack extends cdk.Stack {
  constructor(scope: Construct, id: string) {
    super(scope, id);

    // Configuration — pass these at deploy time:
    //   npx cdk deploy -c latitude=30.27 -c longitude=-97.74 -c ntfyTopic=my-secret-weather-topic
    const latitude = this.node.tryGetContext('latitude');
    const longitude = this.node.tryGetContext('longitude');
    const ntfyTopic = this.node.tryGetContext('ntfyTopic');

    if (!latitude || !longitude || !ntfyTopic) {
      throw new Error(
        'Missing required context. Deploy with: npx cdk deploy ' +
        '-c latitude=30.27 -c longitude=-97.74 -c ntfyTopic=my-secret-weather-topic'
      );
    }

    // Lambda function — fetches weather, calls Bedrock, sends notification via ntfy
    const fn = new NodejsFunction(this, 'ForecastFunction', {
      runtime: Runtime.NODEJS_24_X,
      entry: path.join(__dirname, '../lambda/index.ts'),
      handler: 'handler',
      environment: {
        LATITUDE: latitude,
        LONGITUDE: longitude,
        NTFY_TOPIC: ntfyTopic,
      },
      timeout: cdk.Duration.seconds(30),
      memorySize: 256,
    });

    // Grant Lambda permission to invoke Bedrock
    fn.addToRolePolicy(new iam.PolicyStatement({
      actions: ['bedrock:InvokeModel'],
      resources: ['arn:aws:bedrock:*::foundation-model/amazon.nova-lite-v1:0'],
    }));

    // EventBridge rule — triggers every morning at 6:30 AM CT (11:30 UTC)
    // Adjust the cron to match your timezone and preferred time
    new events.Rule(this, 'MorningSchedule', {
      schedule: events.Schedule.cron({
        minute: '30',
        hour: '11',    // 11:30 UTC = 6:30 AM CT
        weekDay: 'MON-FRI',
      }),
      targets: [new targets.LambdaFunction(fn)],
    });

    // Output the function name for manual testing
    new cdk.CfnOutput(this, 'FunctionName', {
      value: fn.functionName,
      description: 'Lambda function name (for manual invocation)',
    });
  }
}

How to schedule a Lambda function with EventBridge

The EventBridge rule above is what makes this run every morning. A few things to notice:

Configuration via context. Your coordinates and ntfy topic are passed at deploy time with -c flags. This keeps configuration out of your source code and makes the project easy to share. To find your coordinates, right-click any location in Google Maps and the lat/long will appear at the top of the context menu.
Notifications go through ntfy.sh, which is just an HTTP POST from Lambda. There are no AWS messaging services to configure, no phone number verification steps, and no sandbox restrictions to deal with.
Weekdays only. The cron schedule runs Monday through Friday. If you want weekends too, change weekDay: 'MON-FRI' to remove that constraint, or set it to '*'.
UTC time. EventBridge cron expressions use UTC. Central Time is UTC-5 (or UTC-6 during standard time), so 6:30 AM CT is 11:30 UTC during CDT. You'll need to adjust this for your timezone.
30-second timeout. The Lambda makes three external calls (NWS points, NWS forecast, and Bedrock), so we give it more time than the default 3 seconds. In practice it finishes in 2-4 seconds.

Now create the entry point at cdk/app.ts:

#!/usr/bin/env node
import * as cdk from 'aws-cdk-lib';
import { MorningForecastStack } from './stack.js';

const app = new cdk.App();
new MorningForecastStack(app, 'MorningForecastNotificationApp');

Step 2: Fetch the forecast and generate a notification

Create lambda/index.ts. This is the code that runs every morning:

import { BedrockRuntimeClient, InvokeModelCommand } from '@aws-sdk/client-bedrock-runtime';

const bedrock = new BedrockRuntimeClient({});

const LATITUDE = process.env.LATITUDE!;
const LONGITUDE = process.env.LONGITUDE!;
const NTFY_TOPIC = process.env.NTFY_TOPIC!;

const NWS_USER_AGENT = 'daily-notification-bot (github.com/your-repo)';

// Type definitions
interface NwsPoint {
  forecastUrl: string;
  city: string;
  state: string;
}

interface ForecastPeriod {
  name: string;
  temperature: number;
  temperatureUnit: string;
  windSpeed: string;
  windDirection: string;
  shortForecast: string;
  probabilityOfPrecipitation: number;
  isDaytime: boolean;
}

interface WeatherData {
  city: string;
  state: string;
  daytime: ForecastPeriod;
  nighttime: ForecastPeriod;
}

// Step 1: Get the NWS grid point for our coordinates
async function getNwsPoint(): Promise<NwsPoint> {
  const url = `https://api.weather.gov/points/${LATITUDE},${LONGITUDE}`;
  const response = await fetch(url, {
    headers: { 'User-Agent': NWS_USER_AGENT },
  });

  if (!response.ok) {
    throw new Error(`NWS points API error: ${response.status}`);
  }

  const data: any = await response.json();
  return {
    forecastUrl: data.properties.forecast,
    city: data.properties.relativeLocation.properties.city,
    state: data.properties.relativeLocation.properties.state,
  };
}

// Step 2: Get the forecast from the NWS grid point
async function getForecast(point: NwsPoint): Promise<WeatherData> {
  const response = await fetch(point.forecastUrl, {
    headers: { 'User-Agent': NWS_USER_AGENT },
  });

  if (!response.ok) {
    throw new Error(`NWS forecast API error: ${response.status}`);
  }

  const data: any = await response.json();
  const periods = data.properties.periods;

  const daytime = periods.find((p: any) => p.isDaytime);
  const nighttime = periods.find((p: any) => !p.isDaytime);

  const toPeriod = (p: any): ForecastPeriod => ({
    name: p.name,
    temperature: p.temperature,
    temperatureUnit: p.temperatureUnit,
    windSpeed: p.windSpeed,
    windDirection: p.windDirection,
    shortForecast: p.shortForecast,
    probabilityOfPrecipitation: p.probabilityOfPrecipitation?.value ?? 0,
    isDaytime: p.isDaytime,
  });

  return {
    city: point.city,
    state: point.state,
    daytime: toPeriod(daytime),
    nighttime: toPeriod(nighttime),
  };
}

// Step 3: Ask Bedrock for a clothing recommendation
async function getClothingAdvice(weather: WeatherData): Promise<string> {
  const prompt = `Today's forecast for ${weather.city}, ${weather.state}:
- Daytime (${weather.daytime.name}): ${weather.daytime.temperature}°${weather.daytime.temperatureUnit}, ${weather.daytime.shortForecast}
- Wind: ${weather.daytime.windSpeed} ${weather.daytime.windDirection}
- Rain chance: ${weather.daytime.probabilityOfPrecipitation}%
- Tonight: ${weather.nighttime.temperature}°${weather.nighttime.temperatureUnit}, ${weather.nighttime.shortForecast}

What should I wear today? Give me a practical recommendation in one to two sentences. Be direct and specific. No preamble.`;

  const body = JSON.stringify({
    messages: [
      {
        role: 'user',
        content: [{ text: prompt }],
      },
    ],
    inferenceConfig: {
      maxTokens: 80,
    },
  });

  const command = new InvokeModelCommand({
    modelId: 'amazon.nova-lite-v1:0',
    contentType: 'application/json',
    accept: 'application/json',
    body: new TextEncoder().encode(body),
  });

  const response = await bedrock.send(command);
  const result = JSON.parse(new TextDecoder().decode(response.body));
  return result.output.message.content[0].text;
}

// Step 4: Format the notification message
function formatMessage(weather: WeatherData, advice: string): string {
  const today = new Date().toLocaleDateString('en-US', {
    weekday: 'long',
    month: 'short',
    day: 'numeric',
    timeZone: 'America/Chicago', // Adjust to your timezone
  });

  return [
    `${weather.city}, ${weather.state} — ${today}`,
    `${weather.daytime.name}: ${weather.daytime.temperature}°${weather.daytime.temperatureUnit}, ${weather.daytime.shortForecast}`,
    `Tonight: ${weather.nighttime.temperature}°${weather.nighttime.temperatureUnit}, ${weather.nighttime.shortForecast}`,
    `Wind: ${weather.daytime.windSpeed} ${weather.daytime.windDirection} | Rain: ${weather.daytime.probabilityOfPrecipitation}%`,
    '',
    advice,
  ].join('\n');
}

// Step 5: Send push notification via ntfy.sh
async function sendNotification(message: string): Promise<void> {
  const response = await fetch(`https://ntfy.sh/${NTFY_TOPIC}`, {
    method: 'POST',
    headers: {
      'Title': 'Morning Forecast',
    },
    body: message,
  });

  if (!response.ok) {
    throw new Error(`ntfy.sh error: ${response.status}`);
  }
}

// Main handler — EventBridge triggers this every morning
export const handler = async (): Promise<void> => {
  const point = await getNwsPoint();
  const weather = await getForecast(point);
  const advice = await getClothingAdvice(weather);
  const message = formatMessage(weather, advice);

  await sendNotification(message);

  console.log('Forecast sent:', message);
};

The function does four things in sequence:

Calling the NWS weather API from Lambda

The NWS API works in two steps. First you send your coordinates to /points/{lat},{lon}, which returns metadata about your location including the forecast URL and your city/state name. The NWS requires a User-Agent header for identification, but no API key.

The second call hits the forecast URL from step one. It returns forecast periods (today, tonight, tomorrow, etc.) with temperature, wind, precipitation probability, and a plain-English summary like "Partly Cloudy" or "Chance Showers."

Using Bedrock to generate clothing advice

We send the weather data to Amazon Nova Lite with a prompt that asks for practical clothing advice. The maxTokens: 80 keeps the response tight — one to two sentences, no filler. Nova Lite is Amazon's cheapest model and responds in under a second.

Sending push notifications with ntfy.sh

The city name, forecast summary, and clothing advice get combined into a notification message and sent to ntfy.sh with a single HTTP POST. The ntfy app on your phone picks it up instantly.

Step 3: Deploy and test your notification

Deploy with your coordinates and ntfy topic:

npx cdk deploy \
  -c latitude=YOUR_LATITUDE \
  -c longitude=YOUR_LONGITUDE \
  -c ntfyTopic=YOUR_NTFY_TOPIC

Replace the values with your own:

Latitude and longitude of your location. Right-click any spot in Google Maps and the coordinates appear at the top of the menu. For example, Austin, TX is 30.27,-97.74.
ntfy topic — the same topic name you subscribed to in the ntfy app. This is like a private channel, so pick something not easily guessable.

CDK will show you the resources it's creating and ask for confirmation. Type y.

CDK asks because the stack creates IAM permissions (Lambda's execution role, Bedrock invoke access). This is standard for any stack that includes a Lambda function. Review the permissions if you want, then approve.

After about two minutes, you'll see output like this:

✅  MorningForecastNotificationApp

✨  Deployment time: 107.44s

Outputs:
MorningForecastNotificationApp.FunctionName = MorningForecastNotificationApp-ForecastFunctionBE622553-a1B2c3D4e5Fg

Stack ARN:
arn:aws:cloudformation:us-east-1:123456789012:stack/MorningForecastNotificationApp/67f1ff60-1234-5678-abcd-0affd8af3937

✨  Total time: 110s

Don't wait until tomorrow morning to test it. Invoke the function manually using the function name from the deploy output:

aws lambda invoke \
  --function-name MorningForecastNotificationApp-ForecastFunctionBE622553-a1B2c3D4e5Fg \
  --payload '{}' \
  output.json

Check your phone. You should have a push notification from the ntfy app with today's forecast and a clothing recommendation. 😎

Step 4: Customize the schedule, location, and AI prompt

Change your location

Update the coordinates in your deploy command. Right-click any location in Google Maps to get the
lat/long:

npx cdk deploy \
  -c latitude=YOUR_LATITUDE \
  -c longitude=YOUR_LONGITUDE \
  -c ntfyTopic=YOUR_NTFY_TOPIC

How to change the EventBridge cron schedule

The cron expression in stack.ts controls when you get your notification. A few examples:

// Every day at 7:00 AM ET (12:00 UTC during EDT)
schedule: events.Schedule.cron({ minute: '0', hour: '12' })

// Weekdays at 6:00 AM CT (11:00 UTC during CDT)
schedule: events.Schedule.cron({ minute: '0', hour: '11', weekDay: 'MON-FRI' })

// Every day at 6:30 AM PT (13:30 UTC during PDT)
schedule: events.Schedule.cron({ minute: '30', hour: '13' })

Remember: EventBridge uses UTC. Convert your local time accordingly.

Tweak the AI prompt

The Bedrock prompt in getClothingAdvice() is where you make this yours. The default asks for one to two direct sentences. Some ways to customize:

// If you bike to work:
"Assume I'm biking 3 miles to the office."

// If you run hot:
"I tend to run warm, so err on the side of lighter clothing."

// If you want outfit specifics:
"Suggest specific items: jacket type, shirt type, pants vs shorts, shoe type."

// If you want even less:
"Answer in one sentence only."

The prompt is just a string. Change it, redeploy, and your morning notification changes with it.

How the full flow works

Now that you've seen all the code, here's the complete flow, complete with approximate timestamps:

6:30 AM — EventBridge fires a scheduled event
6:30:01 — Lambda calls the NWS API with your coordinates, gets the forecast
6:30:02 — Lambda sends the weather data to Bedrock, gets back clothing advice
6:30:03 — Lambda formats the message and POSTs it to ntfy.sh
6:30:04 — Your phone buzzes with a push notification

Total execution time: 2-4 seconds. Total cost: covered by Free Tier.

How much this costs on AWS Free Tier

This project uses services eligible for the AWS Free Tier. Here's what each one costs:

Service	Free Tier allowance	Your usage
EventBridge	14M scheduled invocations/month	~30/month
Lambda	1M requests/month, 400K GB-seconds	~30 invocations/month
Bedrock (Nova Lite)	Free Tier credits	~$0.001/month
ntfy.sh	Free (open source)	~30 notifications/month
NWS API	Free (US government data)	~60 calls/month

EventBridge — 14 million scheduled invocations per month free. You're using around 30.

Lambda — You'll probably use around 30 invocations per month, each running for 2-4 seconds at 256 MB. That's well under the 1 million requests and 400,000 GB-seconds you get free.

Bedrock — Nova Lite costs fractions of a cent per invocation at this token volume. At 30 calls per month, it comes out of your Free Tier credits.

ntfy.sh — free, and doesn't require an account or API key for personal use.

NWS API — free US government public data, no key required.

I'd still recommend setting up a billing alarm at $5 as a safety net.

What you just learned

If you followed along, you now have hands-on experience with:

EventBridge: cron scheduling in UTC, weekday-only rules
Lambda: calling external APIs, environment variables, working with the Bedrock SDK
Bedrock: invoking a foundation model, prompt design, controlling output length
CDK: defining infrastructure in TypeScript, passing configuration via context, deploying with a single command
NWS API: the two-step points → forecast pattern for US weather data
ntfy.sh: push notifications via a simple HTTP POST

And you have something running that you'll actually use every morning.

A note on security

This project has a small attack surface. The Lambda has no public URL and can only be triggered by EventBridge within your account. There's no user input, no stored data, and the IAM permissions are scoped to a single Bedrock model.

The one thing to be aware of: your ntfy topic name is the only access control on your notifications. Anyone who knows the topic name can subscribe and read your messages. Since the content is just weather data, the risk is low, but pick a topic name that isn't easily guessable. If you want tighter control, ntfy supports token-based auth on their paid plan, or you can self-host.

Cleanup

If you want to tear everything down:

npx cdk destroy \
  -c latitude=YOUR_LATITUDE \
  -c longitude=YOUR_LONGITUDE \
  -c ntfyTopic=YOUR_NTFY_TOPIC

This deletes the Lambda, the EventBridge rule, and the IAM role. Your morning notifications will stop. Unsubscribe from the topic in the ntfy app if you want to clean that up too.

What to try next

Add a weekend mode with a later send time and more casual tone
Send a mid-day alert if rain probability spikes above 70%
Share the topic with your household so everyone gets the notification
Add a weekly summary on Sunday evenings for the week ahead
Swap the NWS API for Open-Meteo if you're outside the US (free for non-commercial use, covers the entire world)
Replace the weather API with something else you care about: stock prices, package tracking, your team's on-call schedule, a daily quote. The architecture will likely be similar regardless of what data you're fetching.

If you built the blog post view counter, you now have two working projects on AWS Free Tier: one that reacts to events (page views) and one that runs on a schedule (morning forecast). Between the two, you've used Lambda, DynamoDB, API Gateway, EventBridge, and Bedrock.

The source code for this project is on GitHub if you want to fork it and make it your own.

Embed These Websites In Your Blog Today

Sean Boult — Thu, 07 May 2026 18:34:41 +0000

I stumbled onto the DEV supported URL embeds list, which revealed some interesting supported platforms.

You'll want to refer to the link above to figure out the syntax for the DEV specific ones but most are just:

{% embed <url> %}

If you would like to jump around.

asciinema
StackBlitz
GitHub
X/Twitter
YouTube
DEV specific

asciinema

A video-like player which is so cool because you can actually pause it and copy the text from it.

StackBlitz

Interactive code editor right in a blog post 😍. Seems like the embedded terminal and preview will fail due to some postMessage shenanigans, but perhaps it can be fixed.

GitHub

It supports rendering the README to give some brief context with a CTA to open the repo.

strands-agents / sdk-typescript

A model-driven approach to building AI agents in just a few lines of code.

Strands Agents - TypeScript SDK

A model-driven approach to building AI agents in TypeScript/JavaScript

Documentation ◆ Samples ◆ Python SDK ◆ Tools ◆ Agent Builder ◆ MCP Server

Overview

Strands Agents is a simple yet powerful SDK that takes a model-driven approach to building and running AI agents. The TypeScript SDK brings key features from the Python Strands framework to Node.js environments, enabling type-safe agent development for everything from simple assistants to complex workflows.

Key Features

🪶 Lightweight & Flexible: Simple agent loop that works seamlessly in Node.js and browser environments
🔒 Type-Safe Tools: Define tools easily using Zod schemas for robust input validation and type inference
📋 Structured Output: Get type-safe, validated responses from LLMs using Zod schemas with automatic retry on validation errors
🔌 Model Agnostic: First-class support for Amazon Bedrock and OpenAI, with extensible architecture for custom providers
🔗 Built-in MCP: Native…

View on GitHub

X/Twitter

Useful when a tweet has some context you want to reference.

// Detect dark theme var iframe = document.getElementById('tweet-2052162536301072643-248'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2052162536301072643&theme=dark" }

YouTube

Video is king 👑. However, I'd probably reach for the "Cover Video Link" feature, where you can have the video be your banner instead of an image.

DEV specific

These are some of the custom things that DEV supports outside of third party site embeds.

Article Link:

Erik Hanchett for AWS

May 4

Stop Reaching for Python: Strands Agents TypeScript SDK Just Hit 1.0

#typescript #ai #aws #agents

Comments 1

8 min read

User Profile:

Brooke JamiesonFollow

🌥️ I’ll teach you tech tips in bite sized videos 📣 Keynote Speaker 👩🏻‍💻 AI/ML Specialist 💼 AWS Sr Developer Advocate (views are my own) 🇦🇺AU ➡️ NYC🗽

Tag Profile:

#aws Follow

Amazon Web Services (AWS) is a collection of web services for computing, storage, machine learning, security, and more There are over 200+ AWS services as of 2023.

Comment:

Comment on What Even Is AI? (I Took a Break & Had to Relearn Everything)

Jess Lee May 5