DEV Community: AWS

AI Agent Memory: Add Semantic Search Without a Vector Database

Elizabeth Fuentes L — Thu, 13 Aug 2026 01:31:01 +0000

📦 Clone and ⭐ stop-ai-agents-losing-memory-sample-for-aws

The agent's memory holds the answer. The user asks the question. And retrieval returns nothing.

stored:   dietary_notes: "Vegetarian; severe shellfish allergy — strictly no
          crustaceans or mollusks."

asked:    "What should I avoid eating when I go out for dinner on this trip?"

keyword scan: 4 hits, answer found: False

That's a real run, not a thought experiment. The question names no key and shares no words with the stored note, so the key-value memory from the previous post never finds it. The answer was in the store the whole time.

This is the dividing line for semantic search: do you know the key, or only the intent? When questions stop matching keys, you retrieve by meaning: embed each memory once, embed the question, return the nearest neighbors by cosine similarity. This post measures two things (whether semantic search finds what keyword search misses, and which vector store fits your deployment) using the same embeddings and the same memories in the companion repo.

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

Why does key-value memory miss the question?

Because a key-value read is a lookup someone designed in advance, and this question maps to no key. The demo stores 10 memories about a traveler (profile facts, notes, episodes) and asks the dinner question against three stores. The key-value store has exactly two moves, and both fail honestly:

Keyword scan: match question words against keys and values. It returns 4 hits, none of them the allergy note, because "avoid eating at dinner" shares no words with dietary_notes or "shellfish". Answer found: False.
Dump-all fallback: give the model the entire memory and let it read. It works, at a price that grows with every memory you add. For these 10 memories that's 647 characters per question; for hundreds of notes it's thousands of tokens, every single question, forever.

This isn't a bug in key-value memory. Profile lookups ("what's my preferred cabin?") stay exact, instant, and free of embedding costs, which is why the previous post built them that way. The limit only appears when the question is semantic. That's the signal to add a second way in, not to replace the first.

How does semantic search find it?

By comparing meanings instead of words. Every memory is embedded once at write time into a vector (here: Amazon Titan Text Embeddings V2, 1,024 dimensions). At query time, the question is embedded and the store returns the nearest neighbors by cosine similarity:

top hit: "Vegetarian; severe shellfish allergy — strictly no crustaceans
          or mollusks."  (score 0.231)
answer found: True

No shared words between question and note. They're close in meaning, and meaning is what got indexed. Both backends below return this same top hit, because they use the same embeddings; what differs is everything around the query.

FAISS or Amazon S3 Vectors? Same accuracy, different deployment

Both are embedding vector stores. They use the same model (Titan V2), the same algorithm (cosine similarity), and they return the same top hit with the same score. The accuracy is identical this is not a quality trade-off.

Store	Finds the answer	Similarity score
Key-value (keyword scan)	No	— keyword miss
FAISS — Facebook AI Similarity Search, Meta's in-process vector index	Yes	0.231
Amazon S3 Vectors (managed cloud)	Yes	0.231

The difference is deployment. FAISS is an in-process library — zero infrastructure, a pip install, runs local to the process. It provides disk persistence via faiss.write_index / faiss.read_index. In this demo the index is not persisted and is rebuilt from scratch each run. S3 Vectors is a managed AWS service: the index lives in a cloud bucket, reachable from any process with AWS credentials, with no cluster to run or scale.

The demo uses the same AWS credentials for both: Titan embeddings via Bedrock and S3 Vectors via boto3; the same aws configure setup powers both, which is why this requires no extra setup inside a Strands Agents workflow. The demo self-provisions the bucket and index on first run: create_vector_bucket → create_index (1,024 dims, cosine) → put_vectors / query_vectors.

The cost both backends share: embedding the question costs ~510 ms with Titan V2. Index query time (0.09 ms for FAISS, 195 ms for S3 Vectors) is secondary to that. Plan for the embedding call in any latency-sensitive path, regardless of which vector store you pick.

So, do you need a vector database?

It depends on the query pattern. AWS positions S3 Vectors as "ideal for workloads where queries are less frequent", which describes agent memory exactly: an agent queries a user's memories a handful of times per conversation, not thousands of times per second.

	FAISS	Amazon S3 Vectors	Dedicated vector database
