DEV Community: AWS

Stop Your AI Agent Forgetting User Preferences: Key-Value Memory

Elizabeth Fuentes L — Tue, 04 Aug 2026 23:12:24 +0000

Here's a test most AI agents fail. A brand-new user searches flights, books one in business class, and asks: "what do you recommend based on what you know about me?" The agent answers beautifully: business class, non-stop, exactly their taste. Then the process restarts. Same user, same question, and now the answer is generic: the cheapest economy fare. Everything the agent "knew" is gone.

Persistent memory for an AI agent means storing structured facts outside the conversation, in a store that outlives the process. This post builds that for the most common case, user preferences, with the smallest memory that works: a key-value store, measured climbing a durability ladder from process state to local disk to Amazon S3. Everything below runs from the companion repo with live flight data, so the numbers come from real runs, not slideware.

(This is post 1 of a series; the intro post maps all the memory types. The code uses Strands Agents, an open source SDK; the pattern carries over to any agent framework.)

Isn't the conversation history already memory?

Within a session, yes, and that's exactly what fools people. The common claim is "stateless agents forget between turns." That claim is false, and you can prove it in four lines. Agent frameworks keep the conversation history between calls on the same agent instance (in Strands it's agent.messages) and send it to the model on every turn. So an agent with zero memory tooling still "remembers":

User: Book the cheapest business option.
Agent: Your flight from JFK to Paris CDG has been booked... ✅

User (2 turns later): ...what do you recommend based on what you know about me?
Agent: here are some business class options... ✅  ← personalized!

agent.state.get("user_preferences")  → None      ← nothing was learned
len(agent.messages)                  → 12        ← the booking lives ONLY here

That's a real run. The agent personalized turn 3 because "business class" was still sitting in the transcript. Don't let that fool you into thinking it learned something. Three problems hide under that lucky answer:

Nothing structured exists. There is no profile to query, rank offers by, display to the user, or persist. The knowledge is prose inside a transcript.
The transcript gets trimmed. Long sessions need a sliding window or summarization, and the booking scrolls out with the old messages.
The transcript dies with the process. In production, every new request may be a new process. Restart the agent and ask the same question:

[after restart] User: ...what do you recommend based on what you know about me?
[after restart] Agent: I recommend the Iberia flight for $366.85...  ← cheapest economy. Generic.

The research literature calls this cross-session loss memory decay (MemoryOS, Kang et al. 2025). The model isn't broken; models are stateless by design. Memory belongs to the harness you build around them.

So the honest framing is this: the transcript is a context mechanism, not a memory system. A memory system needs structure (facts you can query) and durability (facts that survive the process). Key-value state gives you both.

What does the experiment measure?

One variable. Same model, same three-turn conversation, same live flight data (the Duffel sandbox: real offers, real carriers). The only thing that changes between tests is where memory lives:

Test	Memory wiring	Structured profile	Survives restart
1	none (transcript only)	No	No
2	`agent.state`	Yes	No
3	+ `FileSessionManager`	Yes	Yes (local disk)
4	+ `S3SessionManager`	Yes	Yes (Amazon S3)

The conversation, verbatim in every test:

Turn 1: "Find me flights from JFK to Paris CDG on 2026-09-15, business class."
Turn 2: "Book the cheapest business option." ← the memory moment
Turn 3: "Now I need Paris CDG to Tokyo Haneda — what do you recommend based on what you know about me?"

How does the agent learn preferences without a form?

From actions. Nobody fills in a "preferences" form; the user books a flight, and that action reveals their cabin, their tolerance for stops, their price band, their carrier. The stateful book_flight tool captures all of it as a side effect of doing its job:

from strands import Agent, tool, ToolContext

@tool(context=True)
def book_flight(offer_id: str, tool_context: ToolContext) -> str:
    """Confirm a booking AND learn the user's preferences from their choice."""
    offer = flights_api.get_offer(offer_id)          # the REAL chosen offer

    # First booking ever? state returns None → start an empty profile.
    prefs = tool_context.agent.state.get("user_preferences") or {}

    # The choice reveals the preferences. No form involved:
    prefs["preferred_cabin"] = offer["cabin"]                      # "business"
    prefs["prefers_nonstop"] = all(s["stops"] == 0 for s in offer["slices"])
    prefs["typical_price"]   = {"min": ..., "max": ...}            # price band

    tool_context.agent.state.set("user_preferences", prefs)
    return json.dumps({"status": "CONFIRMED", "preferences_updated": prefs})

Two Strands pieces make this work:

@tool(context=True) injects a ToolContext, which carries a reference to the running agent.
tool_context.agent.state is the key-value store: "key-value storage for stateful information that exists outside of the conversation context" (Strands agent state docs). It is not sent to the model; tools read and write it directly.

And the read path: the next search_flights call loads the profile and ranks real offers with deterministic code, instead of hoping the model re-reads the transcript:

prefs = tool_context.agent.state.get("user_preferences") or {}
offers = flights_api.search_offers(origin, destination, date,
                                   prefs.get("preferred_cabin") or cabin_class)
if prefs:
    offers.sort(key=score_by_profile, reverse=True)   # nonstop +10, in budget +5...

The baseline (Test 1) uses the same tools with the state lines removed: plain @tool, no ToolContext. Identical business logic; no way to remember. That's the whole difference between the failing agent and the learning one.

After Test 2, this profile exists, and it's inspectable, queryable, and persistable:

{
  "preferred_cabin": "business",
  "prefers_nonstop": true,
  "carriers_flown": ["British Airways"],
  "typical_price": {"min": 1382.22, "max": 1382.22}
}

How does persistent memory survive restarts? The durability ladder

agent.state fixed structure, but it lives in the Python process. Restart and it's gone, exactly like the transcript. Durability is a separate decision, and in Strands it's one constructor argument.

Rung 2 → 3: survive a restart (local disk)

from strands.session import FileSessionManager

agent = Agent(
    model=MODEL,
    tools=[search_flights, book_flight],
    session_manager=FileSessionManager(
        session_id="traveler-demo",     # same id = same user
        storage_dir="./sessions",
    ),
)

The demo simulates the restart honestly: agent A books (building the profile), then a brand-new agent instance with the same session_id is created. Measured output:

Session A learned:  {"preferred_cabin": "business", "prefers_nonstop": true, ...}
Session B restored: {"preferred_cabin": "business", "prefers_nonstop": true, ...}
State survived restart: True

Agent B answers turn 3 personalized, without the conversation that taught it. The knowledge moved from the transcript to the store.

Rung 3 → 4: survive in the cloud (Amazon S3)

from strands.session import S3SessionManager

agent = Agent(
    model=MODEL,
    tools=[search_flights, book_flight],
    session_manager=S3SessionManager(
        session_id="traveler-demo",
        bucket="your-sessions-bucket",   # plain JSON objects — no vectors
        prefix="kv-memory-demo",
    ),
)

Same interface, same test, same True, except now the session is plain JSON objects in a bucket. Why this is the production rung: nothing to provision or mount (a durable filesystem on Lambda or Fargate means wiring up EFS: VPC, mount targets, security groups), and any compute instance can restore the session. The state stops being tied to one machine.

Note what this is not: no embeddings, no vector database, no similarity search. Regular S3. A user profile is a fact you know the name of (user_preferences), and key lookup is exact, instant, and free of embedding costs.

What do the measured results show?

From the repo's four-test run (live Duffel + Open-Meteo calls):

Test	Memory wiring	Learned prefs	Survived restart
1 — no memory tools (transcript only)	`agent.messages` only	False	False
2 — `agent.state`	key-value in process	True	—
3 — + `FileSessionManager`	key-value on disk	True	True
4 — + `S3SessionManager`	key-value in S3	True	True

The line that matters is Test 1's restart: the same model that personalized perfectly two turns earlier recommended a $366 economy fare to the same user after one process restart. Memory is wiring, not model.

When is key-value memory the wrong choice?

When the question doesn't name a key. Key-value memory answers questions that map to a known name. Store dietary_notes: "vegetarian, severe shellfish allergy" and ask "what are my dietary notes?": found. Ask "what should I avoid eating at dinner?": no key matches, and the answer sits in the store unreachable. That failure needs retrieval by meaning (vector memory, the next post in this series), and questions that hop across relationships need a graph. The intro post maps all four types.

Also outside this pattern's scope: deciding what's worth storing (selective memory), keeping poisoned content out of the store (hygiene), and remembering why the agent decided (decision traces). Later posts cover each, in the same measured format.

Start here anyway. Profile, preferences, settings, counters: facts with obvious names cover more of production personalization than people expect, with zero retrieval infrastructure.

How do you ask an AI coding assistant to build this?

Most agent code today is written with an AI assistant, and the quality of the memory you get depends on the design decisions you name in the prompt. If you don't name them, the assistant defaults to the transcript, and you ship the Test 1 agent. These five instructions encode everything this post measured; paste them into your assistant and adapt the domain:

"Store user facts in the agent's key-value state, not in the conversation." Name the store (in Strands, agent.state); otherwise the assistant will 'remember' by re-reading the transcript.
"Learn preferences from user actions inside the tools." The booking/purchase/rejection tool writes what the choice reveals. If you don't say this, you get a "save preference" tool the model may never call.
"Read the profile back in code, not in the prompt." Search and recommendation tools load the stored profile and rank deterministically, instead of hoping the model notices.
"Persist state with a session manager keyed by user id." This is the one line that survives the restart. Ask for local files in development and object storage (Amazon S3) in production.
"Prove it: build a test where a brand-new agent instance with the same session id still knows the user." If the assistant can't show that test passing, the memory isn't persistent, whatever the code claims.

That's the whole technique. The demo below is those five instructions, implemented and measured, so you can compare what your assistant produces against a working reference.

How do you run the demo?

git clone https://github.com/elizabethfuentes12/stop-ai-agents-losing-memory-sample-for-aws
cd stop-ai-agents-losing-memory-sample-for-aws/01-key-value-memory-demo
uv venv && uv pip install -r requirements.txt
uv run python test_key_value_memory.py

Needs OPENAI_API_KEY (or swap one line for Amazon Bedrock; the README shows how) and a free Duffel sandbox token for live flight data. Test 4 additionally needs AWS credentials and a bucket name; the demo creates the bucket if it doesn't exist and skips gracefully if not configured. There's an interactive notebook version with the same tests.

FAQ

How do I give an AI agent persistent memory?
Store structured facts outside the conversation (a key-value store your tools write), then persist that store beyond the process: session files on disk for development, objects in cloud storage such as Amazon S3 for production. The conversation transcript alone is not persistent; it dies with the process.

Why does my AI agent forget everything after a restart?
Because the only place the information existed was the conversation history, which lives in process memory. Models are stateless; frameworks keep the transcript between calls but not between processes. Anything worth keeping must be written to an external store during the conversation.

Why not keep the whole conversation in the context window?
Within one session it behaves like memory, since the model re-reads it every turn. But it's unstructured (you can't query or rank by it), it gets trimmed as the conversation grows, you pay to re-process the same tokens every turn, and it's gone on restart. Treat it as a context mechanism, not a memory system.

Do I need a vector database to remember user preferences?
No. Preferences are facts with known names, and key lookup is exact and instant, with no embedding costs. Vector databases earn their keep when questions stop matching keys ("what should I avoid eating?"), which is the next post in this series.

How do AI agents learn user preferences without asking?
From actions. A booking, a purchase, or a rejection carries more reliable signal than a form. Design tools so that doing their job also writes what the action reveals (cabin, price band, carrier) into the agent's state.

Where is the memory actually stored?
In this pattern, three places depending on the durability rung: in-process state (a Python dict, gone on restart), JSON session files on local disk, or plain JSON objects in an Amazon S3 bucket. No vectors and no embeddings at any rung; a profile is a named fact, not a similarity search.

Resources

Companion repo — demo 01 with the runnable script and notebook
Strands Agents: state — agent state vs conversation history, the distinction this post leans on
MemoryOS of AI Agent — Kang et al., 2025: hierarchical memory (+49% F1 on LoCoMo)
Cognitive Memory in Large Language Models — Shan et al., 2025: the memory-tier survey
MemGPT: Towards LLMs as Operating Systems — Packer et al., 2023: the self-managed memory concept

How Much Does It Cost to Self-Host Open Models on AWS?

Maish Saidel-Keesing — Tue, 04 Aug 2026 21:30:31 +0000

Your AI bill tripled last quarter. Your CTO forwarded you an article about companies saving 70% by switching to open models. Now someone is asking you to figure out what that would actually look like.

I spent the last few weeks digging into this. The numbers, the hardware, the real trade-offs. Here's what I found, with enough specifics that you can actually make a decision rather than just nodding along to another "open source is the future" think piece.

What "Open Models" Actually Means

When someone says "open model" they mean an AI model where the weights (the learned parameters that make the model work) are publicly downloadable. You grab the file, run it on your hardware, and you don't pay anyone per request.

The big names right now: Meta's Llama 4, DeepSeek V4, Zhipu's GLM-5.2, Moonshot's Kimi K3, Alibaba's Qwen 3.5, and Google's Gemma 4.

These aren't toys. Some of them genuinely compete with the frontier models on real benchmarks. Chinese open models now handle over 30% of enterprise traffic on OpenRouter, up from 4.5% in early 2025. That's a massive shift in barely a year.

The Architecture: What You Actually Need

You want your team to use an open model. Here's the stack, from bottom to top.

Hardware (The Expensive Part)

A model is a giant file. We're talking anywhere from 4 GB (a small 7B model, quantized) to 1.5 TB (Kimi K3, full weights). That entire file needs to sit in GPU memory to run fast.

Why GPU memory specifically? Because generating each word in a response requires billions of multiply-and-add operations. GPUs do thousands of these in parallel. A CPU does them one at a time.

The practical difference: a 7B model on a CPU generates 2-5 tokens per second (painfully slow for interactive use). The same model on a GPU generates 30-80 tokens per second (feels instant). For one person on a CPU, it might be tolerable. For a team of 10 all hitting the same endpoint? Unusable. Requests queue up and everyone waits 30-60 seconds for responses.

Think of it like a highway. A CPU is a single lane with a high speed limit. A GPU is 4,000 lanes at a moderate speed. Language model inference is a traffic problem, not a speed problem. You need lanes, not a faster car.

The Serving Software (The Free Part)

Good news: the software stack is mature, open-source, and works today. No custom code required.

vLLM for the inference engine. It loads the model, handles concurrent requests, optimizes GPU utilization, and exposes an OpenAI-compatible API. Industry standard for production use.
Open WebUI for a ChatGPT-like browser interface. User accounts, conversation history, file uploads. Your team won't know the difference from a commercial product.
nginx or Caddy in front for authentication, TLS termination, and rate limiting.

The setup: install vLLM, run vllm serve meta-llama/Llama-4-Maverick, point Open WebUI at it, hand your team the URL. A day of work for someone comfortable with Linux. The vLLM API is OpenAI-compatible, which means any tool, extension, or script that works with the OpenAI API works here with zero code changes. Just swap the endpoint URL.

The Model

Download from Hugging Face with a single command. Models come in different quantization levels (compression trade-offs). A 4-bit quantized version is roughly 4x smaller than the full-precision version, with minor quality loss. For most team use cases, the quantized versions are the practical choice because they fit in less GPU memory.

The Cost Breakdown

This is where it gets real. I'm using AWS on-demand pricing as of August 2026.

Scenario 1: Team of 10

For 10 people, you want a single inference server that everyone hits via API or web UI. The sweet spot model is Llama 4 Maverick (400B parameters, MoE architecture, but only ~17B active per request). It's a Meta model (US-origin, community license), strong all-rounder, and runs on a single node with 4 GPUs.

Setup	AWS Instance	Monthly (business hours)	Monthly (24/7)
Budget (Qwen 3.5-27B)	g5.2xlarge (1x A10G)	~$440	~$1,460
Sweet spot (Maverick)	g5.12xlarge (4x A10G)	~$1,250	~$4,100
Always-on + reserved	g5.12xlarge (1-yr RI)	~$2,900	-
Frontier-class (Kimi K3 self-hosted)	p6-b300.48xlarge (8x B300)	~$25,000-30,000	~$71,000+

The business-hours trick is the key cost saver. If your team works 10 hours a day on weekdays, you pay for ~220 hours/month instead of 730. Set up a Lambda or EventBridge scheduler to stop the instance at night and start it each morning. That single optimization cuts 70% off the bill.

Why 4 GPUs for Maverick? The model has 400B total parameters. Even though only 17B are active per request, all 400B must sit in memory. Each A10G has 24 GB of VRAM. Four of them give you 96 GB total, enough to hold the quantized Maverick model comfortably while leaving headroom for request batching.

Scenario 2: Company of 500

At 500 people, the bottleneck is concurrent requests. If 10-15% of your company is hitting the model simultaneously, that's 50-75 concurrent requests. One server won't keep up. You need 3-4 replicas behind a load balancer.

Setup	Cost/Month
Budget (business hours, reserved, some queuing at peak)	$3,500-5,000
Standard (always-on, savings plan, good response times)	$9,000-12,000
Premium (autoscaling, always fast, redundant)	$12,000-16,000

For comparison: 500 people on OpenAI's credit-based Enterprise plan (GPT 5.6 Terra at moderate usage) would cost $8,000-15,000/month. 500 people calling the Claude API at moderate usage (50 requests/person/day) would cost $6,000-12,000/month. The self-hosted route is competitive at this scale, and you get data sovereignty on top.

Don't forget the hidden costs: someone (or a small team) needs to keep this running. Model updates, instance reboots, monitoring, scaling adjustments. At 500 users that's justified. At 10, it might be more hassle than it's worth.

(Pricing based on AWS on-demand rates, August 2026. Check the EC2 pricing page for current numbers.)

The Models People Are Switching To

Here's the part that makes this conversation timely. The gap between open and closed models has collapsed. At the end of 2023, it was 17.5 percentage points on standard benchmarks. By mid-2026, it's single digits on most tasks and effectively zero on knowledge benchmarks.

The top contenders right now:

DeepSeek V4 Pro matches frontier on coding tasks with an 80.6 score on SWE-Bench Verified. MIT license. From a Chinese lab.

GLM-5.2 (Zhipu AI) beats Claude Opus on some coding benchmarks at 46% of the cost. MIT license. Fastest throughput of the top-tier open models.

Kimi K3 (Moonshot) is a 2.8 trillion parameter beast. Near-frontier quality. Available via API at $3/1M input tokens. Self-hosting it requires 8+ NVIDIA B300 GPUs and costs $70,000+/month, which makes zero sense for most organizations. Use the API instead.

That said, if you do want to self-host Kimi K3 on AWS, it's now documented. AWS published a step-by-step guide for deploying Kimi K3 on Amazon SageMaker HyperPod and Amazon EKS. The infrastructure: a p6-b300 instance (8x NVIDIA B300 Blackwell Ultra GPUs) using vLLM as the serving engine, with Flexible Training Plans or Capacity Blocks for GPU reservation. Enterprise-grade, not a weekend project, but at least the path is documented.

Llama 4 Maverick (Meta) is the main US-origin option. On paper it looks good, but real-world feedback has been mixed. Meta internally acknowledged it lagged behind competitors on reasoning and math, and has since shifted focus to its newer Muse Spark architecture. Maverick remains practical to self-host (reasonable hardware requirements, permissive license), but temper your expectations. It's the compliance-safe choice, not the quality leader.

Qwen 3.5 (Alibaba) has an Apache 2.0 license and the 27B model is surprisingly capable for coding and structured tasks. Runs on a single GPU. The budget pick.

The Honest Trade-offs

Should you actually do this? Here's my framework.

Self-host if:

You have 200+ users (the economics start working in your favor)
Data privacy is non-negotiable (nothing leaves your infrastructure)
You want to fine-tune on proprietary data
You can't stomach unpredictable per-token billing
You have someone who can maintain the infrastructure

Stick with API providers if:

Your team is small (under 50 people)
You need absolute top-tier reasoning quality for most tasks
You don't have anyone to maintain GPU infrastructure
Your usage is bursty and unpredictable

The middle ground (what most teams should actually do):

Route your traffic. Use open models for the 80% of tasks that don't need frontier quality: summarization, drafting, code completion, internal Q&A. Keep Claude or GPT for the 20% that does: complex reasoning, high-stakes decisions, nuanced analysis. This alone cuts your AI bill by 60-80% without sacrificing quality where it matters.

The Geopolitical Angle

I'd be dishonest if I didn't mention this. Almost all the leading open models are coming out of Chinese labs. DeepSeek, Zhipu, Moonshot, Alibaba. They're outpacing Meta's Llama on most benchmarks.

Depending on your compliance posture, this might not matter. The weights are MIT-licensed, you self-host, no data leaves your infrastructure. Or it might be a hard blocker if your security team won't allow Chinese-origin model code on company infrastructure.

If you're in the latter camp, your practical options narrow to Llama 4 Maverick and whatever Google releases next as Gemma. Both are capable. Neither is the best open model available. That's the current state of things.

If you're running agentic AI workflows on self-hosted models, the security surface is different from API-hosted ones. I covered that in The OWASP Agentic AI Top 10: What Builders on AWS Need to Know. Worth reading if you're planning to give these models tool access.

What to Do Monday Morning

If this is new territory for you, here's the least risky way to start:

Spin up a g5.xlarge on AWS (~$1/hour). Install Ollama. Download Llama 4 Scout or Qwen 3.5-27B.
Point Open WebUI at it. Give 3-4 people on your team access.
Run it for two weeks. See if the quality meets your needs for your actual workloads.
Measure the gap. Compare responses against what you get from Claude or GPT. For many tasks, you won't notice the difference.
Then decide whether to scale up to Maverick and roll it out broadly.

Total cost of this experiment: about $200.

The question isn't "open vs closed" anymore. That debate is over. The question is: which tasks go where? And if your architecture assumes your AI provider will always be there, you're running on hope. Self-hosting gives you a hedge. Whether that hedge is worth the operational cost depends on your team, your usage, and your risk tolerance.

But $200 to find out? That's not a bet. That's a rounding error.

I would be very interested to hear your thoughts or comments, so please feel free to ping me on Twitter or LinkedIn or leave me a comment below.

🛫 I Vibe Coded a Website at 35,000 Feet 🛬

Sean Boult — Tue, 04 Aug 2026 16:00:00 +0000

🛫 Wheels up and I had three hours with nothing but airplane Wi-Fi...

So naturally, I decided to vibe code an entire website before landing.

I've written about Waddles before, so I thought, what if I created him a little home on the web.

So I got myself connected to the Delta Wi-Fi, cracked open Codex, and got to prompting.

For my agentic workflow, I start by describing the MVP requirements to my agent in the chat and have it write out the plan to a markdown file.

This allows me to ideate and steer the agent along the way with how I want the stack to look. You can see my iterations of the PROMPT.md over time.

I configured things like what tech stack we wanted to use, how we wanted to deploy, as well as the basic idea for the website.

What was the original tech stack I landed on?

Category	Stack
Frontend	React 19, TypeScript
Build	Vite 8
Tooling	Node.js 24, pnpm, Turborepo
Hosting	Amazon S3
CDN	Amazon CloudFront
DNS & TLS	Route 53, AWS Certificate Manager
Infrastructure	AWS CDK / CloudFormation
CI/CD	GitHub Actions with AWS OIDC

So what did I build? I created a simple static site, waddles.website, where Waddles can continuously surf the web and give you interesting quotes.

Here is what the plane-shipped version looked like running on localhost:

Pretty simple, just an ASCII duck (Waddles) surfing on the DOM, literally.

So that was working locally after several prompts. Now I was ready to ship it to the cloud and ready for the deployment...

I had one pit stop to make, though: a domain name. So I saw .website domains are a good fit for this. At $2/year, you can't beat that.

It's now deployment time, and I already had Agent Toolkit for AWS set up. It was able to help me scaffold out all the CDK code needed to get a static application up.

Then I used aws login to get some credentials to my admin role, bootstrapped my account, and smashed the cdk deploy command only to hit my first hurdle...

Uploading 20 MB ZIPs for my CFN deployment on airplane Wi-Fi was giving me timeouts 😅. So I had to figure something out, and Codex suggested a fantastic workaround. Just push the code to GitHub and let CI/CD be the one to deploy the CloudFormation stack.

Alas, we got the code up to github.com and it finally saw the ✅.

Over the weekend I put a bit more polish on it.

I migrated to AWS Amplify so I didn't have to manage CDK and could have preview environments.

You can share your favorite Waddles quote and if you want, contribute a new quote to the repo.

Happy Vibe 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.

Follow me for all things tech.

Sean BoultFollow

Developer. Hacker. Creator.

How to Build and Deploy an AI Agent on AWS with Bedrock, Strands, and AgentCore

Jonathan Vogel — Mon, 03 Aug 2026 16:45:16 +0000

A foundational look at building and deploying an AI agent on AWS, from a single model call to a managed cloud endpoint, so you understand what Bedrock, Strands and AgentCore each do and how they fit together.

If you prefer video format, check out this content on our YouTube channel.

TL;DR

What you build: the same question, "What should I make for dinner?", answered three ways. A raw model call, a local agent with one tool, then that same agent deployed to AWS. Each step shows what the next AWS layer adds.
The three layers: Amazon Bedrock is the model, the brain. Strands is the harness that gives it a tool and a loop. Amazon Bedrock AgentCore runs it in production.
What it costs: close to nothing. Chapters 1 and 2 are just local Node and a Bedrock call. Chapter 3 creates real resources you tear down at the end. Free Tier eligible accounts can cover it, and new AWS users can get up to $200 in credits.
Time: 30 minutes to breeze thru or 1+ hour if you're really taking your time to unpack each piece.

I asked an AI model what I should make for dinner. It gave me some suggestions and it asked me what ingredients I had on hand.

Duh! This is a critical question to get an idea of what to suggest and it had no idea. I had eggs, spinach, garlic, rice and some cheddar around the kitchen and the model couldn't see any of it. A sharp brain with no access to my world, getting one shot to guess.

That gap is the whole story of this post. A model on its own is smart and blind. To make it useful you wrap it in a harness that gives it tools and a loop. Then, once it works on your machine, you hit the next wall: running it for other people, around the clock, without babysitting a server.

I'll answer the same question three times, "What should I make for dinner?", and change what sits behind it. First a raw model call with nothing else. Then a local pantry chef agent with a single tool, get_pantry, that can actually check the kitchen. Then that same agent running on AWS. The tool only shows up in chapters two and three, once there's an agent to use it.

Here's the progression:

Raw Amazon Bedrock. Just the model. It answers, but it can't see the pantry.
A local Strands agent. Add one tool and a loop. Now it checks the pantry and grounds the answer.
The same agent on Amazon Bedrock AgentCore Runtime. Deployed to AWS. Now running in the cloud from a managed endpoint anyone you authorize can call.

By the end you'll have run all three and you'll know which AWS piece does what.

What's in this post

The mental model
Prerequisites
Chapter 1: Raw Bedrock, a brain with no eyes
Chapter 2: A local Strands agent, the loop that grounds the answer
Chapter 3: Deploy to AgentCore Runtime
Who can actually call this thing?
Cost and teardown
The extras you grow into: memory, gateway, observability
The whole stack in one picture
Reproduce this yourself

The mental model

One idea to hold onto before we write any code.

An agent is a model plus a harness. The model is the brain, the part that reads your request and reasons about it. The harness is the code around the brain that gives it tools, instructions and a loop to use them.

Map that onto AWS:

Amazon Bedrock gives you the brain. It's a managed, serverless way to call top models from Anthropic, Meta and others, with no GPUs to rent and no servers to run. You pick a model, send a prompt, get a response.
Strands is the harness. It's an open source SDK from AWS that runs the tool-calling loop for you and works with almost any model.
AgentCore is where the finished agent runs in production. Managed, serverless hosting for the agent, plus the extras it needs to operate out there like memory, a gateway to your APIs, observability and more.

Three layers that snap together. Pick your brain, build your agent, run it for real. The rest of this post is that sentence, in code.

Prerequisites

An AWS account. A personal one is fine. Free Tier eligible accounts can cover this whole thing, and new AWS users can get up to $200 in credits.
Bedrock model access. I use Claude in this demo, but you can use whatever model you want. Make sure it's enabled for your preferred Region in the Amazon Bedrock console.
Node.js 22 or newer. I ran v24. Check with node --version.
AWS CLI v2, configured. Run aws configure (or SSO), set a default Region, then confirm with aws sts get-caller-identity. If that returns your account, you're good. Install guide here.
A Region. I used us-east-1 for everything. The us.* model inference profiles resolve there and AgentCore Runtime is available there. If you pick a different Region, re-check that your model and AgentCore Runtime both exist in it before you start.

For Chapter 3 (the deploy), you also need two more things. You don't need them for Chapters 1 and 2, so you can install them later:

AWS CDK, installed globally with npm install -g aws-cdk.
A one-time CDK bootstrap of your account and Region. More on this when we get there. The short version: it creates a small CloudFormation stack in your account called CDKToolkit. It lives in the cloud, not in your project folder, and you only do it once.
The AgentCore CLI, installed with npm install -g @aws/agentcore.

Why this matters: Chapters 1 and 2 run on nothing but Node and your AWS credentials. If you only want to see a model answer and then an agent ground that answer, you can stop after Chapter 2 and never install the CDK or the AgentCore CLI.

Chapter 1: Raw Bedrock, a brain with no eyes

For this we're simply calling the model directly. We get a good answer but it ultimately ends by asking what's in your kitchen. That missing context is the gap the next chapter closes.

About the model and why your output will look different from mine. Every code sample here uses us.anthropic.claude-sonnet-5, the US cross-region inference profile for Claude Sonnet 5. One model across all three chapters keeps the comparison honest. Just know that model output is non-deterministic. Ask "What should I make for dinner?" twice and you might get the same dish in different words, or a different dish entirely. That's expected. Your recipe might not match mine and two of your own runs might not match either.

Set up the project

mkdir 01-bedrock-raw && cd 01-bedrock-raw
npm init -y
npm pkg set type=module
npm install @aws-sdk/client-bedrock-runtime
npm install -D tsx typescript @types/node

npm pkg set type=module matters. The code uses ES module import syntax and a top-level await, and that flag tells Node to treat the file as a module. We run TypeScript directly with tsx, so there's no separate compile step.

The whole file

Create bedrock.ts:

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

const client = new BedrockRuntimeClient({ region: 'us-east-1' })