Type	In-process library	AWS vector storage	Full database engine
Examples	—	—	OpenSearch, Qdrant, Weaviate, Milvus, pgvector, Chroma
Semantic accuracy	✅ same	✅ same	✅ same
Infrastructure	None — pip install	None — fully managed	Self-hosted or managed
Max vectors	Process memory	Up to 2 billion per index	Depends on deployment
Query latency	~0.09 ms	~100–200 ms	Sub-10 ms at high QPS
Hybrid search	❌	❌	✅ most support it
Best for	Prototype / local agent	Cloud agent, infrequent queries	High QPS, advanced filtering, production search

The decision:

You need	Pick	Why
Facts under known keys (profile, preferences)	Key-value (post 1)	Exact and instant; don't pay ~510 ms of embedding for a lookup
Semantic search, local / prototype	FAISS	Zero infrastructure, pip install, in-process
Semantic search, cloud / infrequent queries	S3 Vectors	Purpose-built AWS vector storage, subsecond latency, up to 2 billion vectors, no infrastructure to manage
High QPS, hybrid search, or advanced filtering	Dedicated vector DB	OpenSearch, Qdrant, Weaviate, Milvus, pgvector, Chroma
Multi-hop questions over relationships	Graph (next post)	Semantic search finds pieces; it can't follow edges between them

What this demo does not cover: FAISS and S3 Vectors are storage backends. They store vectors and retrieve by similarity. Building what to remember (extracting specific facts from conversations, deduplication, structured memory across sessions) is handled by managed memory services like Amazon Bedrock AgentCore Memory. That technique is the topic of a future post in this series.

How does the agent choose between key lookup and semantic search?

From the tool docstrings, on its own. The demo's last test attaches both recall tools to one Strands agent:

@tool
def recall_by_key(key: str) -> str:
    """Recall a memory when the question maps to a known identifier.
    Use when the user asks about a stored field: "my preferred cabin",
    "my home airport"..."""

@tool
def recall_semantic(question: str, top_k: int = 3) -> str:
    """Recall memories by meaning when no key is obvious.
    Use for open questions: "what should I avoid eating on this trip?"..."""

Asked the dinner question, the agent calls recall_semantic; asked "what cabin do I prefer?", it calls recall_by_key. No routing logic, no prompt engineering. The when to use this sentence at the top of each docstring is what the model reads to decide. Write that sentence carelessly and the agent pays embedding latency for profile lookups.

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

The quality of the semantic search implementation your assistant builds depends on the decisions you name in the prompt. Unnamed, it will default to embedding everything and querying one big index. These five instructions encode what this post measured:

"Add semantic search only for questions that don't map to keys; keep profile facts in key-value state." Otherwise the assistant defaults to embedding every query, including exact lookups that already have a known key.
"Embed each memory once, at write time; only the question gets embedded at query time." Assistants love re-embedding the whole store per query.
"Use one embedding function for storage and queries, and state the model and dimensions." Mixed embedders produce silent garbage similarity scores.
"Give me two recall tools with 'when to use' docstrings: by key, and by meaning." The agent routes per question from those sentences; no router code.
"Make persistence explicit: in-process index for a prototype, managed vector storage for anything that must survive a restart, and prove it with a fresh-client test that still sees every vector."

The companion repo implements and measures all five. Run it to see each decision play out.

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/02-vector-memory-demo
uv venv && uv pip install -r requirements.txt
uv run python test_vector_memory.py

Needs AWS credentials (aws configure) for Titan embeddings and S3 Vectors. The demo creates the vector bucket and index automatically if they don't exist. OPENAI_API_KEY is only needed for the agent conversation in the notebook (or swap one line for Amazon Bedrock); the retrieval measurements run without any LLM.

FAQ

Is a vector database the same as AI agent memory?
No. A vector database is one possible backend for one memory type (retrieval by meaning). Agent memory is the whole system: key-value state, vector or graph storage, selection rules, and hygiene. Many production agents need vector retrieval without a vector database.

Can I use a vector database as agent memory?
Yes, for memories you'll query by meaning. But route keyed facts (preferences, settings) to key-value storage first: a direct lookup costs nothing, while every vector query pays the question-embedding call (~510 ms with Titan V2) before the index is even touched.

When do I need something beyond S3 Vectors?
When your query pattern changes. Dedicated vector databases such as OpenSearch, Qdrant, Weaviate, Milvus, pgvector, and Chroma are built for high QPS, hybrid keyword+vector search, aggregations, and advanced filtering. S3 Vectors is purpose-built for infrequent queries: it handles up to 2 billion vectors per index with subsecond latency, which covers agent memory workloads well past prototype scale.