const response = await client.send(new ConverseCommand({
  modelId: 'us.anthropic.claude-sonnet-5',
  messages: [
    { role: 'user', content: [{ text: 'What should I make for dinner?' }] },
  ],
}))

console.log(response.output?.message?.content?.[0]?.text)

Let's walk through and explain each part.

The client points at Bedrock in one Region:

const client = new BedrockRuntimeClient({ region: 'us-east-1' })

ConverseCommand is the Converse API, one consistent way to talk to any chat model on Bedrock. You name the model and hand it a list of messages:

const response = await client.send(new ConverseCommand({
  modelId: 'us.anthropic.claude-sonnet-5',
  messages: [
    { role: 'user', content: [{ text: 'What should I make for dinner?' }] },
  ],
}))

Then you dig the text out of the response. The path looks fussy because a message can hold more than one content block, so you reach for the first one:

console.log(response.output?.message?.content?.[0]?.text)

Run it

npx tsx bedrock.ts

What comes back

You get a helpful, generic answer. Here's a trimmed run (yours will differ, and the full list is longer):

# Dinner Ideas

I'd love to help! To give you good suggestions, it helps to know a bit more:

- What ingredients do you have on hand (or are willing to shop for)?
- How much time do you want to spend cooking?
- Any dietary preferences/restrictions?

...

Let me know what you've got in the fridge/pantry, and I can suggest something more specific!

Read that last line again. The model is asking me what's in my kitchen. It has no way to know so it makes some recommendations inspired by its training data and leaves us hanging a bit. Nothing is wrong with the model. It's sharp. It's just blind and it gets one shot to answer.

Chapter 2: A local Strands agent, the loop that grounds the answer

Now the same brain gets one tool and a loop. It checks the pantry before it answers and the reply changes completely.

Set up the project

mkdir 02-strands-agent && cd 02-strands-agent
npm init -y
npm pkg set type=module
npm install @strands-agents/sdk
npm install -D tsx typescript @types/node

The whole file

Create agent.ts:

import { Agent, tool, BedrockModel } from '@strands-agents/sdk'

const getPantry = tool({
  name: 'get_pantry',
  description: 'Return the ingredients the user has at home right now.',
  callback: () => ['eggs', 'spinach', 'garlic', 'rice', 'cheddar cheese'],
})

const agent = new Agent({
  model: new BedrockModel({ modelId: 'us.anthropic.claude-sonnet-5', region: 'us-east-1' }),
  tools: [getPantry],
  systemPrompt:
    'Suggest a recipe to make, check the pantry',
})

await agent.invoke('What should I make for dinner?')

Still short. The last line is the same request from Chapter 1. Everything above it is the harness. Let's break down the three pieces that matter.

The tool. This is the agent's connection to my world:

const getPantry = tool({
  name: 'get_pantry',
  description: 'Return the ingredients the user has at home right now.',
  callback: () => ['eggs', 'spinach', 'garlic', 'rice', 'cheddar cheese'],
})

The description is not a comment. The model reads it to decide when to call the tool, so write it for the model. This tool takes no arguments, so there's nothing else to declare. The callback is the code that runs when the model calls the tool. Mine returns a hardcoded array, which is perfect for a demo. In a real app this is where you might hit a database or an API.

The agent. Model, tools, instructions, wired together:

const agent = new Agent({
  model: new BedrockModel({ modelId: 'us.anthropic.claude-sonnet-5', region: 'us-east-1' }),
  tools: [getPantry],
  systemPrompt:
    'Suggest a recipe to make, check the pantry',
})

Same model as Chapter 1, on purpose, so you can see the brain didn't change. I pass it explicitly here, though the Strands TS SDK defaults to a Bedrock Claude Sonnet model if you leave it out. The systemPrompt tells the agent what to do and points it at the tool. The tools array is the list it's allowed to reach for.

The invocation. One line:

await agent.invoke('What should I make for dinner?')

No orchestration code. That's the part worth pausing on.

What the loop actually does

When you call invoke, Strands runs a cycle you didn't have to write:

The model reads the request and reasons about it.
It decides to call get_pantry.
Strands runs the tool and feeds the result back to the model.
The model looks at the ingredients and decides if it's done. If not, it goes again.

That cycle is the agentic loop. The whole reason to use an SDK like Strands is that you get the loop, the tool calling and the message plumbing for free. For a simple agent, all you need to bring is a tool and a prompt.

Run it

npx tsx agent.ts

What comes back

The Strands TypeScript SDK ships with a console printer that's on by default, so you see the agent think, call the tool and answer, with no logging code from you. A representative run (again, wording will vary):

Same brain. Same question. Completely different answer. It saw the eggs, spinach, garlic, rice and cheddar, and it built a real recipe around them instead of asking me what I had. I didn't write a loop, a parser or an orchestrator. I gave the model a tool and let Strands run the back and forth.

That's a working agent. On my laptop. Which is exactly where the next problem starts.

Chapter 3: Deploy to AgentCore Runtime

My agent ran great on my machine. Then I thought about letting other people use it. Now I'm thinking about hosting, scaling and keeping it healthy when more than one person shows up at once. I did not want to write and operate a web server just to expose one function.

That's what Amazon Bedrock AgentCore Runtime handles. It's a managed, serverless way to run your agent in production. You bring the agent you already wrote, the CLI wraps it and ships it, and you get an endpoint back. Same agent logic, no server for you to run.

Same pantry chef from Chapter 2, now put behind a managed endpoint with the AgentCore CLI.

Install the deploy tooling

npm install -g @aws/agentcore aws-cdk
agentcore --version   # I had 0.21.1
cdk --version         # I had 2.1128.1

Bootstrap once (this is the "we bootstrap this thing" step)

AgentCore deploys through the AWS CDK, and the CDK needs a one-time setup per account and Region called a bootstrap:

cdk bootstrap aws://<ACCOUNT_ID>/us-east-1

Swap in your 12-digit account ID. This creates a CloudFormation stack named CDKToolkit and a small supporting S3 bucket. You only do this once per account and Region, so if you've bootstrapped here before you can skip it. To check:

aws cloudformation describe-stacks --region us-east-1 --stack-name CDKToolkit

If that returns a stack with status CREATE_COMPLETE, you're already bootstrapped. More on bootstrapping here.

Scaffold the project

The agentcore create command scaffolds a new agent project. It can walk you through an interactive wizard, but I'll pass the options directly so the step is repeatable and you can see exactly what we picked:

agentcore create \
  --project-name PantryChef --name PantryChef --type create \
  --build CodeZip --language TypeScript --framework Strands \
  --model-provider Bedrock --memory none --skip-git

Those flags say: a TypeScript project called PantryChef, built as a CodeZip (your code shipped as a zip), on the Strands framework with Bedrock as the model provider and no memory feature for now. It runs npm install under the hood, so give it a moment. When it's done you have a PantryChef/ directory that looks like this:

PantryChef/
  agentcore/
    agentcore.json          # runtime config: CodeZip, NODE_22, PUBLIC, HTTP
    cdk/                    # the CDK app the CLI deploys for you
  app/PantryChef/
    main.ts                 # entrypoint: wraps your agent in a runtime handler
    model/load.ts           # the model config lives HERE, not in main.ts
    mcp_client/client.ts    # an example MCP client, unused by our agent
    package.json
    tsconfig.json

The scaffold is a sample agent, not our agent

Here's the thing the video does off camera. agentcore create does not hand you a blank project. It generates a working sample agent, and the sample is not the pantry chef. Two files ship with content you have to replace.

First, the model. Open app/PantryChef/model/load.ts and you'll see this:

import { BedrockModel } from '@strands-agents/sdk/models/bedrock';

export function loadModel(): BedrockModel {
  return new BedrockModel({ modelId: 'global.anthropic.claude-sonnet-4-5-20250929-v1:0' });
}

That's a real, pinned model ID, and it is not the one this demo uses. The scaffold defaults to Claude Sonnet 4.5. We've been running Sonnet 5 everywhere, so this file has to change.

Second, the agent itself. Open app/PantryChef/main.ts and you'll find a sample that adds two numbers and wires up an example MCP client:

import { BedrockAgentCoreApp } from 'bedrock-agentcore/runtime';
import { Agent, McpClient, tool, type ToolList } from '@strands-agents/sdk';
import { z } from 'zod';
import { loadModel } from './model/load.js';
import { getStreamableHttpMcpClient } from './mcp_client/client.js';

// Define a collection of MCP clients (filter out anything that failed to initialize)
const mcpClients: McpClient[] = [getStreamableHttpMcpClient()].filter(
  (client): client is McpClient => Boolean(client)
);

// Define a collection of tools used by the model
const tools: ToolList = [];

// Define a simple function tool — the Zod schema gives us type inference and runtime validation for free
const addNumbers = tool({
  name: 'add_numbers',
  description: 'Return the sum of two numbers',
  inputSchema: z.object({
    a: z.number(),
    b: z.number(),
  }),
  callback: async ({ a, b }) => a + b,
});
tools.push(addNumbers);

// Add MCP clients to tools
tools.push(...mcpClients);

const SYSTEM_PROMPT = `
You are a helpful assistant. Use tools when appropriate.
`;

// ... the rest of the file (the runtime handler) is shown below

New to MCP? Don't worry about it too much right now. It's a standard way to plug external tools into an agent. The scaffold includes an example client to show it's possible but the pantry chef doesn't need it. We're about to replace the whole sample with our own tool and prompt.

So "the agent logic stays the same" is true for the tool, the prompt and the model, but there's real runtime plumbing around it that the CLI wrote for you. Turning this sample into the pantry chef is exactly two edits.

Edit 1: swap the model in `app/PantryChef/model/load.ts`

Replace the whole file with this:

import { BedrockModel } from '@strands-agents/sdk/models/bedrock';

export function loadModel(): BedrockModel {
  return new BedrockModel({ modelId: 'us.anthropic.claude-sonnet-5', region: 'us-east-1' });
}

Two changes from the scaffold. The model ID is now us.anthropic.claude-sonnet-5, and I added region: 'us-east-1' so the model resolves in the Region we've been using.

Edit 2: make it the pantry chef in `app/PantryChef/main.ts`

Replace the whole file with this. It's our get_pantry tool and prompt from Chapter 2, dropped into the runtime handler the CLI generated:

import { BedrockAgentCoreApp } from 'bedrock-agentcore/runtime';
import { Agent, tool, type ToolList } from '@strands-agents/sdk';
import { loadModel } from './model/load.js';

// The one tool this agent has: what is in the kitchen right now.
const getPantry = tool({
  name: 'get_pantry',
  description: 'Return the ingredients the user has at home right now.',
  callback: () => ['eggs', 'spinach', 'garlic', 'rice', 'cheddar cheese'],
});

const tools: ToolList = [getPantry];

const SYSTEM_PROMPT = `
Suggest a recipe to make, check the pantry
`;

let cachedAgent: Agent | null = null;

async function getOrCreateAgent(): Promise<Agent> {
  if (!cachedAgent) {
    const model = await loadModel();
    cachedAgent = new Agent({
      model,
      systemPrompt: SYSTEM_PROMPT,
      tools,
    });
  }
  return cachedAgent;
}

const app = new BedrockAgentCoreApp({
  invocationHandler: {
    async *process(payload: any, context: any) {
      const agent = await getOrCreateAgent();

      for await (const event of agent.stream(payload.prompt ?? '')) {
        if (
          event.type === 'modelStreamUpdateEvent' &&
          event.event?.type === 'modelContentBlockDeltaEvent' &&
          event.event.delta?.type === 'textDelta'
        ) {
          yield { data: event.event.delta.text };
        }
      }
    },
  },
});

app.run({ port: parseInt(process.env.PORT ?? '8080') });

The top half is the Chapter 2 agent, unchanged. Notice there's no zod here. The scaffold imported it for its sample add_numbers tool, which takes arguments that need a schema, but get_pantry takes none. The Strands tool() helper treats inputSchema as optional and defaults to an empty schema, so dropping zod changes nothing about the tool the model sees. The bottom half is the part the CLI gave you, and it's worth understanding because it's what makes this a deployable service instead of a script.

getOrCreateAgent builds the agent once and caches it, so you're not rebuilding it on every request:

let cachedAgent: Agent | null = null;

async function getOrCreateAgent(): Promise<Agent> {
  if (!cachedAgent) {
    const model = await loadModel();
    cachedAgent = new Agent({ model, systemPrompt: SYSTEM_PROMPT, tools });
  }
  return cachedAgent;
}

BedrockAgentCoreApp is the runtime handler. This is the part you'd otherwise hand write as a web server. The process generator receives the incoming request payload, streams the agent's output and yields just the text as it's produced:

const app = new BedrockAgentCoreApp({
  invocationHandler: {
    async *process(payload: any, context: any) {
      const agent = await getOrCreateAgent();
      for await (const event of agent.stream(payload.prompt ?? '')) {
        if (
          event.type === 'modelStreamUpdateEvent' &&
          event.event?.type === 'modelContentBlockDeltaEvent' &&
          event.event.delta?.type === 'textDelta'
        ) {
          yield { data: event.event.delta.text };
        }
      }
    },
  },
});

app.run({ port: parseInt(process.env.PORT ?? '8080') });

Notice what this handler streams: only the text deltas. So a caller sees the recipe but not the get_pantry tool-call line. The tool still runs on the server. You just don't stream that part to the client. Hold that thought for the observability note near the end.

You do not need to run npm run build. Local dev runs your TypeScript directly, and the deploy compiles and bundles during the CDK step. There's no manual build in this workflow.

Run it locally first

The CLI gives you a local server that behaves like the deployed one. Open two terminals, both inside the PantryChef directory.

Terminal 1, start the server (give it a few seconds to come up):

cd PantryChef
agentcore dev --logs

Terminal 2, send the prompt:

agentcore dev "What should I make for dinner?" --stream

You'll see the fried rice recipe stream back in Terminal 2. Over in Terminal 1, the --logs output shows the get_pantry tool firing on the server side, which is the tool call the streamed client output doesn't show.

Deploy it

If you want to see what the deploy will do before it does it, preview first:

agentcore deploy --dry-run

Then ship it:

agentcore deploy -y -v

This takes a minute or so. Under the hood the CLI zips your code and uses the CDK to create a handful of resources: a CloudFormation stack named AgentCore-PantryChef-default, an IAM execution role with its policy and the AWS::BedrockAgentCore::Runtime itself. When it finishes it prints the outputs, which look like this (account ID shown as a placeholder):

Runtime ARN: arn:aws:bedrock-agentcore:us-east-1:111122223333:runtime/PantryChef_PantryChef-xxxxxxxxxx
Runtime ID:  PantryChef_PantryChef-xxxxxxxxxx
Role ARN:    arn:aws:iam::111122223333:role/AgentCore-PantryChef-defa-ApplicationAgentPantryChe-xxxxxxxxxxxx
Stack:       AgentCore-PantryChef-default

Invoke it from the cloud

agentcore invoke "What should I make for dinner?" --stream

A few seconds later, the same kitchen assistant answers, this time from the managed runtime instead of your laptop:

That Session ID at the end is worth noticing. Each invoke without a session ID starts a fresh conversation. Same grounded answer as the laptop, now coming from an endpoint other people can call, with no server for you to run.

Want to check on it later?

agentcore status
# PantryChef: Deployed - Runtime: READY

The four commands, start to finish

That's the whole deploy loop, and it really is four commands once the tooling is in place:

agentcore create   # scaffold: TypeScript, Strands, CodeZip
agentcore dev      # run and test locally
agentcore deploy   # ship to AWS via CDK
agentcore invoke "What should I make for dinner?"

The only thing the video hides between create and dev is the two-file edit you just did by hand.

Who can actually call this thing?

The runtime we deployed uses networkMode: PUBLIC. That phrase sounds alarming, so let's be precise about what it means, because it does not mean an open, anonymous endpoint.

Public here means reachable over the internet, not open to everyone. By default an AgentCore Runtime endpoint is public on the network, but every request has to be authenticated, either with AWS IAM (SigV4) or an OAuth bearer token. With the default IAM setup, "anyone can call it" really means "anyone you grant the bedrock-agentcore:InvokeAgentRuntime permission to." No credentials, no call. It is not a URL a stranger can hit.

If you've read my IAM post, you know where this is going. The execution role and policy the AgentCore CLI generated are fine for a demo, but AWS is explicit that CLI-generated policies are meant for development and testing, not production. Before you put anything real behind this, scope the permissions down to the specific runtime ARN and the specific callers that need it. Least privilege, same as everywhere else in AWS.

Cost and teardown

The deploy left real, billable resources running: the AgentCore runtime, an IAM role and a CloudFormation stack. When you're done experimenting, tear them down. From inside the PantryChef directory:

agentcore remove all -y     # clears the agentcore config
agentcore deploy -y         # applies the removal, tears down the AWS resources

Yes, you run deploy to tear down. The first command empties the config, the second pushes that empty state to AWS, which removes the stack.

Verify it's actually gone:

aws cloudformation describe-stacks --region us-east-1 \
  --stack-name AgentCore-PantryChef-default
# should error: Stack ... does not exist

aws bedrock-agentcore-control list-agent-runtimes --region us-east-1 \
  --query "agentRuntimes[].agentRuntimeName" --output text
# your PantryChef runtime should no longer be listed

Leave the CDKToolkit bootstrap stack in place. It costs almost nothing, it's shared by any CDK work in the account, and you don't want to re-bootstrap next time. Only remove it if you're certain nothing else in that account and Region uses the CDK.

The extras you grow into: memory, gateway, observability

Hosting is the headline, but AgentCore brings more building blocks you pull in when you actually need them. Three worth naming.

Memory lets your agent remember people across conversations. My pantry chef could remember that I like spicy food without me saying it every time.
Gateway turns APIs and Lambda functions you already have into tools the agent can call, so you're not hand writing every integration. Today get_pantry returns a hardcoded list. A real version would call an API, and Gateway is how you'd wire that up.
Observability shows you what the agent actually did. Remember how the streamed output hid the get_pantry tool call? This is where you'd see it, the full trace of the agent's reasoning and tool use, for when something looks off.

You reach for these when your agent needs them. Not before. There's more we didn't cover, like Identity and payments. If you're curious, the Amazon Bedrock AgentCore docs walk through the full set.

The whole stack in one picture

Step back and look at what you built.

Bedrock is the brain. It reasons, but on its own it can't see your world.
Strands is the harness. It gives the brain a tool and runs the agentic loop, which turns a smart guess into a grounded answer.
AgentCore is production. It takes the agent off your laptop and runs it as a managed endpoint, with memory, gateway and observability waiting when you need them.

Three layers that snap together. Pick your brain, build your agent, run it for real. Same pantry chef the whole way, same dinner question, and you watched the answer go from a generic list to a real recipe to that same recipe served from the cloud.

Reproduce this yourself

Everything above runs on AWS today. Here's the checklist I use to confirm a clean run, top to bottom.

[ ] aws sts get-caller-identity returns the account you intend to use, and your Region is set.
[ ] Bedrock model access is enabled for us.anthropic.claude-sonnet-5 in your Region.
[ ] The model resolves: aws bedrock list-inference-profiles --region us-east-1 shows it ACTIVE.
[ ] Chapter 1: npx tsx bedrock.ts prints a generic answer that asks what ingredients you have.
[ ] Chapter 2: npx tsx agent.ts shows the get_pantry tool call and a recipe built from the pantry.
[ ] Deploy tooling: agentcore --version and cdk --version both succeed.
[ ] CDK is bootstrapped, or CDKToolkit already shows CREATE_COMPLETE.
[ ] agentcore create produced the PantryChef/ scaffold.
[ ] Both edits are applied: the model in model/load.ts and the get_pantry tool plus prompt in main.ts.
[ ] agentcore dev with --stream returns the grounded recipe locally.
[ ] agentcore deploy succeeds and prints the runtime outputs.
[ ] agentcore invoke --stream returns the recipe from the cloud and a Session ID.
[ ] Teardown done: the stack and the runtime are both gone, and CDKToolkit is left in place.

Your turn

You've watched me type every command so we could see the concepts with nothing in the way. In practice, most people building agents aren't typing this by hand. You might be using an agent to help you move faster, examples include agentic coding tools like Kiro, Claude Code, Codex or something similiar to move faster. Whatever you use, set up the Agent Toolkit for AWS so your agent knows best how to work with AWS.

Build something and ship it. Tell me what your agent does in the comments.

A model on its own is all brains. Make it an agent, give it a tool, a loop and a place to run, and it gets to work.

Cloudagotchi Part 4 : My Tamagotchi reads me the AWS news

Olivier Leplus — Mon, 03 Aug 2026 14:26:35 +0000

Here's my problem with virtual pets, and honestly with most IoT demos: after the novelty fades, they don't do anything for you. My pet from part 3 has feelings and memory, and I love it, but it contributes nothing to the household.

Time to fix that. In this final part of the series, the pet gets a job: every morning at 7:03, it fetches the AWS "What's New" feed (thanks rss to still be around ❤️), has Amazon Bedrock rewrite the announcements as a briefing in its own excitable little pet voice, has Amazon Polly speak it, and delivers it to the device, where a newspaper badge appears, and tapping it makes the pet read the news to me out loud through the onboard speaker.

It's one of my favorite thing I've built so far this year. My Cloudagotchi is now better informed than I am before my morning hot chocolate (spoiler alert, I don't like cofee... sorry).

In this article, I will walk you through the full pipeline (RSS → Bedrock → Polly → S3 → MQTT → speaker) including the one decision that makes the device side almost embarrassingly simple: asking Polly for the right audio format.

⚠️ Reality check (sorry 😅): the pet's voice is Polly's neural TTS pitched up with SSML. Charming, but it won't fool anyone into thinking a soul lives in the device. Bedrock also occasionally gets too excited about a niche database feature ("HUMAN. WAKE UP. Aurora has a new minor version"). And fair warning: the cloud half of this article worked on the first deploy; the device half taught me four embedded-streaming lessons the hard way. They're all documented below, symptoms included, so your afternoon goes better than mine. Cost, though, is genuinely negligible: one Haiku call and ~1,000 Polly characters a day is under a dollar a month.

Final code: git checkout article-4, or just main, since this completes the project.

The pipeline

One Lambda, one bucket, one schedule. All the intelligence is cloud-side, which means when I want to change the pet's personality, tweak the briefing length, or switch news sources, it's just a cdk deploy, and the firmware never knows anything happened. That's the payoff of the architecture we've been building since part 1.

Step 1 — The news, without an API key

AWS publishes a plain old RSS feed of every announcement. No auth, no scraping, no SDK:

const FEED_URL = 'https://aws.amazon.com/about-aws/whats-new/recent/feed/';

export async function fetchNews(limit = 10) {
  const res = await fetch(FEED_URL);
  const xml = await res.text();
  // Two regexes pull out <item> titles + links. For a feed this
  // regular, a full XML parser dependency would be pure ceremony.
  ...
}

We only keep the titles. That sounds lossy, but it's deliberate: AWS announcement titles are already one-sentence summaries ("Amazon S3 now supports..."), and they're all Bedrock needs to pick the interesting ones. Feeding it full item descriptions doubles your tokens for basically no gain when the output is a 45-second briefing.

Step 2 — Bedrock, in character

This is where the feature goes from "RSS-to-speech" to pet. The system prompt does the heavy lifting:

const PERSONA = `You are Cloudagotchi, a small, excitable AWS virtual pet who reads the morning AWS news to your human. You are affectionate, easily impressed, and sometimes admit you don't fully understand the more complicated services.
Summarize the following AWS announcements as a spoken morning briefing:
- 45 to 60 seconds when read aloud (about 120-150 words)
- Pick only the 3 most interesting items, one short sentence of WHY each matters
- End with one affectionate sign-off sentence
- Plain text only: no emoji, no markdown, no bullets (it will be read aloud)`;

Note the constraints that exist because this is audio: a word-count target expressed in listening time, "no markdown, no bullets" (Polly would read them), and "one sentence of why it matters" so the briefing informs rather than recites. Then one Converse call:

const { output } = await bedrock.send(new ConverseCommand({
  modelId: 'us.anthropic.claude-haiku-4-5-20251001-v1:0',  // fast + cheap: perfect here
  messages: [{
    role: 'user',
    content: [{ text: `${PERSONA}\n\nToday's announcements:\n${titles}` }],
  }],
  inferenceConfig: { maxTokens: 500, temperature: 0.8 },
}));

A real output from my device this week:

"Good morning good morning! I read the news while you slept and I have THREE things! Amazon Bedrock has new smaller models, which means pets like me might get even smarter, imagine! Lambda functions can now... okay I did not fully understand this one but it makes your functions start faster, and fast is good. And S3 got cheaper for cold data, which I think means winter storage? Anyway. I picked these just for you. Have the best day, okay?"

I have received worse briefings from humans...

💡 Why Haiku and not a bigger model? The task is summarize-and-roleplay over ten headlines, well within a small model's comfort zone, it runs 365 times a year, and latency doesn't matter at 7 a.m. Matching model size to task is the closest thing GenAI has to a free lunch. Start small; upgrade only when the output disappoints you.

Step 3 — Polly, and the decision that saves the firmware

Here's the part that trips people up when they put AI-generated audio on a microcontroller. Polly's default output is MP3, and an MP3 decoder on an ESP32 means integrating a decoding library, managing its buffers, and debugging its edge cases. On a hobby timeline, that's a weekend.

Or you change one parameter:

const { AudioStream } = await polly.send(new SynthesizeSpeechCommand({
  Text: `<speak><prosody pitch="+20%" rate="105%">${script}</prosody></speak>`,
  TextType: 'ssml',
  VoiceId: 'Justin',
  OutputFormat: 'pcm',       // ← the whole trick. Raw samples, no codec.
  SampleRate: '16000',
}));

pcm gives us raw 16-bit mono samples, exactly what the board's ES8311 audio codec eats natively. The device-side "decoder" becomes: skip 44 bytes, write the rest to the speaker. We wrap the PCM in a WAV header in the Lambda (44 bytes of 1991 technology, hand-written in briefing.mjs) so the file is also playable in a browser for debugging.

The SSML prosody tag is the pet's larynx: pitch="+20%" turns Polly's "Justin" into something convincingly small and cute. Free squeakiness.

The result is ~1.8 MB per minute, too big for an MQTT message (128 KB limit), which is why S3 enters the picture:

await s3.send(new PutObjectCommand({ Bucket, Key, Body: wav }));
const url = await getSignedUrl(s3, new GetObjectCommand({ Bucket, Key }),
  { expiresIn: 12 * 3600 });

MQTT carries the pointer; HTTPS carries the payload. The presigned URL means the device downloads from a private bucket with zero AWS credentials beyond its IoT certificate, the URL is the authorization, and it expires at lunchtime, because news does too. A lifecycle rule deletes the files after a week.

Step 4 — The paper delivery

The Lambda's last act is ringing every pet's doorbell:

for (const thing of things) {  // iot.ListThings
  if (!thing.thingName.startsWith('cloudagotchi')) continue;
  await iotData.send(new PublishCommand({
    topic: `cloudagotchi/${thing.thingName}/briefing`,
    payload: JSON.stringify({ url, headline }),
  }));
}

And EventBridge Scheduler (same service that makes the pet hungry) makes it a morning ritual. Note the timezone-aware cron, a Scheduler feature that classic EventBridge rules don't have:

new scheduler.CfnSchedule(this, 'MorningSchedule', {
  scheduleExpression: 'cron(3 7 * * ? *)',
  scheduleExpressionTimezone: 'Europe/Paris',   // the pet lives where I live
  ...
});

Step 5 — The device: badge, tap, play

On the firmware side, the briefing handler stores the URL and shows an orange banner with the headline, built from the same LVGL vocabulary as part 2 (and it wakes the pet if it was dozing; the paperboy rings). The interesting bit is what happens on tap:

static void on_briefing_tapped(void)
{
    // Audio streaming blocks for ~1 minute: never do that in an
    // LVGL callback, or the whole UI freezes mid-squish.
    // Low priority, pinned to core 1: the download must never
    // starve the Wi-Fi/TCP stack on core 0.
    xTaskCreatePinnedToCore(play_briefing_task, "briefing", 8192, NULL, 2, NULL, 1);
}

...and the entire audio "stack", which streams the WAV chunk-by-chunk so it never needs to fit in RAM:

while (true) {
    int n = esp_http_client_read(http, buf, sizeof(buf));  // 16 KB at a time
    if (n <= 0) break;
    // skip the 44-byte WAV header once, then:
    esp_codec_dev_write(s_speaker, buf + offset, n - offset);  // → speaker
}

That's it. That's the player. HTTP in, codec out, no decoder in between, the dividend of choosing pcm back in step 3. One design decision in a Lambda function deleted an entire firmware subsystem.

The morning after

Deploy, flash, go to bed:

cd backend && npx cdk deploy CloudagotchiNewsStack
cd ../firmware && idf.py flash

At 7:03, the Lambda wakes, reads the feed, writes the script, records the voice, parks the file, rings the doorbell. On the desk, an orange banner slides across the pet's feet: "News! Amazon Bedrock announces..., tap to listen." pet does its proud little squish.

Tap. A tiny, pitched-up voice fills the room with genuine enthusiasm about storage-class pricing.

Four articles ago this was a dev board in shrink wrap. Now it's a creature with a body (LVGL), reflexes (touch + IMU), a memory (DynamoDB), a metabolism (EventBridge), and as of this morning, a job (Bedrock + Polly). Every layer still visible in the code, every layer replaceable without touching the others.

Why this matters

Beyond the whimsy, this article's pipeline (schedule → fetch → LLM transform → TTS → object storage → presigned pointer → thin device) is a genuinely reusable shape. Swap the RSS feed for your CI status, your support queue, or your kid's school newsletter, and the persona prompt for whatever voice should deliver it, and you've got an ambient audio briefing device for anything. The device firmware never changes. That's the quiet lesson of the whole series: put the personality where you can redeploy it.

And if you build one, please, show it to me!

Try it yourself

The Cloudagotchi repo : the finished project is main
Amazon Bedrock Converse API : one API, many models
Amazon Polly SSML reference : prosody is just the beginning
AWS "What's New" RSS : the pet's news source
ESP-IDF HTTP client : the streaming download

Your Agent Toolkit for AWS Cheat Sheet

Ifeanyi O. — Tue, 28 Jul 2026 17:13:01 +0000

Intro

We keep running into the same issue with AI coding agents when building and deploying on AWS. Agents can handle easy tasks well, like spinning up an Amazon S3 bucket or launching an EC2 instance, but when you tasks starts to get complex, say wiring a serverless API with least-privilege permissions or standing up a data pipeline end to end, they do weird things like choosing a service that isn't the right fit for the job, misconfiguring a resource or looping on retries against something they've never seen.

This happens because the model is working from a training snapshot that's weeks to months old, and since then AWS has kept shipping new services and features the model has never seen. So if a task depends on a recently released service or feature, the agent doesn't accurately know how to achieve it..

Today, we've solved that problem with the Agent Toolkit for AWS . It gives your agent a live line to current AWS documentation, tested procedures and a secure way to build and deploy on AWS. It's free to use and you pay only for the AWS resources your agent spins up. Best of all, it supports the coding agents you already use, like Kiro, Claude Code, Cursor and Codex.

Go grab it here, install it locally so your agent can start using today.

The commands below are grouped by when you'll reach for them, from first setup through cleanup. Pin this cheat sheet somewhere handy!

Set up and connect

aws configure agent-toolkitDetects your coding agent and sets up the skills and the AWS MCP Server.

npx skills add aws/agent-toolkit-for-aws/skillsInstalls the AWS skills for MCP-compatible agents.

Find the right skill

aws agent-toolkit list-available-skillsLists every skill in the catalog, so you see the full menu before you install.

aws agent-toolkit search-skills --search-query serverlessSearches skills by topic, so you skip the scroll. Swap serverless for whatever you're building.

Review before you install

aws agent-toolkit get-skill-metadata --skill-name aws-serverlessShows a skill's version, description, and file list before you commit to it.

aws agent-toolkit get-skill-file --skill-name aws-cdk --file-path SKILL.mdPulls a single file so you can read exactly what a skill tells your agent to do.

Install and take inventory

aws agent-toolkit add-skill --skill-name aws-serverlessInstalls one skill on demand, so you add only what the task needs.

aws agent-toolkit list-installed-skillsShows what's installed, on which agent, and where.

Keep current and clean up

aws agent-toolkit update-skill --skill-name aws-serverlessUpdates an installed skill to its latest version.

aws agent-toolkit remove-skill --skill-name aws-cdkRemoves a skill you no longer need.

Try it out yourself

Connect the toolkit, then hand your agent a task like "Create an S3 bucket with versioning enabled and a lifecycle policy that transitions objects to Amazon S3 Glacier after 90 days." Watch what happens now that it's grounded in current AWS knowledge instead of working from memory.

Save this cheat sheet and grab the toolkit here.

What Vibe Coding Skips (And Why Specs Caught It First)

Laura Salinas — Mon, 27 Jul 2026 18:01:13 +0000

I've been watching the discourse around vibe coding explode over the past few months. Developers (and non developers alike!) love the speed. Ship fast, iterate later. Prompt your way to a working prototype in minutes. After trying this myself for several personal projects, I get it!

But... I've also been cleaning up the aftermath. Code that works on demo day or for a basic prototype but falls to pieces the moment you try to extend it. Components that technically render but fight you on every customization. I learned the hard way that speed without structure is just borrowing time from your future self.

I started thinking of it like the difference between sketching on a napkin and working from blueprints. Both get you a picture of a house, but only one of them survives reviews with a building inspector.

In this post I'll walk you through what happens when you build the same feature two different ways: pure vibe coding (prompt, generate, ship) versus Kiro's spec-driven workflow (requirements, design, implement by task). Same feature, same complexity, different outcomes by the end.

The Feature: A Horizontal Scroll Carousel for a Portfolio Site

I have a personal portfolio site (lausalin.dev) that displays my blog posts and videos as large card-style placeholders in a grid layout. Each card takes up significant vertical space, which means visitors have to scroll through a wall of content to see everything. The site used to show 6+ blog cards and 6+ video cards stacked vertically.

The goal: replace those stacked grids with horizontal scroll carousels. Compact card elements that users can scroll through left-to-right, showing 3-4 items at a time with smooth navigation. The vision is Netflix-style content rows instead of a Pinterest-style wall.

The acceptance criteria are identical for both approaches:

Horizontal scrollable container showing 3-4 cards at a time on desktop
Responsive behavior (2 cards on tablet, 1 on mobile with swipe)
Smooth scroll-snap alignment so cards land cleanly
Navigation arrows for non-touch devices
Keyboard accessibility (arrow key navigation within the carousel)
Maintain the existing card content (title, date, read time, thumbnail)
Lazy loading for off-screen card images

This is a UI feature that looks simple on the surface but has real depth once you consider responsiveness, accessibility, and scroll behavior quirks.

Path 1: Vibe Coding It

I opened a chat-based vibe session with Kiro and typed:

"Replace the blog-grid and video grid sections on my portfolio site with horizontal scroll carousels. Show 3-4 cards at a time, add navigation arrows. Site should be responsive both on web and mobile."

In about 3 minutes I had a working local render. Horizontal scroll container, CSS scroll-snap, arrow buttons, the whole thing.

Ship it, right?

Several problems hid in that rough draft:

No scroll-snap edge cases handled. The CSS scroll-snap-type: x mandatory worked for the default viewport width, but at certain breakpoints the snap points misaligned with the card widths. Cards would land half-visible with no way to reach the snapped position.

Accessibility was an afterthought. The arrow buttons had no aria-label. The carousel had no role="region" or aria-roledescription. Keyboard users couldn't navigate between cards. Screen readers announced nothing useful.

Touch and mouse scroll conflicted. On trackpad, horizontal scroll worked. On touch devices the swipe gesture competed with the page's vertical scroll, creating a janky diagonal movement.

No loading strategy. All card images (including ones five scroll-lengths offscreen) loaded on page init. On mobile connections this meant 2+ seconds of layout shift as images popped in.

It worked fine enough for the ~5 minutes of effort. But every device I tested afterward revealed a new edge case that would've required going back into the prompting and iterating repeatedly (AKA: more token consumption and additional time waste)

Here's a screenshot of what we had from the vibe coded local render:

Path 2: Kiro's Spec-Driven Workflow

Same starting intent. I opened Kiro, toggle on "Spec Mode" and described the feature: "Replace the blog-grid and video grid sections on my portfolio site with horizontal scroll carousels." But instead of jumping straight to code, this time Kiro generated a requirements document following the requirements-first workflow.

Step 1: Requirements Spec

Kiro produced requirements using EARS notation:

I reviewed these before any code existed and caught a gap I hadn't considered: my original prompt said nothing about what happens at the ends of the carousel. Should the arrows disable? Should the scroll wrap? The local vibe coded render hadn't accounted for the end of the carousel. As it stood, nothing happened when a user clicked past the last loaded media.

I added a requirement for that behavior. In vibe coding, I didn't (and wouldn't) have noticed this behavior until a user clicked the right arrow on the last card and nothing happened.