What's the real latency difference between FAISS and S3 Vectors?
Measured on the same memories: 0.09 ms vs 195 ms per query. But embedding the question adds ~510 ms to both, so end-to-end it's ~0.5 s vs ~0.7 s. The index is rarely your bottleneck; the embedding call is.

Why did my semantic search return the wrong memories?
The most common causes: the store and the queries use different embedding models or dimensions, memories were embedded with stale text, or keyed facts polluted the index. Keep one embedder for everything, embed at write time, and keep profile facts out of the vector store.

Resources

Companion repo — demo 02 with the measured tests and notebook
Amazon S3 Vectors — User Guide and limitations
Amazon Titan Text Embeddings V2
FAISS, Meta's similarity search library
Zep: A Temporal Knowledge Graph Architecture for Agent Memory, Rasmussen et al., 2025
From RAG to Memory: Non-Parametric Continual Learning for LLMs (HippoRAG 2), 2025

Gracias!

🇻🇪 Dev.to Linkedin GitHub Twitter Instagram Youtube

Elizabeth Fuentes LFollow

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

Running Kiro Crew in Docker on Windows

Matheus Guimaraes — Wed, 12 Aug 2026 20:12:47 +0000

I've been playing with Kiro Crew recently, and when I went to get it running on my Windows machine I had a decision to make.

Kiro Crew doesn't currently have a Windows desktop app. You can still run it natively on Windows, but the documented route involves installing and running the Gateway from source.

But then, while looking through the Kiro Crew GitHub repository, I noticed another option that immediately caught my attention: there's an official Docker image!

Docker is already a familiar part of the development workflow for many of us, and a container felt like a nice, clean way to get Kiro Crew running without installing it from source.

So that's the route I took.

It worked, but along the way I ran into an interesting security detail that made the setup slightly less straightforward than simply running a container.

And, as it turns out, that's actually a good thing.

What we're going to do

By the end of this post, we'll have Kiro Crew running in Docker on Windows, with its agent sandbox enabled and without giving the container more privileges than it actually needs.

I'm using Docker Desktop with WSL 2, so you'll want to have those installed before following along.

You can check your WSL installation with:

wsl --version

With that out of the way, let's get Kiro Crew running.

Starting with the official container image

The Kiro Crew team publishes a public container image, so we don't need to build anything ourselves or even authenticate with a container registry. Nice and easy.

Before doing anything else, I created a directory to keep the files for this setup together:

mkdir kiro-crew
cd kiro-crew

Now, at first glance, running Kiro Crew looks like it should be as simple as starting the official image.

And technically, the Gateway itself will run.

But there's another security boundary inside that container that we need to understand before we can start it properly.

Wait... a sandbox inside a container?

This was the interesting part for me.

We're already putting Kiro Crew inside a Docker container, which gives us an isolation boundary between Kiro Crew and our Windows host.

But Kiro Crew adds another boundary of its own.

Agent commands aren't simply executed with access to everything available to the main Kiro Crew process. On Linux, Kiro Crew creates an internal user-namespace sandbox for those commands.

Conceptually, our setup looks something like this:

Windows
└── Docker container
    └── Kiro Crew
        └── Agent sandbox

Why sandbox an agent that's already inside a container?

Because the two boundaries are protecting different things.

The container isolates Kiro Crew from our host. The inner sandbox isolates agent commands from sensitive state available to Kiro Crew itself.

For example, Kiro Crew's sandbox hides credential directories such as ~/.aws and ~/.ssh from agent subprocesses by bind-mounting empty directories over them. So if an agent-executed command tries to access one of those directories, it simply sees an empty directory rather than our AWS credentials or SSH keys.

That means the Gateway can have the credentials it needs to do its job without automatically making those credentials readable by commands executed by an agent.

That's a pretty important distinction when we're giving an AI agent the ability to execute commands.

Where Docker gets in the way

There's one complication.

To create that inner sandbox, Kiro Crew needs Linux system calls including:

unshare(CLONE_NEWUSER)
unshare(CLONE_NEWNS)

Docker's default seccomp security policy blocks those operations.

So if the Kiro Crew container can't create its inner sandbox, it doesn't quietly shrug its shoulders and run agent commands without one.

It fails closed, meaning that when the security mechanism can't be established, access is denied rather than silently falling back to a less secure mode.

The Gateway and dashboard can still run, but agent command execution remains disabled.

I actually really like this design! What initially looks like an extra hurdle in getting the container running is Kiro Crew refusing to silently weaken its security model.