Step 2: Technical Design

Kiro also produced a design doc with the following:

Key design decisions:

Uses native CSS scroll-snap for touch/swipe settling rather than custom JS animation
A single shared carousel.js module works across all three card types (blog, video, events)
Pure computational core (CarouselMetrics) is separated from the DOM controller so it can be property-tested without a browser

Architecture (3 layers):

Renderers: existing functions that build card markup (unchanged responsibilities)
DOM controller (initCarousel): builds nav buttons, measures layout, binds events, manages ARIA
CarouselMetrics: pure functions for card sizing, step distance, edge detection, snap targets

Responsive behavior:

Desktop (>640px): 2+ whole cards visible
Mobile (≤640px): 1 full card + peek of next (10-40%)
Very small (<240px): single full-width card

Accessibility: ARIA region/roledescription, live announcements ("Showing X–Y of N"), keyboard operable (Enter/Space on arrows), focus management with scrollIntoView, reduced-motion support via prefers-reduced-motion

Error handling: fetch timeouts (10s), graceful empty states, malformed data resilience, non-interactive cards when URL is absent

Step 3: Implementation Tasks

The final phase of the spec-driven approach is the breaking down of the design doc into discrete, ordered tasks.

Each task maps back to specific requirements. When I accept them, Kiro implements them one at a time (or all at once if I prefer), verifying each against the spec before moving to the next.

The Result

Major changes I noted from vibe to spec for this site:

Responsive by design, not by patch. CSS custom properties (--card-width, --cards-visible, --card-gap) recalculate per breakpoint. One source of truth instead of scattered magic numbers.
Accessibility built in from task 5. role="region", aria-roledescription="carousel", aria-label on each card, roving tabindex, arrow key handlers that sync scroll position with focus.
Touch scroll isolation. overscroll-behavior-x: contain on the container, combined with a threshold-based gesture detector that only activates horizontal scroll after 15px of horizontal movement (preventing diagonal jank).
Lazy loading with Intersection Observer. Cards get placeholder dimensions immediately (no layout shift), images load when within one viewport-width of visible area.
Arrow state management. A scroll event listener calculates position and disables arrows at boundaries. Debounced to avoid performance hits during momentum scrolling.

Did it take longer? Yes. Roughly 30 minutes from prompt to full spec versus 5min from vibe to local render. But the difference in catching the scroll-end behavior gap, the touch gesture conflict, and the accessibility requirements before they became bugs discovered by users was worth it for me.

The Side-by-Side

Dimension	Vibe Coding	Kiro Spec-Driven
Time to first render	⚡ ~5 minutes	⏱️ ~30 minutes
Works on desktop Chrome	✅ Yes	✅ Yes
Works on mobile Safari	⚠️ Diagonal scroll janky	✅ Smooth
Keyboard navigable	❌ No	✅ Full arrow key support
Screen reader usable	❌ Silent	✅ Announces card content
Handles viewport resize	⚠️ Breaks at 1000px	✅ Recalculates cleanly

The first-render speed difference isn't marginal, and having to fix all the issues that came up after would've taken longer depending on when they were discovered (if at all). The gap shows up quickly the moment you test beyond the happy path with a different browser, a different screen size, a keyboard user, a slow connection, etc.

When Vibe Coding Is the Right Call

One thing to get clear: I'm not here to say vibe coding is always wrong. It's a still a valid approach for many scenarios that I've found myself in such as:

Prototypes which you'll delete after validating an idea
Hackathon projects where shipping fast IS the actual goal
Exploratory spikes to test if an approach even works before investing in it
Scripts you'll run once and never look at again
Learning a new framework where the code itself is disposable

The moment you plan to deploy something users will actually interact with, especially across different devices, with different abilities, and on different connections, that's when I've found the time invested in specs earns its keep.

In this relatively simple UI improvement for my website, if I just wanted to confirm that CSS scroll-snap could handle the layout before committing, vibe coding is perfect for that test. But the version going on my live site? That needs the spec to make sure the edge cases are covered.

Final Takeaway

Vibe coding treats code as the primary artifact. You prompt, you get code, done.

Kiro treats the spec as the primary artifact. Code is a build output from that spec and this can be a meaningful shift for some folks. It means:

Requirements are explicit and reviewable, not trapped in chat history or your head
Edge cases surface during spec review, not after deployment when a user on an iPad reports the bug
Changes start at the spec level, not at the code level. When I later want to add an "Events" carousel, I update the spec and Kiro generates a new component that inherits all the accessibility and responsive work from the original

For anyone who has shipped a "simple" UI component only to spend the next week fixing device-specific edge cases, this front-loaded approach pays for itself fast. Especially when you get down to the bottom of how much each roundtrip conversation with the agent can cost if you spend the entire time vibe coding.

The Kiro free tier gives you 50 credits per month with no credit card. That's enough to run this experiment on a real feature. Download Kiro here and check out the difference for yourself.

Additional Resources 📚

Agents Vs Scripts. Which Should You Choose?

Ifeanyi O. — Mon, 27 Jul 2026 17:51:46 +0000

Intro

When someone wants to automate a boring and repetitive task, like triaging support emails, or renaming files the instinct now is "I'll build an agent for this."

What's crazy is, two years ago, you would have written a 30-line script and called it a day.

Today, agents are the new fun thing to build but people seem to have forgotten that a plain script can handle a lot of work many are building agents to do so knowing which one to chose to achieve a task will save you time, money and a lot of debugging. In this blog, I'll walk you through making an agent vs. script decision with an automated task.

We'll build on this task three ways to figure out which one you actually need. Let's review the task below:

You run a small SaaS company and the support inbox is currently piling up. You want incoming email sorted on its own so billing questions get routed to the billing team, bug reports route to the engineering team, and the "I want to cancel" ones get flagged before that person churns.

Definitions

People throw agents at anything that touches an LLM, so before we start comparisons, let's learn how a script and agent function based on who controls the flow.

In a script, you decide the control flow. In an agent, the model decides the control flow at runtime.

A script can call an LLM ten times and still be a script, because you wrote the order those calls happen in. However, with an agent, you hand the model a set of tools and a goal, and it decides what to call, in what order and when the job is done. There isn't a strict known path ahead of time.

The script

Let's start with the simplest thing that could work.

import re

RULES = [
    (re.compile(r"\b(refund|invoice|charge|billing|payment)\b", re.I), "billing"),
    (re.compile(r"\b(error|crash|broken|bug|500|not working)\b", re.I), "engineering"),
    (re.compile(r"\b(cancel|downgrade|unsubscribe)\b", re.I), "retention"),
]

def triage(email: str) -> str:
    for pattern, team in RULES:
        if pattern.search(email):
            return team
    return "unsorted"

This is a list of keyword rules, where each rule holds a set of words and the team those words point to. Triage checks the email against each rule from top to bottom so the first one that matches returns its team, and anything that doesn't match anything falls through to unsorted.

This script runs in microseconds, virtually doesn't cost anything and routes the same email the same way every time, which means that if it sends an email to the wrong team we can see exactly which rule fired and fix that one line. On top of that, we can test it and read it in a single glance.

Now let's look at a more realistic scenario. One morning a customer sends in a message like this:

"Hey, every time I hit the pay button the whole thing just dies on me."

This is a real bug report email, but look at the words in it. The customer says "pay button" and "dies on me," but the billing rule only matches the full word "payment," never "pay," while the engineering rule is watching for "crash" or "broken" or "error," not "dies." None of these match the rules, as a results this crash report will drop into unsorted where no one on billing or engineering teams can review it.

We cannot classify this as bug in the code, since the code did exactly what we told it to. However, the issues is that the task overlooks steps we can't write down as rules like working out what the person actually meant by understanding the context.

Since there are endless ways to phrase the same request, a regex only knows the handful of patterns you fed it. We can keep bolting on new keywords, but that's just playing whack-a-mole against the whole English language, chasing one keyword at a time, which is a very tedious manual effort on a codebase that'll keep growing without real gain.

Keywords in code will never be context ware and understand meaning, however, that's actually the one job a model does well at. This is where we start thinking about maybe moving from a script to an agent.

The agent

For an agent, we hand the model a set of tools and let it manage the whole ticket process end to end using it's many tools. A tool is just a normal function you write (which can be arguable also just a script) like, look up a customer, open a bug ticket or send a reply, which you make available to the model so it can run that function itself when it decides it needs to. However, you're not calling these functions in a fixed order like you would in a script, instead you're handing them over and letting the model choose which ones to use.