So how do we fix it?

The tempting solution and the better solution

There are a few ways we could approach this.

One option is to simply tell Kiro Crew that we accept running agent commands without the inner sandbox. Kiro Crew provides an environment variable for exactly that:

KIROCREW_ALLOW_UNSANDBOXED=1

We could pass that into our container and Kiro Crew would allow agent execution, leaving Docker itself as our only isolation boundary.

We could also reach for the rather large hammer:

--privileged

That would make the sandbox work, but it does so by granting the container extremely broad privileges and removing many of Docker's normal isolation restrictions.

That's a much bigger security concession than we actually need.

What we really want is much narrower:

Allow the operations Kiro Crew needs to create its sandbox while keeping the rest of Docker's security restrictions in place.

And this is another nice detail about the Kiro Crew implementation: the team already provides a seccomp profile specifically for this!

So we don't have to create one ourselves.

Downloading the Kiro Crew seccomp profile

From the kiro-crew directory we created earlier, download the official Kiro Crew seccomp profile:

curl -fsSL https://raw.githubusercontent.com/kirodotdev/KiroCrew/main/docker/seccomp/kirocrew-seccomp.json \
  -o kirocrew-seccomp.json

You should now have:

kiro-crew/
└── kirocrew-seccomp.json

Having trouble downloading it from WSL?

I happened to be dealing with a DNS issue in my WSL environment when I did this, so curl couldn't resolve GitHub. If you happen to run into the same thing, there's nothing special about downloading the file through curl: you can download kirocrew-seccomp.json directly from the Kiro Crew GitHub repository in your browser and place it in this directory manually, which is what I did.

Now we can start the container using that profile.

Running Kiro Crew

Run:

docker run -d --name kirocrew \
  -p 127.0.0.1:5476:5476 \
  -v kirocrew-home:/home/kirocrew \
  --security-opt seccomp=kirocrew-seccomp.json \
  ghcr.io/kirodotdev/kirocrew:stable

There are a couple of things worth noticing here.

We're only publishing port 5476 on the host's loopback interface, so the dashboard isn't being exposed to the rest of our network.

We're also creating a named Docker volume:

kirocrew-home

Kiro Crew keeps its persistent state under /home/kirocrew, including its configuration and Kiro CLI credentials. That means our state can survive replacing or upgrading the container.

And, most importantly for what we've just discussed, we're passing the Kiro Crew seccomp profile with:

--security-opt seccomp=kirocrew-seccomp.json

The container can now create the inner namespace sandbox while Docker's other default security restrictions remain in place.

Let's open it

At this point I did what I imagine most developers would do.

I opened:

http://localhost:5476

And instead of the Kiro Crew dashboard, I was greeted by a message telling me I was missing a token.

Another security measure!

Simply being able to reach port 5476 isn't enough to get access to the dashboard. Kiro Crew also requires a bearer token, so someone who can reach the Gateway still needs to authenticate before they can use it.

So, there's one more part of the setup we need to do.

Actually, two.

Authenticating Kiro CLI

Kiro Crew's agent runtime uses kiro-cli, so first we need to authenticate the CLI running inside our container.

We can do that without opening an interactive shell ourselves:

docker exec -it kirocrew kiro-cli login

Follow the authentication flow and log in with the identity you use for Kiro.

Once authentication succeeds, those credentials are stored in the kirocrew-home volume we created earlier, so they survive container upgrades.

But that authenticates the agent runtime.

We still need access to the dashboard.

Getting our dashboard token

Every request to the Kiro Crew dashboard requires a token.

We can mint a temporary login link from the running container:

docker exec kirocrew kirocrew token --ttl 2h

Kiro Crew will print a URL containing the token.

It will look roughly like:

http://localhost:5476/?token=...

Open that URL in your browser and...

We're in!

And with that, we have Kiro Crew running nicely inside Docker on Windows, without having to build it from source and without unnecessarily weakening either of its isolation boundaries.

Now I just need someone to explain why the Solarized theme is green instead of yellow. 😄

References

7 Tips to Make Your AI Agent More Predictable

Salih Guler — Tue, 11 Aug 2026 10:20:35 +0000

After months of building with AI coding tools, I found the difference between generated code that works and generated code that ships comes down to how you communicate with the AI. I have been sharing these lessons in a talk called "It's Dangerous to Code Alone! Take This: Developer's AI Survival Guide" and people keep asking me to write them down. How big is the gap? An MIT study across 100,000+ developers found that AI agents boosted code written by ~180%, while code that actually shipped to production rose by only ~30%.

To demonstrate these tips, I built a link-sharing platform so my teammates can share resources without juggling multiple QR codes. I generated the frontend with Codex GPT 5.6 Sol and Figma MCP, and I am adding an AWS Blocks backend to swap out local mocks with real cloud infrastructure. You can find all the prompts in this repository.

All of these tips are applicable to greenfield projects as well. I can't promise you it is going to have the 42 effect :)

#1 Talk to AI in Clear Prompts

Each model reacts to prompts differently. The clearer you get, the faster you achieve your goal.

You also need to remember that now we don't only have models, we also have effort levels. If you are not mindful about which model you are running with which effort level, you will have a hard time getting the results you want.

Here are some general rules I follow (you can check the BUILD_PROMPT.md and the AWS Blocks skill in the repo for the full picture):

Zero-Shot

Describe what you want. Works for simple, well-defined tasks.

Here is my frontend build prompt. One sentence, clear outcome:

Build "Some Useful Links" — a LinkTree-style web application using
Next.js with SSR enabled. The complete visual design specification
is in `DESIGN_SPEC.md` and reference screenshots are in the
`design-previews/` folder. Implement the design pixel-perfectly.

And for the backend migration to AWS Blocks:

Replace the local JSON mock services in src/lib/services/local/ with
AWS Blocks implementations. The service registry (index.ts) is the
only file that should change in the existing codebase. Frontend must
not be modified.

Both are zero-shot: one clear task, no ambiguity.

Few-Shot

Show examples. Input, output. Input, output. The model picks up the shape. Research shows the format matters more than whether the examples are perfectly correct.

In my BUILD_PROMPT.md, I use this for the service registry pattern. I show the AI what an implementation swap looks like:

// src/lib/services/index.ts
import { LocalAnalyticsStore } from './local/analytics-store.local';
import { LocalLinkStore } from './local/link-store.local';
import { LocalVisitTracker } from './local/visit-tracker.local';

// SWAP POINT: Replace these with cloud implementations
export const analyticsStore = new LocalAnalyticsStore();
export const linkStore = new LocalLinkStore();
export const visitTracker = new LocalVisitTracker();

When I ask the AI to build the AWS Blocks backend, it sees this pattern and knows the target: create a BlocksAnalyticsStore, BlocksLinkStore, and BlocksVisitTracker that implement the same interfaces, then swap them in index.ts. I do not need to explain the concept of dependency injection. The example IS the explanation.

Chain-of-Thought

Force the model to reason step by step before acting. For debugging, architecture decisions, or anything multi-step, this cuts logical errors significantly.

I use this when asking the AI to plan the AWS Blocks migration:

Before writing any code, analyze the existing service interfaces in
src/lib/services/interfaces/. For each interface method, determine:
1. Which AWS Blocks building block maps to it (DistributedTable, KVStore, FileBucket, etc.)
2. What the key schema should be to support the query patterns
3. Whether the method needs authentication (check if the frontend
   calls it from an admin route or a public route)

Write your analysis as a numbered plan. I will review it before you
start implementing.

The AI produces a plan I can review before it writes a single line of code. Without this step, it would just start building and often pick the wrong storage pattern for a given query.

#2 Set Absolute Boundaries

Use words like MUST, NEVER, ALWAYS, and STRICTLY FORBIDDEN. Avoid weak phrasing like "Please try to," "It is preferred," or "Usually we do."

Here is a comparison from my project. The frontend BUILD_PROMPT.md sets boundaries like this:

All backend infrastructure must be local mocks — no cloud dependencies.
The mocks must be documented clearly enough that another AI agent or
developer can swap them for any cloud provider without restructuring.

And the AWS Blocks skill sets boundaries for the backend side:

Backend lives in `aws-blocks/index.ts`. Frontend imports from
'aws-blocks' (workspace package). The `client.js` is auto-generated
— never edit it.

Both are direct, absolute, and leave no room for interpretation.

Prioritize negative boundaries (Guardrails)

Telling the AI what NOT to do is often more effective than listing everything it should do.

Frontend (AGENTS.md):

- Do not add cloud SDKs, deployment configuration, external persistence,
  or source-controlled credentials unless the task explicitly requires them.
- Import services from `@/lib/services`; components and route handlers
  must not import `src/lib/services/local/*` directly.
- Keep unrelated refactors and generated-file churn out of focused changes.

Backend (AWS Blocks skill):