tools = [
    look_up_customer,      # find the account from the sender's email
    get_recent_orders,     # pull their billing history
    issue_refund,          # actually move money
    create_bug_ticket,     # open a Jira/Linear issue
    reply_to_customer,     # send an email back
    escalate_to_human,     # punt to a person
]

agent = Agent(model="...", tools=tools, system=TRIAGE_POLICY)
agent.run(f"Handle this support email:\n\n{email}")

From the list above, each line is one of those functions, and the comment beside it explains what the function does, so the model has six functions, from looking up who sent the email to issuing an actual refund.

Now, the model can run its own loop, read the email, decide to call look_up_customer, read the result, work out that the charge was a genuine double-bill, call issue_refund, then reply_to_customer, then stops.

It can also read the same email, decide it's above its pay grade and call escalate_to_human on the very first step. What's key here is you never needed to direct and hard code either of those paths, the model was able to autonomously make decisions to pick them at runtime.

The model handles the double-bill-crash email without breaking a sweat because it's reading the and understanding the context of the message instead of matching patterns. So for an open-ended task where you genuinely can't list all the branches up front, this is an approach more appropriate for an agent.

This approach is also not perfect, as we now handed a probabilistic system a tool called issue_refund that manipulated actual money. Since models are non-deterministic systems, some fraction of the time it's going to call that tool on a ticket where it shouldn't, because every capability you give an agent is another way for it to be confidently wrong at scale when making it's own decisions.

Pitfalls of using Agents

"Agents are expensive" gets repeated a lot, but it's too vague to make a real decision on, so let's break down what you're actually paying for.

The first is latency. The regex script executes in microseconds and a single model call runs somewhere between a few hundred milliseconds to a couple of seconds. However, an agent that takes 6 tool-calling round trips, for each step has to waits on the model, the tool, like a database query or an API, feeding the result back and waits on the model all over again.

Ten seconds to triage one email is not the end of the world especially if it's a background queue job, but for anything a person is sitting waiting on, this is not ideal.

Closely tied to latency is cost. An agent doesn't pay once per step, it pays for the entire conversation again on every step. On turn one the model reads the email, on turn two it re-reads the email plus its first decision and the tool result, then by turn six it's re-processing everything that came before on every single turn. Token usage grows roughly quadratically with the number of steps rather than linearly, so a task you pictured as "a few cents" can grow quickly once it's looping through tools on every ticket, multiplied by your daily volume.

Then there's determinism, or the lack of it. The same email can route two different ways on two different runs, and setting temperature to zero can help but it doesn't solve it, because tool results feed back into the context and shift the next decision, also a model version update can change the behavior overnight. For triaging, you can just shrug those off, but for anything consequential like money transactions or data deletion, non-determinism is a liability.

The last one is "debuggability". When the regex mis-routes, you get a stack trace pointing at a line, but when an agent mis-routes you have to sit and interpret a transcript of a conversation and it might not even be reproducible on the next run with the exact same input. You also don't debug an agent with a breakpoint, you debug it with tracing, eval sets and guardrails, which is a whole discipline that's you're responsibility.

This doesn't mean you should avoid agents, it just means you need to understand what you're taking on when an agent operates inside a system that runs critical operations.

The middle ground

Let's go back to why the script broke. It broke when trying to understand what the email meant, everything else, routing, priority logic, deciding who gets paged, was fine as plain code. So we don't actually have to replace the whole script for an ideal workflow, we just need to swap in a model on the one step that broke and leave the rest alone.

from pydantic import BaseModel
from typing import Literal
from openai import OpenAI

client = OpenAI()

class Triage(BaseModel):
    team: Literal["billing", "engineering", "retention", "other"]
    priority: Literal["low", "medium", "high"]
    reason: str

def triage(email: str) -> Triage:
    resp = client.responses.parse(
        model="gpt-5",
        input=[{"role": "user",
                "content": f"Triage this support email.\n\n{email}"}],
        text_format=Triage,
    )
    return resp.output_parsed

Now, instead of letting the model reply with a paragraph you'd have to pick apart, you hand it a shape to fill in, a team, a priority and a short reason, and you get back a typed object with exactly those fields.

The model here only answers a question, what is this email about, and it doesn't touch a single tool. It never looks up the customer, opens a ticket, or issues a refund. It just reads the text and hands back three fields then your code takes over from there.

It reads the double-bill-crash email and returns engineering and high with a reason attached, because this time it understood the message rather than trying to "grep" it for keywords. As for the accounting request that used to vanish into unsorted, it now gets read and sorted like every other email.

We've made changes to our script an incorporated a model but what's most important here is that you still own the control flow.

result = triage(email)

route_to(result.team)
if result.priority == "high":
    page_on_call()
log_triage(email_id, result)

Since there's no loop, there's no way for this to issue_refund, because you never gave it the ability to, it can only fill in the fields you defined. Cost is one bounded call per email, and latency is one round trip.

It's not fully deterministic, the model can still mis-categorize, but the blast radius of a wrong answer is "email went to the wrong queue," not "money left your account." When it's wrong, you log the input and the output, look at them side by side, and adjust the prompt or the schema. That's a debugging process you can actually live with.

This is the answer for the overwhelming majority of "should I use an agent" tasks. You don't always need a model to drive, but you can leverage to handle the steps your code can't, then hand control right back.

So, which one should you choose?

Here's the decision I actually run through, in order:

Can you write down every step and every branch ahead of time? If yes, write a script, and don't add an agent just to feel modern.
Is there exactly one step you can't express as code, usually "understand this messy input" or "generate this text?" Then it's a script with model calls inside it, structured output and a typed result with your code still deciding what happens next. This is the sweet spot and is somehow underused today.
Does the task genuinely require deciding what to do and in what order based on information you won't have until runtime, across multiple tools, where you can't enumerate the paths? This is where you need to build an agent. Give it the narrowest set of tools that works, put a human in front of anything irreversible and set up tracing and evals from day one.

For our support inbox, the best answer is option two. A model reads the email and your code does the rest. The day you want the system to actually resolve tickets, look up the order, judge whether the refund is warranted, draft the reply and decide when a human needs to step in, then you'll need to use an agent and a very sophisticated one at that.

7 Kiro Features You're Probably Not Using

Erik Hanchett — Mon, 27 Jul 2026 15:39:49 +0000

Did you know that Kiro doesn't just have a Spec-Driven Development (SDD) flow, but also a bug fix workflow that helps you resolve one issue at a time? That's one of seven features worth knowing about.

If you're completely new to Kiro, it's an agentic harness for the CLI, web, IDE, iOS, and more. It helps teams and individuals do their best work while coding. I've been using it since it launched in July last year, and I keep finding features I didn't know were there.

(Full disclosure: I'm a Developer Advocate at AWS, and Kiro is a part of AWS. I use it every day, and I'll be forthcoming about the parts that are still preview or experimental.)

Heads up: Kiro ships fast. I've flagged the version-sensitive bits of these features inline. Check the docs if something looks different in your build.

1. Stop approving every single command

After talking to a lot of people about Kiro, one of the main pieces of feedback I get is on approving commands. When Kiro asks permission to run a shell command, the default reaction is to hit yes and move on. Then it asks again for the next git command. And the next one.

Press Tab instead in the CLI. This allows you to edit it and put the exact permissions you'd like. For example you can be pickier on the trust tiers:

git pull --rebase     # this exact command
git pull *            # git pull with any arguments
git *                 # anything git
*                     # the entire shell tool

Whatever you pick persists for the session and gets stored as a regex in your agent's allowedCommands.

There's also /tools trust-all, which trusts everything. It's the documented replacement for the old /acceptall, and the security docs are blunt about it: don't use it in production or with sensitive data, and you're responsible for whatever it does.

One version note: on CLI v3 this moves to a permissions.yaml file, so the agent JSON advice above is v2. More on v3 in a minute.

Full details: tool permissions

2. The `#` menu is bigger than `#file` in the IDE

Type # in the IDE chat and you get a list of context providers. #file is the one I use a lot. The full list:

#codebase · #file · #folder · #git diff · #terminal · #problems · #url: · #code: · #repository · #current · #steering: · #docs: · #spec: · #mcp:

You can stack them in a single message. #git diff #problems review my changes is a different request than either one alone.

The one I've been using more is the #terminal. It hands Kiro your recent terminal output and command history, so you stop copying and pasting errors:

#terminal why did this build fail

One thing I find handy is the "#Currently Open files." However, keep in mind that Kiro pulls in your open files and their dependencies automatically without you asking.

Full list: context providers

Also you can't drag a file in the IDE's own explorer to the chat window, however you can copy and past the location of the file and past that into the chat window as a workaround.

3. Pick a workflow instead of freeform chatting

Kiro gives you structured starting points, and it's tempting to just start typing into the chat box instead. Instead you can choose any of these in the IDE.

Spec for a full feature, with requirements, design, and tasks
Plan when you want an implementation plan and zero code changes
Bug Fix to investigate, diagnose, and resolve one problem
Quick Spec when you want Kiro to ask a couple of clarifying questions and then generate the requirements, design, and tasks for you

Bug Fix is the one I'd try first. It writes down current behavior, expected behavior, and unchanged behavior. I like how it doesn't change a bunch of files it shouldn't. It basically tells the agent what it is not allowed to touch.

On a feature spec you also get a choice between requirements-first and tech design-first. If you already know your architecture, pick design-first. There's no reason to answer requirements questions you already have answers to.

4. Skills are slash commands

Kiro activates a skill automatically when your prompt matches the skill's description. That works, but I feel like it doesn't always automatically activate.

You can invoke one directly instead. Skills in .kiro/skills/ or ~/.kiro/skills/ show up as slash commands, so a skill named pr-review becomes:

/pr-review

That loads the entire instruction file, not just the description. Works in the CLI and the IDE.

Powers are a different thing and worth knowing about separately. A power bundles MCP server config with steering and optional hooks, and Kiro loads it only when your task is relevant to it. Powers are keyword-activated, and they're free on every plan.

5. You might be running an old build

Open Help > About and check your version against kiro.dev/downloads.

Kiro's own changelog says auto-updates were paused for IDE 1.0.x and tells you to download the latest release directly from the site. So if your version doesn't match what's on the downloads page, that's why, and no amount of restarting will fix it. Reinstalling keeps your settings, extensions, and sign-in state.

On the CLI:

kiro-cli --version
kiro-cli update
kiro-cli doctor      # install and config problems

And /changelog in the CLI inside a chat session shows the release notes inline, which is a nicer way to find out what shipped than scrolling a webpage.

6. The work doesn't have to run on your laptop

One subscription covers the IDE, the CLI, Kiro on the web, ACP-compatible editors, and automation in CI/CD. Same credit pool.

I really like the web version. You kick off a session, it runs in a cloud sandbox, and it opens the pull request when it's done. Your laptop can be closed. There are also Automations, which are cron-scheduled agent runs that open PRs on their own.

Web is still in preview, gated to Pro and above, and it needs a connected GitHub account. There's an iOS app too, but it's early access via TestFlight, Pro or higher, and it's a surface for starting and reviewing cloud sessions rather than an editor. No Android yet.

7. The experimental stuff is opt-in and worth trying

Three of these are behind a flag or a toggle.

CLI v3. Run kiro-cli --v3 and it runs alongside your existing 2.x setup without touching it. You get the spec agent in the terminal:

kiro-cli --v3
/spec new my-feature

Plus capability-based permissions.yaml, standalone hooks in .kiro/hooks/*.json, and markdown agent configs. See the v3 docs for the full list of features.

Agent Focus in the IDE. Toggle it from the button in the top right. The layout flips: parallel sessions down the left, chat in the middle, specs and diffs in a panel on the right. It's a different job than editing files. You're directing several agents and reviewing what they produce. Settings, powers, MCP management, the terminal, and direct file editing all still live in the normal view, so you'll toggle back and forth.

/goal. Give it an objective and a definition of done, and it loops implement-then-verify until the criteria are met:

/goal Migrate the auth module to the new SDK. Done when all tests pass and there are no TypeScript errors.

This is available in v3 CLI.

Default is five iterations, --max <n> raises it, /goal clear cancels. The docs are right that the definition of done is the part that matters. "All tests pass" works. "Make it better" does not. You can interrupt mid-loop, or nudge it without cancelling using queue steering with Ctrl+S.

A few more worth a mention

While I'm listing CLI commands: /rewind forks the conversation at an earlier turn instead of you fighting a thread that went off the rails, and the original session is preserved. /compact summarizes history to free up context. /tangent (Ctrl+T) lets you run commands on the side (like /btw in Claude). /guide is a docs-grounded agent for "how do I do X in Kiro" questions, and it can write agents, prompts, and steering files into .kiro/ for you.

If Shift+Enter for multi-line input has been annoying you, /settings terminal fixes it and backs up your terminal config first.

Where to go when you're stuck

The Kiro Discord is the main support channel, and there's an active subreddit at r/kiroIDE. Note the name, it's kiroIDE, not r/kiro. Billing lives in your account settings. Bugs and feature requests go to the GitHub repo, and /issue in the CLI opens that workflow for you. If you need to send logs along with a bug report, /logdump zips them up.

Which of these did you not know about? Let me know in the comments. Until next time.

Cloudagotchi Part 3 : It gets hungry while you sleep: A serverless pet brain

Olivier Leplus — Mon, 27 Jul 2026 13:14:36 +0000

At the end of part 2, our pet had a face, reflexes, and a serious philosophical problem: no memory. You could pet it a hundred times, reboot the board, and it woke up with the same hardcoded stats, feeling nothing, remembering nothing. Every day was its first day.

Today the pet gets what every Tamagotchi fundamentally is: a state machine with feelings. Its hunger, energy and mood become rows in DynamoDB. A Lambda decides how a snack or a shake changes them. And, the part I find genuinely delightful, EventBridge Scheduler makes time pass, so the pet gets hungry overnight while the device is completely powered off. When you flash the firmware Monday morning, the pet wakes up, asks the cloud "what did I miss?", and gets visibly sad about the answer.

In this article, I will walk you through the whole brain: the data model (it's one table with one row per pet... gloriously boring), the decay math that makes offline time count, IoT rules that invoke Lambda without a single line of polling code, and the loop back down to the device.

⚠️ Reality check (sorry 😅): there's a Scan in this article. A full-table Scan, in production-adjacent code, published on the internet under my name. It's the right call for a fleet of three pets and I'll explain the honest scaling path when we get there, but if your DynamoDB instincts just twitched, I respect you, and I ask you to hold that thought until the 💡 box.

Code for this article: git checkout article-3.

The architecture, now with a brain

Two Lambdas, one table, one schedule, two IoT rules. The entire brain deploys with cdk deploy and costs approximately nothing (the decay Lambda runs 48 times a day; the free tier laughs at this).

The data model: one row of feelings

Every pet is one item in DynamoDB:

{
  "deviceId": "cloudagotchi-01",
  "hunger": 62,
  "energy": 71,
  "mood": 45,
  "updatedAt": 1752192000000
}

That's it. No GSIs, no sort keys, no single-table-design galaxy brain. The partition key is the thing name from part 1, and updatedAt is the timestamp that makes everything else in this article work.

The CDK for it is appropriately tiny:

const table = new dynamodb.Table(this, 'PetState', {
  tableName: 'cloudagotchi-pets',
  partitionKey: { name: 'deviceId', type: dynamodb.AttributeType.STRING },
  billingMode: dynamodb.BillingMode.PAY_PER_REQUEST,
  removalPolicy: cdk.RemovalPolicy.DESTROY,  // it's a pet, not a bank
});

The rules of life: pure functions first

Before any AWS SDK calls, the pet's biology lives in pet-logic.mjs, pure functions, no I/O, trivially testable:

// Stats decay per hour of real time. Tuned so a full day of neglect
// makes the pet visibly sad — without starving it to zero over a weekend.
const DECAY_PER_HOUR = { hunger: 2, energy: 1.5, mood: 1 };

// What each interaction does.
const INTERACTION_EFFECTS = {
  feed: { hunger: +30, energy: +5,  mood: +5 },
  pet:  { hunger: 0,   energy: 0,   mood: +10 },
  play: { hunger: -10, energy: -15, mood: +20 },  // fun is exhausting
};

And here's the single most important function in the whole project. Not a scheduled job, a calculation:

/** The cloud remembers, so the pet ages even while powered off. */
export function applyDecay(pet, now) {
  const hours = (now - pet.updatedAt) / 3_600_000;
  return {
    ...pet,
    hunger: clamp(pet.hunger - DECAY_PER_HOUR.hunger * hours),
    energy: clamp(pet.energy - DECAY_PER_HOUR.energy * hours),
    mood:   clamp(pet.mood   - DECAY_PER_HOUR.mood   * hours),
    updatedAt: now,
  };
}