- Adding to an existing project? Scaffold into a temp dir, copy only
  `aws-blocks/` folder, then manually merge workspace config, scripts,
  and dependencies. The scaffolder overwrites root package.json,
  tsconfig.json, vite.config.ts, .gitignore.
- Never edit index.cdk.ts, index.handler.ts, or client.js — these are
  auto-generated.

#3 Give Your AI Persistent Context

You need to steer the agent in the correct direction. AI tools have dedicated files for this purpose:

AGENTS.md
CLAUDE.md
Kiro steering files (.kiro/steering/)
Kiro skills (.kiro/skills/)

Some of these are loaded every session (steering files), giving the AI persistent rules. Others are loaded on demand (skills), giving the AI specialized knowledge only when it needs it. Both keep your context window lean.

Always-loaded: Steering files

For the frontend, I have an AGENTS.md at the root that covers the full Next.js application:

# AGENTS.md

## Project Overview
Some Useful Links is a local-first, multi-page link-sharing application
built with Next.js App Router, React, strict TypeScript, and Tailwind CSS.

## Commands
npm install
npm run dev
npm run validate:links
npm run lint
npm run build

## Architecture
- src/app: App Router pages, layouts, route handlers
- src/components: UI grouped by admin, analytics, layout, links, share
- src/lib/services/interfaces: Backend-neutral service contracts
- src/lib/services/local: Local JSON-backed implementations
- src/lib/services/index.ts: The only provider registration and swap point

I also have two Kiro steering files that enforce cross-cutting rules regardless of the task:

TypeScript rules (.kiro/steering/typescript.md) — enforces strict typing and build validation:

# TypeScript Project Instructions

## Workflows & Validation
- Pre-completion Check: Before completing any task or reporting success,
  you MUST run `npm run build` in the terminal.
- Do not consider a task finished if the build command returns errors. Fix
  the errors first.

## Coding Conventions
- Strict typing is enforced. You are strictly forbidden from using the
  `any` type.
- Always define and apply the exact, correct types and interfaces for all
  variables, function parameters, and return values.
- You are STRICTLY FORBIDDEN from using @ts-ignore.
  If unavoidable, use @ts-expect-error with a detailed comment.

Agent behavior rules (.kiro/steering/agent.md) — controls what the AI can and cannot do on its own:

# Agent Behavior Rules

## File and Folder Boundaries
- DO NOT create any new Markdown files unless explicitly instructed by
  the user.
- STRICTLY FORBIDDEN to auto-generate changelogs or documentation.
- You MUST update the existing README.md if your changes alter the
  project's public API or architecture.

## Technology Boundaries
- You MUST ALWAYS use the Strands Agents library with TypeScript for any
  agent development.
- You are STRICTLY REQUIRED to use Claude Haiku 4.5 from Amazon Bedrock
  for all agent models.
- You MUST ALWAYS use React and Vite with TypeScript for web development.
- NEVER write or generate unit tests unless the user explicitly commands
  it.

## Security Boundaries
- NEVER commit or hardcode sensitive information (client secrets, API
  keys, client IDs, resource IDs).

## Git Boundaries
- Commits MUST stay under 150 lines of source code.
- Every commit: single-sentence summary, blank line, detailed explanation
  (max 20 lines).
- You MUST append `(Kiro)` to the author name using:
  git commit --author="[Git Username] (Kiro) <[User Email]>"

These prevent the common annoyances: AI generating unwanted test files, committing giant diffs, sneaking any types past the compiler, or littering the repo with markdown files nobody asked for.

On-demand: Skills

Steering files are always loaded. But what about capabilities that are only needed sometimes? You do not want to load everything upfront because that wastes context.

A Skill is a reusable, discoverable capability. The AI loads it only when it becomes relevant to the current task. The most important part of a Skill is the name and description. That is how the AI decides whether to use it.

My AWS Blocks skill activates with this frontmatter:

---
name: building-aws-blocks-apps
description: "Builds fullstack TypeScript applications on AWS using"
  @aws-blocks/blocks. Use when working with any Building Block
  (KVStore, DistributedTable, Agent, AuthBasic...), ApiNamespace,
  BlocksStack, or the create-blocks-app CLI.
---

The main SKILL.md is the overview: decision guides, project structure, quick start. Detailed reference lives in separate files:

.kiro/skills/aws-blocks-development/
├── SKILL.md                    # Overview + decision guide (under 200 lines)
├── CORE-ARCHITECTURE.md        # Scope, ApiNamespace, JSON-RPC, CORS
├── TROUBLESHOOTING.md          # Common errors and fixes
└── blocks/
    ├── auth-basic.md           # AuthBasic patterns
    ├── distributed-table.md    # DistributedTable patterns
    ├── api-namespace.md        # ApiNamespace deep dive
    └── ... (20+ block files)

When the AI needs to implement authentication, it loads blocks/auth-basic.md. When it needs to set up a database, it loads blocks/distributed-table.md. It does not carry all 122 KB of reference material in every conversation.

Keep it lean

Keep the root file under 200 lines. My AGENTS.md is 127 lines. The AWS Blocks SKILL.md is the overview (under 200 lines), with detailed reference files loaded on demand.

Use the "Router Pattern": a root file that points to detailed references when needed. The AWS Blocks skill does exactly this with its block reference table.

Separate context from instructions

Project Context tells the AI where it is:

"This is a Next.js 14 App Router project using Tailwind CSS."

Actionable Rules tell the AI what to do:

"Import services from @/lib/services; components must not import src/lib/services/local/* directly."

Keep these separate. Context helps the AI orient itself. Rules constrain its behavior.

#4 Manage Your Context Window

Your AI sees everything in a stack:

System instructions + steering files
Full conversation history (every message)
Tool output (files, terminal, search results)
Your current request

Performance degrades at 25% capacity, not 100%. You do not have the full context window available. The degradation starts much earlier than you think.

Context rot

Long sessions lead to the model "forgetting" earlier decisions, fixing one thing and breaking two others. Hallucinations increase as context fills up and your original constraints stop being followed.

I have seen this firsthand. On the frontend side, I asked my AI to follow the service registry pattern from my AGENTS.md. After 15 turns of unrelated work, it started importing directly from src/lib/services/local/, exactly what I told it not to do.

On the backend side, I had a session where I was building multiple API methods with AWS Blocks. After building the analytics endpoints, I asked it to add authentication. It generated a whole custom auth system instead of using the AuthBasic block that was in the skill file. The context was too full for it to reference back.

Fighting context rot

Start fresh sessions for each new task
Keep steering files under 200 lines
Summarize progress in a file the AI can re-read, do not rely on conversation history
Keep interactions to 5–7 turns per task max

#5 Follow a Spec-Driven Development Process

Vibe coding skips everything we know about building software: planning, analysis, design, testing, maintenance. All of it gone.

Vibe coding works for prototyping and tiny fixes. But for anything beyond that, you need structure.

Spec-Driven Development (SDD) is a methodology where detailed, unambiguous requirements are written and agreed upon before any actual coding begins. The spec is the contract between you and your AI.

Frontend spec (from `BUILD_PROMPT.md`)

<task>
Build "Some Useful Links" — a LinkTree-style web application using Next.js
with SSR enabled. The complete visual design specification is in
`DESIGN_SPEC.md` and reference screenshots are in the `design-previews/`
folder.

All backend infrastructure must be local mocks — no cloud dependencies. The
mocks must be documented clearly enough that another AI agent or developer
can swap them for any cloud provider without restructuring.
</task>

<architecture>
1. Framework: Next.js (App Router) with Server-Side Rendering enabled
2. Styling: Tailwind CSS with a custom theme from the design spec
3. Backend: Local mocks only — no cloud services, no external APIs
</architecture>

Backend spec (from `MIGRATING_TO_CLOUD_PROMPT.md`)

<task>
Replace the local JSON mock services in `src/lib/services/local/` with AWS
Blocks implementations. The existing service interfaces in
`src/lib/services/interfaces/` are the contract. The service registry
(`src/lib/services/index.ts`) is the only file that should change in the
existing codebase.

The frontend, routing, components, and design must remain untouched.
</task>

<architecture>
1. Backend runtime: AWS Blocks (`aws-blocks/index.ts`)
2. API layer: ApiNamespace with methods that mirror the existing service
   interface contracts
3. Auth: AuthBasic for admin routes (analytics dashboard, page management)
4. Data — Link pages: DistributedTable (stores page configurations and
   link entries)
5. Data — Analytics: DistributedTable (stores daily aggregate snapshots
   per page slug and date)
6. Data — Visit events: DistributedTable (stores raw page-view, link-click,
   and share events)
7. Hosting: Blocks Hosting for the Next.js frontend
</architecture>

<acceptance_criteria>
- [ ] All existing frontend functionality works unchanged
- [ ] `npm run dev` starts both frontend and AWS Blocks local server on
      port 3000