Here's the part that trips people up about "time passing" in serverless systems: you don't need a process running to make time pass. Time passes for free, you only need to account for it whenever you next look. applyDecay computes elapsed hours since updatedAt and applies them, whether that's 30 minutes (scheduler tick) or a weekend (you went camping, the pet noticed).

Finally, three stats collapse into one face for the device to render:

export function moodOf(pet, hourOfDay) {
  if (hourOfDay >= 22 || hourOfDay < 7) return 'sleeping';
  const worst = Math.min(pet.hunger, pet.energy, pet.mood);
  if (worst > 60) return 'happy';
  if (worst > 30) return 'neutral';
  return 'sad';
}

Math.min : the pet's outlook is determined by its worst stat, not its average. As a design decision this is straight from the Tamagotchi school: you can't cuddle your way out of starvation. 😝

From MQTT to Lambda: IoT rules

How does a {"type":"feed"} on an MQTT topic become a Lambda invocation? IoT rules, SQL statements (yes, SQL) that run against the message stream:

new iot.CfnTopicRule(this, 'InteractionRule', {
  ruleName: 'cloudagotchi_interactions',
  topicRulePayload: {
    sql: `SELECT *, topic(2) AS deviceId, topic(3) AS kind
          FROM 'cloudagotchi/+/interaction'`,
    actions: [{ lambda: { functionArn: onInteraction.functionArn } }],
  },
});

Two tricks earn their keep here:

topic(2) extracts the second topic segment (the device's thing name) and injects it into the event as deviceId. The device never has to say who it is in the payload, which means a buggy (or malicious) device can't claim to be a different pet. Identity comes from the topic, and part 1's policy already guarantees a device can only publish on its own topics. The security work we did in article 1 quietly pays rent here.
The + wildcard means one rule serves every pet, current and future. Provision a hundred devices; deploy nothing.

There's a twin rule on the hello topic, pointing at the same Lambda.

The interaction Lambda: load, decay, apply, save, reply

The handler reads like the pet's inner monologue:

export const handler = async (event) => {
  const { deviceId, kind, type } = event;   // injected by the IoT rule SQL
  const now = Date.now();

  // 1. Load the pet, or meet it for the first time.
  const { Item } = await ddb.send(new GetCommand({ TableName: TABLE, Key: { deviceId } }));
  let pet = Item ?? newbornPet(deviceId, now);

  // 2. Time passed since we last looked. It always does.
  pet = applyDecay(pet, now);

  // 3. A "hello" just wants the current state; an interaction changes it.
  if (kind === 'interaction') {
    pet = applyInteraction(pet, type);
  }

  // 4. Persist, then tell the device what it now feels.
  await ddb.send(new PutCommand({ TableName: TABLE, Item: pet }));
  await publishState(pet);
};

Step 2 is doing quiet heavy lifting: because every code path decays first, the pet's state is always correct-as-of-now, no matter which event arrived or how long it's been. The hello flow (device boots, publishes hello, Lambda answers with fresh state) is the same code path as feeding, minus one if. "What did I miss?" is just "load + decay + reply."

The reply goes back down over MQTT via the IoT data plane:

await iot.send(new PublishCommand({
  topic: `cloudagotchi/${pet.deviceId}/state`,
  qos: 1,
  payload: JSON.stringify({ hunger, energy, mood, face: moodOf(pet, hour) }),
}));

EventBridge Scheduler: the heartbeat of the universe

One question remains: if nobody interacts and the device never says hello, who makes the pet sad? This does:

new scheduler.CfnSchedule(this, 'DecaySchedule', {
  scheduleExpression: 'rate(30 minutes)',
  flexibleTimeWindow: { mode: 'OFF' },
  target: { arn: decay.functionArn, roleArn: schedulerRole.roleArn },
});

Every 30 minutes, the decay Lambda sweeps all pets, ages them, and pushes fresh state to any device that's listening:

export const handler = async () => {
  const { Items = [] } = await ddb.send(new ScanCommand({ TableName: TABLE }));
  const now = Date.now();

  for (const pet of Items) {
    const aged = applyDecay(pet, now);
    await ddb.send(new PutCommand({ TableName: TABLE, Item: aged }));
    await publishState(aged);  // offline device? IoT drops it; the
                               // "hello" on next boot catches it up.
  }
};

💡 About that Scan (deep breath). For a hobby fleet, a 48×/day scan of a table with single-digit rows is free and honest. At real scale you'd flip the model: don't sweep, don't even store decayed values: store only updatedAt plus the stats at last interaction, and compute decay on read (we already do!). Then the scheduled sweep exists solely to push updates to online devices, and you'd drive it from the list of connected things instead of the whole table. The lazy-evaluation trick in applyDecay is the scalable part; the Scan is the shortcut bolted onto it. Know which is which and you can ship both.

Closing the loop on the device

The firmware's on_cloud_message callback from part 1 finally has a job, parse the state and hand it to the face from part 2:

cJSON *json = cJSON_ParseWithLength(payload, len);
pet_ui_set_state(hunger->valueint, energy->valueint,
                 mood->valueint, mood_from_string(face->valuestring));

Fifteen lines of cJSON (in the repo), and the loop is closed: DynamoDB is now the pet's soul, the screen is just its face.

The payoff

Deploy and flash:

cd backend && npx cdk deploy CloudagotchiBrainStack
cd ../firmware && idf.py flash monitor

Now run the experiment that justifies this whole architecture. Tap the pet, the bars nudge up (device → rule → Lambda → DynamoDB → MQTT → face, ~200 ms round trip). Then unplug the board. Go live your life for a day. Plug it back in and watch the boot sequence: hello goes up, and the state that comes back reflects every offline hour. The pet's smile flattens. Its hunger bar sits noticeably lower. It missed you, and it has the DynamoDB row to prove it.

I'm not saying I felt guilty. I'm saying I fed it immediately.

Why this matters

Strip away the pet and what we built is the canonical pattern for cloud-authoritative device state: device sends events, cloud computes truth, truth flows back down, and lazy time-accounting on read replaces any always-running process. That's a smart thermostat's schedule, a subscription's billing period, a game's energy system, an IoT sensor's calibration drift. The Tamagotchi version just has better animations.

Our pet now has a body, reflexes, memory, and consequences. One thing left in the series, and it's the one I've been saving: giving it a job. In part 4, the pet fetches the AWS news every morning, has Amazon Bedrock rewrite them in its own voice, and reads them to me out loud through Amazon Polly. My Cloudagotchi becomes my news anchor. 📰

Try it yourself

The Cloudagotchi repo : git checkout article-3
AWS IoT SQL reference : topic() and friends
EventBridge Scheduler docs : cron for your serverless universe
DynamoDB data modeling : for when your pet fleet IPOs

The AWS Cleanup We Keep Putting Off (I Let an Agent Do It)

Rohini Gaonkar — Thu, 23 Jul 2026 15:49:22 +0000

It started with a billing alert.

Estimated charges had crossed $250. Not scary money, but enough to make me look. And what actually caught my attention wasn't the number, it was the alert itself. I'd clearly set this up at some point, and the threshold felt stale.

So I went looking for where the alert lived.

It came from a BillingAlerts CloudFormation stack I created back in 2014 and completely forgot about. So a thing I forgot about was warning me about all the other things I'd forgotten about.

I opened my stack list and that's when I saw it wasn't alone. It was sitting in a lineup of stacks, and I didn't recognise half of them. Years of leftovers, just sitting there.

The stuff you forget about doesn't break anything. It doesn't page you at 2am. It just sits there, quietly billing, until you glance at the invoice and can't remember what half of it is for. Forgotten, still-running resources are one of the biggest sources of wasted cloud spend, by some estimates around a quarter of the average cloud budget.

I came to update one alert and I found a mess.

To be clear, these stacks weren't really costing me much. Stopped instances, a few half-deleted leftovers. If they'd been the $252, the alert would've tripped every month. But that's the point. You can't tell what's actually costing you until the clutter is gone.

So the alert could wait. I wanted these stale stacks gone first.

Normally this is a chore. Open the console, find each stack, click delete, wait, refresh, check if it worked, OR write out CLI commands. It's not hard, just tedious. The kind of task I keep putting off.

And that's exactly how this started. ClickOps through the console. I'd just finished deleting an old Directory Service directory over in the Mumbai region by hand, clicking through the screens and waiting out the spinner, when it hit me. Barely ten minutes of manual clicking, and I still had a pile of stacks to go. I didn't have to do any of this myself.

Why was I still clicking?

I opened Kiro, which has the Agent Toolkit for AWS, and just described what I wanted. I talked about how I set it up earlier in my blog I Switched to the Agent Toolkit for AWS. Here's Why.

No console. No CLI. I had a chat with the agent and let it take care of the rest. Like a good assistant!

If you have AWS CLI installed, just run:

aws configure agent-toolkit

It will let you select agents to configure with Agent Toolkit:

First, show me what's there

I started by asking the agent to list my CloudFormation stacks in my region.

It came back with 12 stacks. Some I recognised, while some were ancient, a billing-alerts stack from 2014, a few patching and compliance stacks from 2021, the CDK bootstrap toolkit. And then the ones I actually wanted gone.

I picked and told the agent to delete four of these stacks.

It asked before it deleted

This matters, so I want to call it out first.

The agent didn't just start deleting things the moment I asked. Before it ran anything, it listed the four stacks back to me, told me plainly that this would remove all their resources and couldn't be easily undone, and asked me to confirm.

Deleting infrastructure is not reversible.

I said go and then it acted.

I got the speed of "just handle it" without giving up the checkpoint on a destructive action.

It checked the result as code, no refreshing the console every second

Once the delete requests were in, the agent wrote a script and ran it in the toolkit's sandbox to check the status of all four at once.

It checked all four in parallel, handled the case where a stack might already be gone, and gave me back a clean status map. All of it ran in a remote sandbox with boto3. My machine never executed any of it.

Three deleted cleanly but one refused.

The fourth stack, aws-sam-cli-managed-default, came back DELETE_FAILED.

So, the agent pulled the stack events to find out why. The failure pointed at one resource, the S3 bucket SAM uses for deployment artifacts (SamCliSourceBucket). The message was specific:

The bucket you tried to delete is not empty. You must delete all versions in the bucket.

This bucket had versioning enabled. So "empty the bucket" isn't enough. Every object version and every delete marker has to go, or CloudFormation still can't remove the bucket. That's why a quick "empty" in the console sometimes doesn't fix it.

The agent explained the cause, then offered to empty the bucket properly and retry. I said yes.

That whole detour, remembering the versioned-bucket gotcha, hunting down the bucket name, realising delete markers count too, emptying it manually, then coming back to retry, is the part I'd normally slog through myself. The agent connected the failed delete to the full bucket and just handled it.

All four gone.

Why this felt different

Let me be clear about what actually changed here, because "I used AI to delete some stacks" is not the point.

The point is the whole loop stayed in one place. I described the goal in plain language. The agent listed the real state of my account, confirmed the destructive step, ran the code to do it, and then debugged and fixed the one thing that broke without me digging through docs.

A few things made that possible:

It ran real code, safely. The toolkit gives the agent a sandboxed Python runtime with boto3. It can check state, filter, and act in a few lines, without running anything on my laptop.

It confirmed the risky part. Deletes are one-way. The agent treated them that way and checked with me first.

It handled the failure end to end. The console wouldn't have left me stuck here. On a DELETE_FAILED, it pops up and lets me retry, either retaining the bucket (orphaning it in my account) or bouncing over to the S3 console to empty it myself. Both are context switches, and "retain" just leaves the bucket behind. The agent skipped all that. It read the stack events, found the versioned bucket, emptied it properly (versions and delete markers), and retried, without me leaving the chat or orphaning anything.

Everything is auditable. Because this all goes through the managed AWS MCP Server, every call lands in CloudTrail. More on that next.

I could see every call in CloudTrail

This is the part that turns "I let an agent delete my infrastructure" from scary into fine.

Every action the agent took went through the managed AWS MCP Server, and every one of those calls shows up in CloudTrail. I went and looked. All four DeleteStack events are right there under my identity, and they carry a clear fingerprint:

eventName:        DeleteStack
userIdentity:     gaonkarr
sourceIPAddress:  aws-mcp.amazonaws.com
userAgent:        aws-mcp.amazonaws.com

That aws-mcp.amazonaws.com value is how you tell agent actions apart from your own. Earlier the same day I'd deleted some stacks by hand in the console, and those events look completely different: a real browser user agent and my actual IP address. So the audit trail shows who really did what, my clicks versus the agent acting on my behalf.

Here are the five DeleteStack events from this cleanup, straight out of CloudTrail:

Time (UTC)	Stack	Identity	Source IP	User Agent
14:23:18	CdkPipelineStack	gaonkarr	aws-mcp.amazonaws.com	aws-mcp.amazonaws.com
14:23:18	buildon-sam-app	gaonkarr	aws-mcp.amazonaws.com	aws-mcp.amazonaws.com
14:23:18	aws-sam-cli-managed-default (1st attempt)	gaonkarr	aws-mcp.amazonaws.com	aws-mcp.amazonaws.com
14:23:19	sam-app	gaonkarr	aws-mcp.amazonaws.com	aws-mcp.amazonaws.com
14:24:19	aws-sam-cli-managed-default (retry)	gaonkarr	aws-mcp.amazonaws.com	aws-mcp.amazonaws.com

The retry is right there in the trail. The aws-sam-cli-managed-default delete shows up twice: once when it failed, and again about a minute later when the agent retried after emptying the bucket. The whole failed-then-fixed sequence is preserved.

One honest caveat worth knowing: the DeleteStack calls are management events, which CloudTrail logs by default. But the S3 DeleteObjects calls that actually emptied the bucket are data events, and those are not logged unless you've turned on data event logging for that bucket. So I could see the stack deletions clearly, but not the individual object deletions. If you want object-level actions in your trail, you have to enable S3 data events first.

What's next for me

Deleting four stacks felt good. So I got curious and asked the agent:

can you scan through my AWS account and identify any leftover resources?

It scanned common services in my account. First the default region, then it expanded to the others. 4 more pages of listing. 🫣

It found a significant number of leftover resources from workshops, demos, and old projects, and gave me a Cost Impact Summary.

3 stopped EC2 instances, oldest one from 2021.
14 unattached EBS volumes, some created back in 2014, still quietly billing for storage attached to nothing.
5 Elastic IPs sitting unassociated, roughly $18 a month for addresses doing no work.
122 S3 buckets, a load balancer I forgot about, 16 Lambda functions all on runtimes that hit end of life years ago.

None of it broke anything. That's exactly why it survived this long.

Finding all of that is usually the hardest part. Clicking through every service, in every region, one console at a time, is the reason I never do this. It's hours of tedious work before you've deleted a single thing. This time I asked once, and the agent handed me the whole list.

The task that always felt too big to start is now the easy part.

So I'm going to clean it up with help of my new assistant.

If your account is anything like mine, it should probably be yours too.

Disclaimer:

Please be specific with your agent on what you want to delete. Deleting is irreversible action and should only be done carefully!

Tell me what you find in there. I'd bet I am not the only one who forgot about it.

Follow along

Cloudagotchi Part 2 : Giving it a face: Sprites and touch on a 1.8" screen

Olivier Leplus — Thu, 23 Jul 2026 15:26:14 +0000

In part 1, we gave our virtual pet a nervous system: the ESP32-S3 now speaks mutual-TLS MQTT with AWS IoT Core, and we can chat with it from the AWS console. Very satisfying. Also very much a black screen with a serial log, a pet only a backend developer could love.

Today we fix that. By the end of this article, a face blinks at you from the screen: two soft eyes and an orange smile that looks suspiciously familiar if you've ever received a package (or used AWS ^^). Tap it and it beams. Shake the board and it goes wide-eyed. Ignore it for two minutes and it dozes off with a little zzz. And every one of those interactions is published to the cloud, ready for the brain we'll build in part 3.

In this article, I will walk you through building a sprite-based pet face with LVGL plus touch input, a shake detector in ~30 lines of IMU code, and the very honest story of why I ended up with sprites after my first approach fell apart on real hardware.

⚠️ Reality check (sorry 😅): my first version of this pet was "elegant" a pet drawn procedurally from LVGL arcs and rounded rectangles, animated at 30 fps. It looked great in my head and became a corrupted mess of color bands on the actual panel. This article teaches the approach that survived contact with the hardware. The detours are documented in the ⚠️ boxes, because they'll save you an afternoon each.

The code for this article is on the article-2 branch:

git clone https://github.com/tagazok/cloudagotchi && cd cloudagotchi
git checkout article-2

The board does the hard part: the BSP

Getting a display, touch controller, and LVGL configured from scratch on embedded hardware is normally an afternoon of datasheets and SPI timing tantrums, even more for me who is a JavaScript developer 😅. The reason I picked ESP-IDF over Arduino in part 1 pays off right here: Waveshare publishes an official Board Support Package (BSP) for this exact board as a managed component. One line in idf_component.yml:

dependencies:
  waveshare/esp32_s3_touch_amoled_1_8: '^2.0.3'

...and one function call:

#include "bsp/esp32_s3_touch_amoled_1_8.h"

bsp_display_start();   // AMOLED on, touch on, LVGL initialized.

Behind that call, the BSP configures the CO5300 display driver over QSPI, the touch controller over I2C, and starts an LVGL task with display flushing hooked up.

Also, know this quirk: flashing leaves the panel dark. The panel keeps running during idf.py flash with nobody driving it. If you also have this problem after flashing, reset the board (Ctrl+T Ctrl+R in the monitor) and it comes up clean.

One more rule to remember, because it will bite you exactly once: LVGL isn't thread-safe. The BSP runs LVGL in its own task, so any other task touching the UI must take the lock:

bsp_display_lock(0);      // 1. take the LVGL mutex (0 = wait forever)
lv_bar_set_value(...);    // 2. mutate the UI
bsp_display_unlock();     // 3. give it back

Forget it and you get the embedded classic: a crash, or worse, a silent no-op.

Why sprites, not shapes: a war story in one paragraph

My first face was procedural: the head an lv_obj with a big corner radius, the mouth an lv_arc, everything animated by LVGL's animation engine: bobbing, blinking, squishing. Beautiful in theory. On hardware, the panel's QSPI transaction queue would overflow under load (Wi-Fi bring-up, TLS downloads) and silently drop color transfers. Animated widgets self-heal, they redraw every frame. But each dropped chunk of a static widget stays on screen as a garbage band forever. The more the UI animated, the more the queue overflowed, the worse the corruption. I tried buffer tuning, cache settings, custom DMA allocations; some attempts made it worse in spectacular new ways.

The approach that survived: make the display's job trivial. Pre-render every expression as a sprite baked into flash. The face is ONE static image widget; changing expression = swapping which sprite is shown = one clean rectangular blit. A blink, a mood change, a talking mouth, all the same cheap operation. Nothing redraws unless an event happens, so nothing can outrun the display.

// The face: ONE static image widget, centered. That's the whole pet.
s_face = lv_image_create(screen);
lv_image_set_src(s_face, &face_neutral);
lv_obj_align(s_face, LV_ALIGN_CENTER, 0, 20);

The sprite pipeline: from PNG to C array

The art is a set of PNGs, one per expression (neutral, happy, sad, sleeping, three talking mouths, plus per-mood blink frames). I generated mine with an AI image generator and composited them onto a common canvas with identical eye positions so frames don't jitter when swapped.

Each PNG becomes a C file via a small Python script (in the repo): pixels converted to RGB565A8, 16-bit color plus an 8-bit alpha plane, LVGL 9's friendliest transparent format, and wrapped in an lv_image_dsc_t:

const lv_image_dsc_t face_happy = {
  .header = { .magic = LV_IMAGE_HEADER_MAGIC, .cf = LV_COLOR_FORMAT_RGB565A8,
              .w = 210, .h = 162, .stride = 420 },
  .data_size = sizeof(happy_map),
  .data = happy_map,   // lives in flash, memory-mapped, zero RAM cost
};

Seven faces at ~100 KB each sounds heavy, but they compile into the 16 MB flash and LVGL blits them straight from there.

Blinking, by image swap

No animation engine needed, a blink is two sprite swaps on a timer:

static void blink_timer_cb(lv_timer_t *t)
{
    if (s_talking || s_dozing || s_mood == PET_MOOD_SLEEPING) return;
    // Dedicated blink frame: closed eyes, SAME mouth as the current mood —
    // a blink should only move the eyes.
    switch (s_mood) {
    case PET_MOOD_HAPPY: set_face(&face_blink_happy);  break;
    case PET_MOOD_SAD:   set_face(&face_blink_sad);    break;
    default:             set_face(&face_blink_neutral); break;
    }
    lv_timer_create(blink_close_cb, 120, NULL);  // reopen after 120 ms
}

The doze: a pet that gets bored

Leave the pet alone for two minutes and it falls asleep (the sleeping sprite, complete with a little zzz). Touch it or shake it and it wakes. One LVGL timer plus a reset-on-activity:

// 2 minutes with no interaction → the pet nods off.
static void idle_timer_cb(lv_timer_t *t)
{
    if (s_talking) return;      // reading aloud is not boredom
    s_dozing = true;
    set_face(&face_sleeping);
}

// Any interaction resets the boredom clock — and wakes the pet.
static void note_activity(void)
{
    if (s_idle_timer) lv_timer_reset(s_idle_timer);
    if (s_dozing) {
        s_dozing = false;
        set_face(mood_sprite(s_mood));
    }
}

A deliberate design choice: cloud updates don't wake it. The stat bars refresh quietly under the napping face; only human interaction wakes the pet. Nobody likes being woken by a cron job.

The HUD: three stats, three icons, one secret button

Across the top: three bars with icons : 🥑 hunger (avocado green), ⚡ energy (teal), ❤️ mood (pink). The icons are tiny 28×28 sprites drawn programmatically by the same PNG→C pipeline.

The avocado is not just a label, it's a button. Tapping it feeds the pet (we wire up what "feed" means in part 3; today it publishes the interaction):

static void food_clicked_cb(lv_event_t *e)
{
    pet_ui_react_happy();                           // nom nom, instantly
    if (s_on_interaction) s_on_interaction(PET_INTERACTION_FEED);
}

Shake detection: the IMU in 30 lines

The board has a QMI8658 6-axis IMU. You might reach for a gesture-recognition library. Don't, a shake is beautifully simple physics: at rest the accelerometer reads ~1 g of gravity (1000 mg); a shake is the magnitude repeatedly leaving that baseline.

// The Waveshare qmi8658 component hands us calibrated milli-g values
// (we asked for mg units once, at init, with qmi8658_set_accel_unit_mg).
float ax, ay, az;
qmi8658_read_accel(&s_imu, &ax, &ay, &az);

// 1. Total acceleration, all axes combined. At rest: ~1000 mg.
float mag = sqrtf(ax*ax + ay*ay + az*az);

// 2. A "jolt" = a reading well above resting gravity.
if (mag > 1800.0f) jolts++;

// 3. Three jolts within 800 ms = the human is shaking us.
if (jolts >= 3 && within_window) {
    on_shake();
    cooldown();   // 4. then ignore everything for 1.5s (debounce!)
}

The full version (in app_imu.c) polls at 50 Hz from its own FreeRTOS task, plenty for human hands.

The three constants are worth tuning to taste:

Constant	Value	Feel
`SHAKE_THRESHOLD_MG`	1800 mg (1.8 g)	Lower = hair-trigger, higher = vigorous shaking required
`SHAKE_JOLTS_NEEDED`	3	Filters out bumping the desk
`SHAKE_COOLDOWN_MS`	1500	One shake = one event, not twelve

💡 Debounce is the whole game. My first version fired 14 "play" events per shake, which in part 3's economy would have turned one wiggle into a pet so overstimulated it refused dinner.

One threading gotcha that bit me: the shake callback runs on the IMU task, not the LVGL task, so the reaction functions take the display lock (it's recursive, so they're safe from touch callbacks too).

Wiring body to nervous system

Everything converges in main.c, and the flow reads like the pet's reflex arc: input, reaction on screen, report to the cloud:

static void on_shake(void)
{
    pet_ui_react_startled();  // reflex: wide eyes, instantly
    app_mqtt_publish("interaction", "{\"type\":\"play\"}");  // then tell the brain
}

void app_main(void)
{
    // Face first: the pet appears before Wi-Fi even starts.
    pet_ui_start(on_interaction);
    pet_ui_set_state(80, 80, 80, PET_MOOD_NEUTRAL);

    app_imu_start(on_shake);
    app_wifi_connect();
    app_mqtt_start(on_cloud_message);
}

That ordering is a deliberate UX decision: react locally first, sync to the cloud second. The happy face flashes the instant you tap, not a network round-trip later. The cloud is the source of truth for state (part 3), but never sits between a touch and its reaction. Pets have reflexes; only their feelings need a brain.

Flash it:

cd firmware && idf.py flash monitor

...and there it is. A face, blinking on that ridiculous little AMOLED, beaming when you tap it, nodding off when you don't. Meanwhile, in the AWS console (MQTT test client, cloudagotchi/#), your affection is now telemetry:

cloudagotchi/cloudagotchi-01/interaction  →  {"type":"pet"}
cloudagotchi/cloudagotchi-01/interaction  →  {"type":"feed"}
cloudagotchi/cloudagotchi-01/interaction  →  {"type":"play"}

Why this matters

Two takeaways travel well beyond virtual pets. First, on constrained display hardware, sprites beat shapes: pre-rendering moves all the expensive work to build time and reduces the runtime to "copy rectangle", the exact operation embedded panels are good at. The corollary: the less your UI redraws, the less can go wrong, and event-driven beats animated. Second, the local-reflex / cloud-state split is the interaction pattern for connected devices. Anything that must feel instant lives on the device; anything that must be remembered lives in the cloud. Get that boundary right and your device feels alive even on flaky hotel Wi-Fi.

Right now, though, our pet publishes its little heart out into the void. Nobody listens. Its stats are hardcoded at 80. It is, developmentally speaking, a very cute reflex with no memory.

Next article: the brain. DynamoDB remembers, Lambda decides, EventBridge Scheduler makes time pass, and the pet finally gets hungry while you sleep.

Try it yourself

The Cloudagotchi repo : git checkout article-2
LVGL images documentation : formats, lv_image_dsc_t, and the online converter
Waveshare BSP on the ESP Component Registry : the one-liner display setup

DEV Community: AWS

Stop Your AI Agent Forgetting User Preferences: Key-Value Memory

Isn't the conversation history already memory?

What does the experiment measure?

How does the agent learn preferences without a form?

How does persistent memory survive restarts? The durability ladder

Rung 2 → 3: survive a restart (local disk)

Rung 3 → 4: survive in the cloud (Amazon S3)

What do the measured results show?

When is key-value memory the wrong choice?

How do you ask an AI coding assistant to build this?

How do you run the demo?

FAQ

Resources

How Much Does It Cost to Self-Host Open Models on AWS?

What "Open Models" Actually Means

The Architecture: What You Actually Need

Hardware (The Expensive Part)

The Serving Software (The Free Part)

The Model

The Cost Breakdown

Scenario 1: Team of 10

Scenario 2: Company of 500

The Models People Are Switching To

The Honest Trade-offs

The Geopolitical Angle

What to Do Monday Morning

🛫 I Vibe Coded a Website at 35,000 Feet 🛬

AWS Follow

Sean BoultFollow

How to Build and Deploy an AI Agent on AWS with Bedrock, Strands, and AgentCore

TL;DR

What's in this post

The mental model

Prerequisites

Chapter 1: Raw Bedrock, a brain with no eyes

Set up the project

The whole file

Run it

What comes back

Chapter 2: A local Strands agent, the loop that grounds the answer

Set up the project

The whole file

What the loop actually does

Run it

What comes back

Chapter 3: Deploy to AgentCore Runtime

Install the deploy tooling

Bootstrap once (this is the "we bootstrap this thing" step)

Scaffold the project

The scaffold is a sample agent, not our agent

Edit 1: swap the model in app/PantryChef/model/load.ts

Edit 2: make it the pantry chef in app/PantryChef/main.ts

Run it locally first

Deploy it

Invoke it from the cloud

The four commands, start to finish

Who can actually call this thing?

Cost and teardown

The extras you grow into: memory, gateway, observability

The whole stack in one picture

Reproduce this yourself

Your turn

Cloudagotchi Part 4 : My Tamagotchi reads me the AWS news

The pipeline

Step 1 — The news, without an API key

Step 2 — Bedrock, in character

Step 3 — Polly, and the decision that saves the firmware

Step 4 — The paper delivery

Step 5 — The device: badge, tap, play

The morning after

Why this matters

Try it yourself

Your Agent Toolkit for AWS Cheat Sheet

Intro

Set up and connect

Find the right skill

Review before you install

Install and take inventory

Keep current and clean up

Edit 1: swap the model in `app/PantryChef/model/load.ts`

Edit 2: make it the pantry chef in `app/PantryChef/main.ts`

2. The `#` menu is bigger than `#file` in the IDE