- [ ] Admin routes require AuthBasic login
- [ ] Click tracking persists events to DistributedTable
- [ ] `npm run build` completes without TypeScript errors
- [ ] `npm run deploy` deploys the full stack to AWS
</acceptance_criteria>

The AI knows exactly what to build, what the constraints are, and what "done" looks like. No ambiguity on either side.

Writing good specs

Start with Goals and Non-Goals: what are you building? What are you explicitly NOT building?
Define your tech stack and project structure
Add executable commands so the AI knows how to build and run things
Write clear acceptance criteria so everyone knows when the work is done
Set your boundaries: what should the AI always do? What should it ask you first?

#6 Use MCP to Extend AI Beyond Its Knowledge

Model Context Protocol (MCP) is an open standard for connecting AI to the outside world. With MCP, your AI can:

Connect to data sources (local files, databases, APIs)
Run tools (search engines, calculators, linters)
Follow workflows and specialized prompts
Access knowledge that did not exist when it was trained

Right now there is an MCP server for almost everything: GitHub, Slack, databases, documentation, cloud services.

In my project, I used this in two places:

Frontend: I connected Figma MCP so the AI could reference my actual design system when generating components. Instead of describing colors and spacing in text, it pulled the tokens directly from the Figma file.

Backend: AWS Blocks is a new framework. The AI does not know its API surface from training data. Instead of pasting documentation into the chat (wasting context), I added an MCP server that gives the AI access to the AWS Blocks docs and API references on demand. It queries what it needs, when it needs it.

The result: zero hallucinated API calls. The AI uses new ApiNamespace(scope, 'api', (context) => ({...})) because it can look up the actual signature, instead of guessing something like createApi(...).

#7 Know When to Vibe Code and When to Spec

Some tasks deserve a spec. Others work fine as a quick conversation with the AI. Knowing which approach to use is what saves you time.

Use vibe coding when:

Prototyping something
Making smaller changes and tiny fixes
Learning syntax and a new technology
Automating one-off tasks

Use Spec-Driven Development when:

Building production software
Working in a team
Designing complex architecture
Working on brownfield projects (like adding AWS Blocks to an existing Next.js app)

In my project, I vibe coded the initial design exploration with Figma MCP. But the moment I started building the actual app and the backend migration, I switched to specs. The frontend BUILD_PROMPT.md and the backend AWS Blocks skill together gave the AI everything it needed to produce consistent, predictable results.

Wrapping Up

I am currently finishing the AWS Blocks backend for the link-sharing project and deploying it. I will write up that process in the next post.

You can find the full project, including the BUILD_PROMPT.md, AGENTS.md, MIGRATING_TO_CLOUD_PROMPT.md, and the AWS Blocks skill files in this repository.

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.

DEV Community: AWS

AI Agent Memory: Add Semantic Search Without a Vector Database

Why does key-value memory miss the question?

How does semantic search find it?

FAISS or Amazon S3 Vectors? Same accuracy, different deployment

So, do you need a vector database?

How does the agent choose between key lookup and semantic search?

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

How do you run the demo?

FAQ

Resources

Elizabeth Fuentes LFollow

Running Kiro Crew in Docker on Windows

What we're going to do

Starting with the official container image

Wait... a sandbox inside a container?

Where Docker gets in the way

The tempting solution and the better solution

Downloading the Kiro Crew seccomp profile

Running Kiro Crew

Let's open it

Authenticating Kiro CLI

Getting our dashboard token

References

7 Tips to Make Your AI Agent More Predictable

#1 Talk to AI in Clear Prompts

Zero-Shot

Few-Shot

Chain-of-Thought

#2 Set Absolute Boundaries

Prioritize negative boundaries (Guardrails)

#3 Give Your AI Persistent Context

Always-loaded: Steering files

On-demand: Skills

Keep it lean

Separate context from instructions

#4 Manage Your Context Window

Context rot

Fighting context rot

#5 Follow a Spec-Driven Development Process

Frontend spec (from BUILD_PROMPT.md)

Backend spec (from MIGRATING_TO_CLOUD_PROMPT.md)

Writing good specs

#6 Use MCP to Extend AI Beyond Its Knowledge

#7 Know When to Vibe Code and When to Spec

Use vibe coding when:

Use Spec-Driven Development when:

Wrapping Up

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

Frontend spec (from `BUILD_PROMPT.md`)

Backend spec (from `MIGRATING_TO_CLOUD_PROMPT.md`)

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

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