DEV Community: Vivek V.

I Crashed My Mac 5 Times So You Don't Have To: Mounting S3 Files on macOS

Vivek V. — Fri, 10 Apr 2026 05:46:45 +0000

Two days ago, AWS launched S3 Files — a managed NFS layer that turns any S3 bucket into a mountable filesystem. Sub-millisecond latency within AWS. Full read/write. Bidirectional sync. The AWS community collectively lost its mind, and rightfully so.

There's just one problem: it only works on AWS compute. EC2, Lambda, EKS, ECS. Not your Mac. Not your laptop. Not the machine where you actually write code.

I spent the last 48 hours fixing that. Along the way, I kernel-panicked my MacBook five times, got "access denied" in three different ways, discovered a crash bug in efs-proxy, and eventually built a tool that mounts S3 Files on macOS with two commands. This is the story of everything that went wrong, and the one thing that finally worked.

Why This Matters

As Corey Quinn put it, S3 has never been a filesystem — but now there's a real one sitting in front of it. Andy Warfield's team didn't just bolt a POSIX layer onto S3 and call it a day. They built a proper filesystem backed by EFS infrastructure, with S3 as the durable source of truth.

Think of S3 Files as another tier in the S3 hierarchy — a file system front end for hot, frequently accessed data that needs mutation, user interaction, or low-latency access. You create a file system on any bucket or prefix with no data migration. Your existing S3 data is immediately visible as files and folders.

The smart defaults are what make it feel magical:

Metadata pre-warms instantly. When you create a file system, all S3 key prefixes are mapped to directories and files. ls works immediately — no waiting. This is a massive differentiator from FUSE-based tools like Mountpoint, where ls on a large dataset can take minutes because it does a HEAD or LIST call per object.
Small files (under 128KB) auto-sync on directory access. When you cd into a directory, code files, configs, and small assets are pulled into the fast tier automatically. No explicit fetch needed.
Large files stream directly from S3. Files over 128KB are lazy-loaded on first read, and very large files may be served directly from S3's throughput layer without ever being copied into the file system tier. This is the ReadBypass optimization in efs-proxy — designed for EC2, but as we'll see, it doesn't play well with our non-standard Docker + NLB setup.

Changes sync back to S3 approximately every minute. Changes to S3 objects sync into the file system via EventBridge notifications. Data expires from the fast tier after 30 days by default (configurable) and rehydrates on next access.

AWS explicitly positions agentic AI as a first-class use case — multi-step, multi-process workloads where agents need to share state, read reference data, and produce outputs collaboratively. That's exactly the use case that got me excited enough to spend 48 hours making this work on a Mac.

And here's something that doesn't get enough credit: S3 Files shipped with Day 1 CloudFormation support (AWS::S3Files::FileSystem and AWS::S3Files::MountTarget). CDK works via L1 constructs — no native L2 constructs yet, but you can provision everything from IaC on Day 1. Our entire CDK stack — VPC, bucket, IAM role, S3 Files filesystem, mount target, NLB — deploys in one command. That's rare for a new AWS service these days. But what about local development? What about editing S3-backed files in VS Code on your Mac? What about ls, cat, echo "hello" > file.txt from your terminal?

That's what I wanted. A native Mac folder backed by S3.

The Problem: macOS Can't Speak S3 Files

S3 Files requires three things that macOS cannot provide:

NFSv4.2 — macOS ships with NFSv4.0. The NFS client is baked into the kernel. You can't upgrade it.
TLS encryption — S3 Files rejects every unencrypted NFS connection. No exceptions.
IAM authentication — Every mount requires an EFS RPC Bind handshake with AWS credentials, handled by a binary called efs-proxy (part of amazon-efs-utils). This only runs on Linux.

Three hard requirements. Zero macOS support. Let's see how many ways this can fail.

Attempt 1: Native macOS NFS Mount → 💀 Kernel Panic (x5)

My first instinct was the obvious one. S3 Files exposes a mount target with a private IP in your VPC. I put an internet-facing Network Load Balancer in front of it (TCP 2049), pointed my Mac at the NLB, and ran:

sudo mount -t nfs -o vers=4 nlb-dns.amazonaws.com:/ /mnt/s3files

The screen went black. Hard reboot. I tried again with different NFS options. Black screen. Reboot. I tried vers=4.0 explicitly. Black screen. Reboot.

Five kernel panics in total. macOS NFSv4 bugs are well-documented — the client chokes on protocol features it doesn't understand. When S3 Files responds with NFSv4.2 capabilities, the macOS NFS client doesn't gracefully degrade. It crashes the kernel.

Lesson: macOS NFSv4 is not just old — it's actively dangerous when pointed at a v4.2 server.

Attempt 2: Raw `mount -t nfs4` via NLB → ❌ "access denied"

OK, so macOS is out. I spun up a Docker container running Amazon Linux (which has a proper NFSv4.2 client) and tried a raw NFS mount from inside the container:

mount -t nfs4 -o nfsvers=4.2 nlb-dns.amazonaws.com:/ /mnt/s3files

"Access denied."

This is where I started reading the efs-utils source code. S3 Files isn't a standard NFS server you can just connect to. Before any NFS traffic flows, the client must authenticate via a custom protocol called EFS RPC Bind — essentially proving "I have valid AWS credentials and I'm allowed to mount this filesystem." The efs-proxy binary handles this. A raw mount -t nfs4 skips the entire auth layer.

Lesson: You can't just NFS-mount S3 Files. The auth isn't optional — it's the only way in.

Attempt 3: efs-proxy Without TLS → ❌ "access denied"

I installed amazon-efs-utils in the container and tried mount -t s3files. The efs-proxy binary started up, but I hadn't configured TLS properly (Docker isn't EC2 — there's no instance metadata service, no AZ info, no automatic certificate provisioning).

"Access denied." Again.

Digging into the efs-utils config, I found that efs-proxy wraps the TCP connection to port 2049 in TLS 1.2, then performs an RPC Bind — a custom handshake where the client proves it has valid AWS credentials. Think of it as mTLS with IAM instead of certificates. Without TLS, the mount target drops the connection before auth even begins.

I patched the config file (/etc/amazon/efs/s3files-utils.conf) to remove the {az_id} placeholder from the DNS format (no AZ metadata in Docker) and set the region via environment variable.

Lesson: S3 Files enforces TLS on every single connection. No TLS, no mount. Period.

Attempt 4: The IPv6 Detour → ✅ First Success (But Wrong Conclusion)

At this point I was convinced the NLB was the problem. Something about how it proxied TCP was breaking S3 Files at the NFS protocol level. So I built a workaround: bypass the NLB entirely.

The mount target ENI had an IPv6 address (assigned by the subnet's IPv6 CIDR). My Mac has IPv6 connectivity. Docker Desktop doesn't — but I could bridge the gap with a Python TCP proxy on my Mac that accepts IPv4 from Docker and forwards to the mount target over IPv6.

This required opening the mount target's security group directly to my public IPv6 address on port 2049. Not great — exposing a mount target to the internet is exactly the kind of thing Security Hub flags. But for debugging, I went with it.

Docker → Mac TCP bridge (IPv4:2049) → IPv6 → Mount Target (SG opened for my IPv6)

Inside the container, I used mount -t s3files with mounttargetip pointing at the Mac's Docker gateway. And it worked. Files appeared. Read/write confirmed. S3 sync verified. First success after hours of debugging.

But why did it work when the NLB path didn't? I assumed it was because I'd eliminated the NLB. Wrong.

The real reason: mount -t s3files automatically enables TLS. My earlier attempts used manual efs-proxy commands without TLS. The official mount helper adds it by default — S3 Files won't work without it.

Retried the NLB with mount -t s3files instead of manual efs-proxy. Worked perfectly. TLS was the missing piece all along. The NLB was fine — it's Layer 4, it just passes TCP bytes through, TLS and all.

I deleted the TCP bridge, removed the IPv6 SG rule, and moved on.

Lesson: when something works through path A but not path B, the difference might not be the path — it might be what path A does automatically that you forgot to do on path B.

Attempt 5: efs-proxy ReadBypass → ❌ Proxy Crash Loop

With the NLB working via mount -t s3files, I had one more problem. During my earlier manual efs-proxy debugging (before discovering the TLS fix), I'd hit a persistent crash:

ERROR efs_proxy::nfs::nfs_reader Error handling parsing error SendError { .. }

The proxy would connect, authenticate (BindResponse::READY), then crash the moment NFS traffic flowed. Restart. Crash. Restart. Hundreds of incarnations per second.

After reading the efs-proxy source and the mount.s3files Python wrapper, I found the culprit: the ReadBypass module. Remember how S3 Files serves large files directly from S3's throughput layer? ReadBypass is the efs-proxy implementation of that — it intercepts NFS read requests and serves them directly from S3, bypassing the NFS data path. This is designed for EC2 instances with direct VPC access to S3. In our setup — Docker container, patched efs-utils config, traffic routed through an NLB — the parser chokes on certain response formats and panics. It's not necessarily a bug in ReadBypass itself; it's that we're running efs-proxy far outside its intended environment.

The efs-proxy binary accepts a --no-direct-s3-read flag (I found this by running efs-proxy --help after the --no-read-bypass flag I guessed didn't exist). The mount -t s3files equivalent is the nodirects3read mount option.

With ReadBypass disabled, the proxy forwarded NFS traffic cleanly. No crashes.

Lesson: efs-proxy ReadBypass doesn't work in our non-standard Docker + NLB setup. Use nodirects3read to disable it. On a normal EC2 instance, it likely works fine.

Attempt 6: The Full Stack → ✅ It Works

The winning combination:

Docker (Amazon Linux) — provides NFSv4.2 kernel support
efs-proxy — handles TLS + IAM authentication
NLB — bridges Docker Desktop to the VPC mount target
nodirects3read — avoids the ReadBypass crash
WebDAV — re-exports the NFS mount to macOS as a native folder

Wait — WebDAV? Why not just use the Docker mount directly?

Because Docker Desktop runs in a Linux VM. The NFS mount lives inside that VM. To access it from macOS, you need to re-export it over a protocol that macOS can mount natively. The two candidates: SMB (Samba) and WebDAV.

I benchmarked both. The results were... not close.

The Benchmark: WebDAV Destroys SMB on macOS

Operation	Docker (NFS direct)	Mac (WebDAV)	Mac (SMB)
List directory	0.09s	0.08s	4.3s
Read small file	0.13s	0.05s	0.49s
Write + read back	0.27s	0.53s	1.7s

Throughput	Docker (NFS)	WebDAV	SMB
10 MB write	1.2s	1.4s	11.0s
10 MB read	0.10s	0.03s	0.42s
100 MB write	6.8s	9.3s	87.0s
Write throughput	~15 MB/s	~11 MB/s	~1.1 MB/s
Read throughput	~830 MB/s	~400 MB/s	~24 MB/s

WebDAV is 10–54x faster than SMB on macOS. Apple's SMB client is notoriously slow — it adds packet signing, metadata prefetching, and delayed TCP acknowledgments to every operation. A simple ls triggers dozens of round-trips. WebDAV is just HTTP requests — one request, one response, done.

I used WsgiDAV as the WebDAV server inside the container. It re-exports the NFS mount at /mnt/s3files over HTTP on port 8080. macOS mounts it natively via mount_webdav.

Region Matters: ca-central-1 vs us-east-2

Since the latency floor is internet RTT, I deployed the same CDK stack to two regions and benchmarked from my Mac in Canada:

Operation (Docker NFS)	us-east-2	ca-central-1	Improvement
List directory	0.09s	0.08s	~same
Read small file	0.13s	0.06s	2x faster
Write + read back	0.27s	0.16s	40% faster
10MB write	1.2s	1.0s	17% faster
10MB read	0.10s	0.06s	40% faster

The CDK stack is region-agnostic — just change -c region=ca-central-1. Pick the region closest to you. For me in Canada, ca-central-1 shaves ~40% off interactive operations.

The Architecture

Your Mac talks WebDAV to a Docker container. The container talks authenticated, encrypted NFSv4.2 to S3 Files through an NLB. The NLB is Layer 4 — it just forwards TCP bytes without inspecting or modifying the TLS payload. S3 Files syncs bidirectionally with your S3 bucket. From your Mac's perspective, it's just a folder.

The Developer Experience: Two Commands

I wrapped everything in a CDK stack and a shell script. The entire setup:

# 1. Deploy infrastructure (VPC, bucket, IAM role, S3 Files, NLB)
cd infra && npm install && npx cdk deploy -c region=ca-central-1

# 2. Mount
./docker/docker-mount.sh up <NLB_DNS_from_CDK_output>

# 3. Use it
ls /tmp/s3files/
echo "hello world" > /tmp/s3files/test.txt
open /tmp/s3files  # opens in Finder
code /tmp/s3files  # opens in VS Code

That's it. docker-mount.sh up builds the container, starts efs-proxy, mounts S3 Files via NFS, starts the WebDAV server, and mounts WebDAV at /tmp/s3files. One command. To tear down: docker-mount.sh down.

The CDK stack provisions everything: VPC with public subnet, S3 bucket (versioning enabled — required by S3 Files), IAM role with the elasticfilesystem.amazonaws.com trust policy, the S3 Files filesystem and mount target, an NLB forwarding TCP 2049, and security groups locking it down.

The Backstory: Mountpoint for S3 and the iPhone Backup That Almost Worked

This isn't my first attempt at mounting S3 locally. Last year, I experimented with Mountpoint for Amazon S3 on Windows via WSL2. Mountpoint is a FUSE-based client that presents S3 as a local filesystem — but it's optimized for read-heavy workloads. Writes are limited: you can create new files, but you can't modify existing ones in place.

I had a wild idea: back up my iPhone to S3 via iTunes. I mounted an S3 bucket using Mountpoint in WSL2, pointed iTunes at it, and kicked off a backup. The initial full backup actually worked — iTunes wrote all the files sequentially, which is exactly what Mountpoint handles well.

Then I tried an incremental backup. iTunes needs to read existing backup files, compare them, and overwrite changed ones. Mountpoint doesn't support overwrites. The backup failed.

S3 Files changes this equation entirely. Full read/write. In-place modifications. Bidirectional sync. The filesystem semantics that iTunes (and every other desktop app) expects. I haven't re-tested the iPhone backup scenario yet with S3 Files, but the technical blockers that stopped Mountpoint are gone. This could finally be the path to backing up an iPhone directly to S3 with full incremental support.

What's Next: Use Cases I'm Excited About

Shared IDE workspace. Mount the same S3 bucket from multiple machines. Edit files in VS Code on your Mac, pick up where you left off on your Linux workstation. S3 is the source of truth. No git push/pull dance for work-in-progress files.

Agentic AI shared state. This is the one that keeps me up at night. AI agents — coding assistants like Kiro, autonomous agents like OpenClaw — increasingly work with files: markdown docs, config files, memory stores, tool outputs. Mount an S3-backed filesystem as the agent's workspace. Multiple agents can read and write to the same shared state. The data lives in S3, durable and accessible from anywhere. It's a shared brain for your agent fleet.

Cross-platform development. Same S3 bucket, three platforms: macOS (via Docker + WebDAV), Windows (via WSL2 — native NFSv4.2, no Docker needed), Linux (native mount -t s3files). One source of truth, zero file sync tools.

A Note on WSL2

If you're on Windows, you might not need Docker at all. WSL2 runs a real Linux kernel (5.15+) with full NFSv4.2 support. You can install amazon-efs-utils directly in WSL2 and mount S3 Files natively — no WebDAV re-export, no container overhead. The mount appears as a Linux path accessible from Windows Explorer via \\wsl$\. You'd still need the NLB (or a VPN) for connectivity, but the protocol stack is native. I haven't tested this yet, but the kernel capabilities are all there.

S3 Files vs. Mountpoint for Amazon S3

For anyone wondering how these two compare:

	S3 Files	Mountpoint for S3
Protocol	NFS (NFSv4.2)	FUSE
Read/Write	Full read/write	Read-heavy (limited writes)
Latency	Sub-millisecond	Milliseconds
Sync	Bidirectional (S3 ↔ filesystem)	One-way (S3 → filesystem)
Requires	Mount target in VPC	Just IAM credentials
Platform	Linux only (EC2, ECS, EKS, Lambda)	Linux, macOS

S3 Files is a managed NFS filesystem with S3 as the durable backend. Mountpoint is a lightweight FUSE client for reading large datasets from S3. Different tools for different jobs. S3 Files gives you the full filesystem semantics that applications like databases, IDEs, and backup tools expect. Mountpoint gives you fast, cheap reads for data pipelines.

Security: What's Safe and What's Not

The PoC uses an internet-facing NLB so Docker Desktop can reach the mount target. This sounds scary, but the actual risk is mitigated:

S3 Files enforces TLS encryption and IAM authentication on every connection — you can't mount without valid AWS credentials
The NLB security group only allows inbound TCP 2049
The mount target security group only accepts traffic from the NLB security group

That said, for production use, replace the public NLB with AWS Client VPN. AWS documents this exact pattern for accessing EFS from on-premises networks, and it applies equally to S3 Files. VPN eliminates the internet-facing endpoint entirely. Also use private subnets with a Gateway endpoint for S3 — it's free and routes S3 traffic through the AWS network, bypassing NAT Gateway costs.

The Failure Table

Because every good debugging story deserves a summary of the wreckage:

Approach	Result	Root Cause
Native macOS NFS mount	💀 Kernel panic (5x)	macOS NFSv4.0 can't handle v4.2 responses
Raw `mount -t nfs4` (no efs-proxy)	❌ "access denied"	Missing EFS RPC Bind authentication
efs-proxy without TLS	❌ "access denied"	S3 Files requires TLS on all connections
efs-proxy with ReadBypass	❌ Proxy crash loop	ReadBypass incompatible with Docker + NLB setup
Docker + efs-proxy + TLS + NLB + `nodirects3read` + WebDAV	✅ Works	All requirements met

Try It Yourself

The entire project is open source (MIT): github.com/awsdataarchitect/s3files-mount

Two commands to go from zero to a native Mac folder backed by S3:

cd infra && npx cdk deploy -c region=ca-central-1
./docker/docker-mount.sh up <NLB_DNS>

If you try it, break it, improve it, or find new use cases — I'd love to hear about it. Open an issue, submit a PR, or find me on LinkedIn.

S3 has never been a filesystem. But as of this week, your S3 data can live in one — even on your Mac.

The AWS Dev Setup Nobody Told You About. Claude Code, Kiro Pro, and Agent Plugins.

Vivek V. — Sun, 05 Apr 2026 02:45:49 +0000

Agent Plugins for AWS

AWS recently released Agent Plugins for AWS, a set of structured skill packs for Claude Code covering serverless, deployment, SageMaker, and more. I wanted to test them. I already have a Kiro Pro subscription, so I used kiro-gateway to route Claude Code through it. No extra API subscription needed. Here's how that worked, and what broke along the way.

The Setup

Claude Code supports a ANTHROPIC_BASE_URL environment variable. Point it at a local kiro-gateway instance and Claude Code thinks it's talking to Anthropic's API. The requests route through your Kiro Pro subscription instead.

Step 1: Install Claude Code

Requires Claude Code version 2.1.29 or later.

npm install -g @anthropic-ai/claude-code

Step 2: Clone and set up kiro-gateway

git clone --depth=1 https://github.com/jwadow/kiro-gateway ~/kiro-gateway
cd ~/kiro-gateway
python3 -m venv .venv
.venv/bin/pip install -r requirements.txt

Step 3: Configure kiro-gateway

Create ~/kiro-gateway/.env:

PROXY_API_KEY="kiro-local-proxy-key"
KIRO_CLI_DB_FILE="/Users/<YOUR_USER>/Library/Application Support/kiro-cli/data.sqlite3"
SERVER_HOST="127.0.0.1"
SERVER_PORT="9000"

The KIRO_CLI_DB_FILE path points to your kiro-cli's auth database. On macOS it's under ~/Library/Application Support/kiro-cli/data.sqlite3.

Step 4: Start kiro-gateway

~/kiro-gateway/.venv/bin/python ~/kiro-gateway/main.py --port 9000 &

Step 5: Point Claude Code at it

Create ~/.claude/settings.json:

{
  "env": {
    "ANTHROPIC_BASE_URL": "http://127.0.0.1:9000",
    "ANTHROPIC_API_KEY": "kiro-local-proxy-key",
    "ANTHROPIC_MODEL": "claude-sonnet-4-6-20250929"
  }
}

Step 6: Run Claude Code

claude

On first run it asks "Do you want to use this API key?" Select Yes. That's the gateway proxy key. Anthropic never sees it.

Step 7. Install Agent Plugins

AWS Agent Plugins package four types of artifacts into a single installable unit:

Skills: structured workflows that guide Claude through complex tasks step by step. This is the core.
MCP servers: connections to live data, pricing APIs, documentation, and IaC validators.
Hooks: automation that runs on developer actions, like validating a SAM template after every edit.
References: documentation and config defaults that skills consult during execution.

Install them from inside Claude Code:

/plugin marketplace add awslabs/agent-plugins
/plugin install deploy-on-aws@agent-plugins-for-aws
/plugin install aws-serverless@agent-plugins-for-aws

Restart Claude Code after installing. Seven plugins are available in the marketplace: deploy-on-aws, aws-serverless, aws-amplify, databases-on-aws, amazon-location-service, migration-to-aws, and sagemaker-ai.

What each plugin does

aws-serverless ships three skills:

aws-lambda: Lambda functions, event sources, API Gateway, EventBridge, and Step Functions
aws-serverless-deployment: SAM and CDK deployment workflows
aws-lambda-durable-functions: workflow orchestration, saga patterns, and human-in-the-loop

When you ask Claude to build a serverless API, the relevant skill drives the process. The aws-serverless-mcp server provides live data underneath.

deploy-on-aws ships a single deploy skill with a five-step workflow: Analyze, Recommend, Estimate, Generate, Deploy. Three MCP servers back it: awsknowledge for architecture decisions, awspricing for live cost data, and aws-iac-mcp for CDK and CloudFormation validation. The Generate step produces CDK or CloudFormation code with security defaults applied. The Deploy step executes with your confirmation.

The aws-serverless plugin also ships a hook that runs sam validate automatically after every edit to template.yaml. You don't configure it. It fires on save and surfaces errors immediately.

sagemaker-ai is the newest addition. It ships 12 skills covering the full model customization lifecycle: use case definition, dataset evaluation, fine-tuning, model evaluation, and deployment on Amazon SageMaker AI. It also includes skills for managing SageMaker HyperPod clusters, running remote diagnostics via AWS Systems Manager, and generating issue reports. Install it the same way:

/plugin install sagemaker-ai@agent-plugins-for-aws

Trying it out. Cost estimation

Type this prompt exactly:

Deploy a serverless TODO API with DynamoDB. Estimate the monthly cost at 10,000 requests/day.

The deploy-on-aws skill runs its Analyze and Estimate steps. It calls get_pricing three times against the AWS Price List API: once each for Lambda, API Gateway, and DynamoDB. The cost table uses live numbers pulled at query time.

At 10,000 requests/day (300,000/month), the breakdown looks like this:

Service	Usage	Monthly Cost
Lambda requests	300K (free tier: 1M)	$0.00
Lambda duration	7,680 GB-sec (free tier: 400K)	$0.00
API Gateway (HTTP)	300K @ $1.00/million	$0.30
DynamoDB reads	180K RRUs @ $0.125/million	$0.02
DynamoDB writes	120K WRUs @ $0.625/million	$0.08
DynamoDB storage	~1 MB	$0.00

Total: ~$0.40/month

This is the screenshot moment. The skill called real AWS pricing APIs to produce that table.

Trying it out. Full plugin-driven deployment

The cost estimation above is the Estimate step. If you continue, the skill runs Generate next. That produces CDK or CloudFormation code with security defaults applied. Then Deploy runs an IaC security scan and asks for your confirmation before executing.

For the SAM path, the aws-serverless plugin takes over. Ask Claude to drive it:

Use SAM to deploy a serverless TODO API with DynamoDB to us-east-1.
Build and deploy it using the SAM tools.

Claude calls sam_init to scaffold the project, sam_build to compile it, and sam_deploy to push it to AWS. The aws-serverless-deployment skill guides each step.

Both paths use the plugins end-to-end. The difference is which skill drives the process.

Troubleshooting kiro-gateway:

kiro-gateway is an open-source project with active development. It works well for personal testing and experimentation, but expect some rough edges. Responses are slightly slower than direct Anthropic API calls because requests route through an extra local hop. Good enough for exploration.

Here are the two issues I hit.

1. Long tool names trigger a 400 error

Once Agent Plugins were installed, I immediately got this:

400 Improperly formed request

MCP servers generate verbose tool names like mcp__GitHub__check_if_a_repository_is_starred_by_the_authenticated_user (71 characters). The Kiro API has a hard 64-character limit. The original kiro-gateway code threw an error on any name over that limit, which broke every MCP server with descriptive tool names.

The fix is a patch to kiro-gateway that transparently shortens names before sending to Kiro and restores the originals in responses. Claude Code and MCP servers see the full names. Kiro sees names that fit its limit. I built this locally with Claude Code's help. It's not yet submitted upstream, so if you hit the same error, the patch is something you'd apply yourself for now.

2. aws-iac-mcp fails to build on Apple Silicon

The aws-iac-mcp server failed to start with:

the `x86_64-apple-darwin` target may not be installed

It depends on guardpycfn, a Rust-based Python package. On Apple Silicon, the build tool tried to cross-compile for x86_64 but the Rust target wasn't installed. One command fixes it:

rustup target add x86_64-apple-darwin

Restart Claude Code after running it.

Usage (again after fix)

Start the gateway:

~/kiro-gateway/.venv/bin/python ~/kiro-gateway/main.py --port 9000 &

Run Claude Code:

claude

Check gateway health:

curl http://127.0.0.1:9000/health

Cost

$0 extra. Your existing Kiro Pro subscription just works for this local experience. Claude Code uses the standard Anthropic API protocol. kiro-gateway translates it to Kiro.

Credits

@jwadow for kiro-gateway
awslabs for Agent Plugins for AWS

I Built a Real-Time Voice AI Confession Guide for 1.39 Billion Catholics. Every Bug Was Invisible.

Vivek V. — Thu, 26 Mar 2026 15:44:40 +0000

The Gap

75% of U.S. Catholics say they never go to confession or go less than once a year. Only 2% confess monthly. Those numbers come from Pew Research and CARA at Georgetown, and they've been trending in one direction for decades.

I built Mass Time, an iOS app with 280,000+ churches indexed, 60 prayers, and daily readings. I've watched the confession problem from the data side for years. People want to go. They feel anxious. They don't know what to say. They haven't been in so long that the guilt of not going becomes the reason they keep not going.

In 2025, the late Pope Francis declared a Jubilee Year and specifically called for increased access to the Sacrament of Reconciliation. The demand is real. The infrastructure isn't.

So I built an AI confession guide. No AI will ever replace a priest. Only a priest can grant absolution. This is a preparation tool. You talk to your phone. It talks back. Seven languages. No keyboard. Just a conversation that helps you organize your thoughts before you walk into that booth.

It uses Amazon Nova 2 Sonic, a bi-directional speech-to-speech model, running on Amazon Bedrock AgentCore Runtime. The bugs I hit building it were the worst kind: silent, invisible, and plausible enough to make you doubt everything except the actual problem.

The Architecture

Simple on paper. Brutal in practice.

Nova 2 Sonic handles the heavy lifting. It takes raw audio in, processes speech bidirectionally, and sends audio back. No separate STT or TTS pipeline. One model, both directions, real-time.

The server is a Python 3.13 container on AgentCore Runtime. The client is native Swift with AVAudioEngine. No web views, no React Native. Seven polyglot voices: English (Matthew), French (Florian), Spanish (Carlos), Italian (Lorenzo), German (Lennart), Portuguese (Leo), and Hindi (Arjun). Users can switch languages mid-conversation and the AI follows.

Region constraint worth knowing: Nova 2 Sonic is only available in us-east-1, us-west-2, and ap-northeast-1. I learned the us-east-2 limitation the hard way when my first deployment returned a model-not-found error.

The Bug That Almost Shipped

Nova 2 Sonic never responded to speech. I tried the Strands Agents SDK. Raw API calls. Different prompts. Different voices. Nothing.

The audio RMS values from the mic looked normal. Waveforms had energy. Everything seemed fine.

One line of Swift was wrong.

// WRONG: reads pointer-to-pointer memory (garbage audio)
Data(bytes: outBuf.int16ChannelData!, count: ...)

// CORRECT: reads actual audio samples
Data(bytes: outBuf.int16ChannelData![0], count: ...)

int16ChannelData is UnsafePointer<UnsafeMutablePointer<Int16>>. A pointer to an array of channel pointers. Without [0], you're reading the pointer addresses themselves as audio samples.

The RMS looked plausible because memory addresses happen to have high values. The model received garbage that looked like audio in every metric except the one that mattered: it wasn't audio.

I confirmed it by injecting known-good PCM on the server side. Model responded perfectly. Fixed the iOS code. Real mic audio worked.

One missing array subscript. Hours of debugging.

Two More Invisible Bugs

The app crashed on every AI response with _outputFormat.channelCount == buffer.format.channelCount. AVAudioPlayerNode was connected with the mixer's stereo format but I was scheduling mono buffers. Nova 2 Sonic outputs 24kHz mono PCM. The mixer expects stereo by default.

Fix: connect the player node with an explicit mono format matching the model's output.

let playFmt = AVAudioFormat(
    commonFormat: .pcmFormatInt16,
    sampleRate: 24000,
    channels: 1,
    interleaved: true
)!
audioEngine?.connect(playerNode!, to: audioEngine!.mainMixerNode, format: playFmt)

Key detail that isn't obvious from the docs: Nova 2 Sonic input is 16kHz 16-bit mono PCM, but output is 24kHz 16-bit mono PCM. Different sample rates in each direction.

Then the mic auto-unmute timer never fired. After the AI spoke, the mic stayed muted permanently. No error. No warning. Just silence.

Timer.scheduledTimer was called from the WebSocket callback thread. That thread has no RunLoop. The timer was created, registered to nothing, and quietly ignored. This is one of those iOS gotchas that experienced developers know and everyone else discovers at 2 AM.

The Cognito Session Policy Trap

This one is invisible and will waste your entire day.

Cognito Identity Pools have two auth flows: Enhanced (default) and Basic (classic). Every tutorial uses Enhanced. It works fine for S3, DynamoDB, Lambda.

It does not work for Amazon Bedrock (currently).

Enhanced flow calls getCredentialsForIdentity, which injects a restrictive session policy that limits credentials to a subset of AWS services. Bedrock is not in that subset. Your IAM role policy can be perfect. You'll still get AccessDeniedException.

The error message says "no session policy allows" but doesn't tell you Cognito is injecting it. You can't see this policy in IAM, CloudTrail, or the Cognito console. It's completely invisible.

Fix: one boolean in CDK.

const identityPool = new cognito.CfnIdentityPool(this, 'Pool', {
    allowUnauthenticatedIdentities: true,
    allowClassicFlow: true,  // This is the entire fix
});

On the client side, the classic flow requires three calls instead of one: getId → getOpenIdToken → STS AssumeRoleWithWebIdentity. The STS call is an unsigned HTTP POST, so you don't even need the STS SDK.

One boolean. Hours of debugging. Not documented clearly anywhere. This affects all Bedrock actions, not just Nova 2 Sonic.

Frugal Architecture: 60 Concurrent Sessions, Zero Quota Increases

Werner Vogels talks about the Frugal Architect: cost-aware design as a first-class engineering concern, not an afterthought. This project runs on my personal AWS account. No technical account manager. No need to request quota increases through a support plan. No need for using my "AWS Hero" Card.

Nova 2 Sonic has a default service quota of 20 concurrent InvokeModelWithBidirectionalStream requests per region (check your Service Quotas console under Amazon Bedrock for the exact current value). That's 20 simultaneous confessions per region before you hit throttling.

Instead of requesting a quota increase, I built a queue-based routing system across all three available regions.

REGIONS = ['us-east-1', 'us-west-2', 'ap-northeast-1']
MAX_PER_REGION = 20

def pick_region(counts):
    best = None
    for region in REGIONS:
        c = counts.get(region, 0)
        if c < MAX_PER_REGION and (best is None or c < counts.get(best, 0)):
            best = region
    return best

3 regions × 20 concurrent sessions = 60 simultaneous confession sessions. On default quotas. No support ticket. No TAM call.

The latency difference between regions is negligible for this use case. A confession guide isn't a trading bot. An extra 80ms of round-trip to Tokyo doesn't matter when the conversation has natural 2-second pauses between turns.

Design around the constraints you have instead of asking for the constraints to be removed.

Nova 2 Sonic Configuration That Matters

Turn detection sensitivity set to LOW for confession preparation. That's roughly a 2-second pause before the model responds. You want thoughtful pauses in this context, not rapid-fire conversation.

await send_evt({"event": {"sessionStart": {
    "inferenceConfiguration": {"maxTokens": 1024, "topP": 0.9, "temperature": 0.7},
    "turnDetectionConfiguration": {"endpointingSensitivity": "LOW"}
}}})

Available values: LOW, MEDIUM, HIGH. For most conversational use cases, MEDIUM is fine. For reflective, thoughtful conversations, LOW gives the user space to think.

Connection limit is 8 minutes per WebSocket connection. For longer sessions, AWS provides a session continuation pattern in their samples.

System prompt gotchas worth knowing:

Without explicit instructions, the model repeats its welcome message on every turn. You need: "FIRST RESPONSE ONLY: Welcome with 'In the name of the Father...' AFTER THE FIRST RESPONSE: Do NOT repeat the welcome ever again."
Hindi requires the speech instruction appended inline to the system prompt text, not as a separate content block. A separate block caused Hindi to be completely silent. No error. Just silence.
Nova 2 Sonic sends { "interrupted": true } as JSON text during barge-in. Filter it server-side or your transcript gets polluted with raw JSON.

Echo Cancellation: Still an Active Problem

The iPhone speaker plays the AI's voice. The mic picks it up. The model hears itself and responds to its own echo. This is the hardest problem in the entire project.

Four approaches, in order of desperation:

Flag-based mute when AI speaks. Problem: contentEnd means the server finished sending, not the speaker finished playing.
Playback completion unmute using scheduleBuffer completion handlers. Better timing, still some leakage.
Send silence while muted. Zero-filled PCM frames keep the bidirectional stream alive while preventing echo from reaching the model.
Prompt-level echo awareness: "You will hear your own voice echoed back. If you hear words identical to what you just said, that is YOUR OWN ECHO. IGNORE IT."

The official AWS Python sample never mutes the mic. Audio flows continuously in both directions. Nova 2 Sonic has built-in turn detection and handles echo internally. That works better on desktop where mic/speaker separation is cleaner. On a phone speaker, it's a different story.

Current approach: silence-based muting + playback completion unmute + prompt-level echo awareness. Works about 90% of the time. The other 10% is still an active problem.

The Economics

Nova 2 Sonic pricing (per 1K tokens): $0.0034 speech input, $0.0136 speech output. That works out to roughly $0.02/min combined.

A 5-minute session costs about $0.10. Not $1. Not $5. Ten cents.

At $1.99 per session, after Apple's 30% cut ($1.39 net), that's about $1.29 profit per paid session. The margins are real.

The freemium flow: 1 free minute (configurable via DynamoDB, no app update needed), then a paywall. Pay $1.99 to continue for up to 5 minutes. A 30-second grace period after the paywall gives users time to decide. The free minute costs about $0.02 to deliver. Even if nobody converts, the free tier costs almost nothing to run.

	Per Session
Nova 2 Sonic cost (5 min)	~$0.10
User pays	$1.99
Apple's 30% cut	-$0.60
Net to developer	$1.39
Profit	~$1.29

Session recordings are AI audio only, stored locally on the user's device. Never on servers. The user can save and share via the standard iOS share sheet.

Total AWS infrastructure cost for the backend? Lambda, DynamoDB, API Gateway, AgentCore Runtime. On a personal account with low traffic, we're talking single-digit dollars per month before any sessions even happen.

What's Next: AgentCore WebRTC

On March 20, AWS announced WebRTC support for AgentCore Runtime. This is a big deal for this project.

Right now, the audio path is: iPhone → WebSocket → AgentCore → Nova 2 Sonic. WebSocket works, but it's a text-based protocol carrying base64-encoded audio. Every audio frame gets encoded, wrapped in JSON, and decoded on the other end.

WebRTC is purpose-built for real-time media. Binary audio frames. Built-in echo cancellation at the protocol level. Adaptive bitrate. Jitter buffers. All the things I've been fighting to implement manually in Swift.

The migration path is straightforward since AgentCore Runtime supports both protocols on the same runtime. I can add a WebRTC endpoint alongside the existing WebSocket one and A/B test latency and echo cancellation quality on real devices.

If WebRTC's built-in echo cancellation works well on iPhone speakers, that solves the hardest remaining problem in the entire project. That 10% failure rate on echo could drop to near zero.

What I'd Do Differently

Verify audio end-to-end on day one. Inject a known sine wave, record what the model receives, compare. Would have saved hours of headache.

Start with the classic Cognito flow. Don't even try enhanced flow with Bedrock. It won't work and the error messages won't tell you why.

Build echo cancellation as a first-class feature, not an afterthought. On mobile, this is the hardest problem. Budget time for it.

Use Docker assets (ECR) for AgentCore from the start. Code assets (S3) seem simpler to package but the cold start timeout makes them impractical for anything with dependencies.

Design for multi-region from day one. The frugal routing across three regions was an afterthought that should have been the starting architecture. Default quotas are generous if you think horizontally.

The Point

1.39 billion baptized Catholics worldwide. A sacrament that many want to practice but feel unprepared for.

This isn't about replacing priests. It's about removing the anxiety barrier that keeps people from showing up in the first place. A 5-minute voice conversation that helps you organize your thoughts, in your own language, on your own time. For ten cents of compute.

Building this was fast. The debugging was not. Every major bug was the invisible kind: plausible RMS values hiding garbage audio, silent timers on runloop-less threads, session policies you can't see in any console. The documentation had gaps. Echo cancellation on a phone speaker remains partially unsolved.

Most of the code was written with Kiro CLI. What would have taken weeks of back-and-forth between Swift, Python, and CDK was done in hours.

But someone will open this app before their first confession in 20 years. And they'll feel a little less anxious walking in.

That's worth ten cents. Now go build.

I Turned Notion Into a Control Plane for my 18 OpenClaw AI Agents

Vivek V. — Sat, 07 Mar 2026 05:43:11 +0000

This is a submission for the Notion MCP Challenge

What I Built

OpenClaw just got an Amazon Lightsail blueprint. No more Mac Minis. No more Raspberry Pis sitting on your desk acting as your AI agent server. Click deploy and you have an agent platform running in the cloud.

AWS samples also has an experimental (non-production) implementation that runs OpenClaw as per-user serverless containers on AgentCore Runtime. The serverless version is early, but the direction is clear.

That means OpenClaw can now run in different places. A Raspberry Pi on my desk. A Lightsail instance in the cloud. Serverless containers on AgentCore or even on an EC2. Pick a flavor. (I didnt buy a Mac Mini)

I run 18 agents on mine. These aren't toy demos. They solve problems I got tired of solving by hand.

After re:Invent last year, every expo vendor on the floor started emailing me. Booth scans, follow-ups, drip campaigns. Unsubscribing from each one is death by a thousand clicks. So I built an unsubscribe agent. I don't give it access to my personal mailbox. I forward vendor spam to OpenClaw's own email inbox. It parses the email, finds the unsubscribe link, clicks it, and confirms. I set up one mail rule and forgot about it. 47 vendor lists cleared in two weeks.

Then there's the train monitor. After peak hours, the next train home is an hour away. Miss it and you're standing on a cold platform for 60 minutes. The problem is trains don't always behave. Sometimes it arrives a minute early. Sometimes it switches platforms with no announcement. I was refreshing the train app constantly. The agent polls live train data and pushes me a notification when something changes. Platform switch, early arrival, cancellation. I get the update instead of checking.

OpenClaw even built me a full SaaS-like newsletter platform "The Agentic Engineer". I wanted a weekly newsletter to keep me updated on the Agentic AI content that I am interested in - along with a platform for subscriber management, double opt-in, click tracking, A/B subject lines, archive pages with SEO, threaded comments, the works. Instead of stitching together Substack or Beehiiv or whatever, I pointed the ask to OpenClaw and let it go. CDK stacks, Lambda functions, DynamoDB tables, SES integration, CloudFront distribution — it scaffolded the entire thing. Then another agent writes and publishes the issues. The platform runs on autopilot. I haven't touched it in weeks. It has more features than most newsletter SaaS tools I've paid for, and it costs me about $2/month in AWS bills. An example of true SaaSpocalypse.

Now multiply that by 18 agents, all running on cron schedules, and you hit the real problem of migrating or cloning your agentic work at 10X scale.

The Agent Migration Problem

Managing 18 agents was already a mess. SSH into a server. No single view other than the OpenClaw Dashboard. No way to pause an agent without editing config files or telegraming the OpenClaw. No full history of what ran, what failed, or how many tokens got burned.

But with three deployment targets, a new problem showed up: how do you move your agents between them along with their identity and history?

Each agent has a custom prompt, a personality file, tool configurations, cron schedules. My unsubscribe bot has mail parsing rules. My train monitor has API polling configs. 18 agents worth of state that lives in files on disk.

Migrating that from a Raspberry Pi to a Lightsail blueprint by hand? Copying config files, re-editing cron tabs, testing each agent one by one? I'd rather stand on that cold train platform for an hour.

I needed a control plane that was portable. Something that could snapshot my entire fleet, move it to a new instance, and bring everything back up. And I didn't want to run a database for it.

So I built AgentOps. And I built it on Notion.

AgentOps turns Notion into the control plane for an entire OpenClaw agent fleet. Four Notion databases form the backbone:

Agent Registry. 18 OpenClaw agents, each a row. Name, type, status, schedule, config, last heartbeat. Change status to "paused" in Notion and the runtime stops dispatching to it.

Task Queue. Every task with priority, status, assigned agent. Create a row in Notion, the OpenClaw runtime picks it up automatically.

Run Log. Every execution recorded. Input, output, duration, tokens used, errors. 78 runs tracked so far.

Alerts. Failures surface immediately. Acknowledge them with a checkbox click.

The key design decision: Notion IS the database. No Postgres. No MongoDB. Every read and write goes through the Notion API. You control your OpenClaw agents by editing Notion pages.

On top of that, AgentOps includes:

Token analytics. Per-agent breakdown, daily trends, top consumers. 128K+ tokens tracked across all OpenClaw agent runs.

Workspace sync. Push your OpenClaw agent configuration files (prompts, personality, tools) to Notion. Edit them there. Pull changes back to your OpenClaw instance.

Agent tuning. Bidirectional prompt sync. Edit an OpenClaw agent's prompt in Notion, apply it live with one click.

Full backup. Snapshot your entire OpenClaw agent fleet to a Notion page. Workspace files, prompts, cron definitions, agent registry. Restore anytime.

Fleet cloning. Export your OpenClaw agent fleet as a portable JSON bundle. Import it on a fresh instance. Your entire AI operation, portable.

All of this data lives directly in your Notion workspace. Agent Registry, Task Queue, Run Log, Alerts, Backups, Agent Prompts. No external database. Open Notion and you see everything.

Three built-in agents ship with it (summarizer, code reviewer, sentiment analyzer) that work end-to-end through Notion without any external AI API keys. Create a task, watch it get dispatched, see results land in the Run Log.

Video Demo

The Code

awsdataarchitect / agentops

Notion-powered control plane for OpenClaw AI agents — monitor, dispatch, tune, backup, and clone your agent fleet

🤖 AgentOps — Notion-Powered Control Plane for OpenClaw Agent Fleets

Notion MCP Challenge Entry — Use Notion as the human-in-the-loop command center for managing OpenClaw AI agents.

AgentOps turns your Notion workspace into a fully functional agent operations control plane. Monitor your OpenClaw fleet, dispatch tasks, track token usage, tune agent prompts, and backup your entire configuration — all through Notion.

Humans stay in control. Every agent, task, and configuration lives in Notion. Edit a page to pause an agent. Change a priority by updating a select field. Notion is the database.

📸 Screenshots

Dashboard

Real-time overview of your OpenClaw agent fleet — 18 agents, success rate, token usage, pipeline health, and recent activity.

Agent Registry

All 18 OpenClaw agents with status, schedules, and one-click pause/resume. Filter by type: cron, monitor, heartbeat, subagent, or demo agents.

Task Queue

Priority-based task queue with status tracking. Create tasks manually or let the…

View on GitHub

Stack: Node.js, Express, React 19, Vite, Tailwind CSS v4, @notionhq/client

Architecture:

┌─────────────────────────────────────────────┐
│                  Notion                     │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐     │
│  │  Agent   │ │  Task    │ │  Run     │     │
│  │ Registry │ │  Queue   │ │  Log     │     │
│  └────┬─────┘ └────┬─────┘ └────┬─────┘     │
│       │            │            │           │
│  ┌────┴────────────┴────────────┴─────┐     │
│  │         Notion API (MCP)           │     │
│  └────────────────┬───────────────────┘     │
└───────────────────┼─────────────────────────┘
                    │
        ┌───────────┴───────────┐
        │    AgentOps Server    │
        │  ┌─────────────────┐  │
        │  │  Agent Runtime  │  │
        │  │  (10s polling)  │  │
        │  └────────┬────────┘  │
        │  ┌────────┴────────┐  │
        │  │  Demo Agents    │  │
        │  │  • Summarizer   │  │
        │  │  • Code Review  │  │
        │  │  • Sentiment    │  │
        │  └─────────────────┘  │
        │  ┌─────────────────┐  │
        │  │  OpenClaw Fleet │  │
        │  │  (14 cron jobs) │  │
        │  └─────────────────┘  │
        └───────────┬───────────┘
                    │
        ┌───────────┴───────────┐
        │   React Dashboard     │
        │  • Fleet overview     │
        │  • Token analytics    │
        │  • Workspace sync     │
        │  • Agent tuning       │
        │  • Backup & clone     │
        └───────────────────────┘

How I Used Notion MCP

Notion MCP is the entire persistence and control layer for OpenClaw agents. There is no other database. Here's how each piece works.

Agent Registry (notion-create-pages, notion-update-page, notion-query-database-view)

Every OpenClaw agent is a Notion database row. The runtime queries for active agents before dispatching. Pause an agent by changing its status select property. The runtime reads it on the next 10-second poll and skips it. Resume by switching back to "active." Zero config files touched.

Task Queue (notion-create-pages, notion-query-database-view)

Tasks are Notion rows with status, priority, and agent type. The runtime queries for pending tasks sorted by priority, matches them to active OpenClaw agents, updates status to "running," executes, then marks "completed" or "failed." You can create tasks directly in Notion and the system picks them up.

Run Log (notion-create-pages)

Every OpenClaw agent execution writes a detailed record: input, output, duration in milliseconds, tokens consumed, error messages. This feeds the token analytics dashboard and provides full audit history.

Alerts (notion-create-pages, notion-update-page)

When an OpenClaw agent fails, an alert row is created automatically. The "Acknowledged" checkbox lets operators dismiss alerts from Notion or the dashboard.

Workspace Sync (notion-create-pages, notion-update-page)

OpenClaw agent configuration files (personality, tools, prompts) are pushed to Notion as formatted pages. The markdown-to-blocks converter handles headings, paragraphs, lists, code blocks, and bold/italic annotations. Secrets are automatically redacted before sync.

Agent Tuning (notion-create-database, notion-create-pages, notion-fetch)

A dedicated "Agent Prompts" database stores each OpenClaw agent's prompt. Edit in Notion's rich editor, pull changes back to disk, and apply live to the running OpenClaw instance. Bidirectional sync with diff detection.

Backup (notion-create-pages, notion-fetch)

Full OpenClaw fleet snapshots stored as Notion pages with toggle blocks containing workspace files, prompts, cron definitions, and agent registry data. Restore writes files back to disk from Notion content. Export as JSON for cloning to a fresh OpenClaw instance.

Why This Matters

The human-in-the-loop problem for AI agents is real. Most agent systems are black boxes. You deploy them and hope. Notion MCP turns Notion into a transparent control surface where non-technical operators can monitor, pause, configure, and audit OpenClaw agents using an interface they already know. No SSH. No config files. No dashboards that only engineers can read.

But the portability angle is what I didn't expect to matter this much.

OpenClaw is spreading. Lightsail blueprints. AgentCore serverless containers. Raspberry Pis. People are running their claws on different platforms, and they will keep moving between them as the options get better. The agents, prompts, schedules, and configs need to travel with them.

AgentOps makes Notion the portable layer. Backup your Pi claw to Notion. Spin up a Lightsail blueprint. Import. Done. All 18 agents, their prompts, schedules, and configs. Moved in minutes, not hours.

18 agents. All runs logged. All tokens tracked. Four Notion databases. Zero external databases. Three deployment platforms. One control plane.

Your Notion workspace becomes the operating system for your claw. 🦞

AgentBoard: A Discovery Platform for the Agentic AI Community

Vivek V. — Sat, 28 Feb 2026 01:14:21 +0000

This is a submission for the DEV Weekend Challenge: Community

The Community

I write for The Agentic Engineer, a weekly newsletter tracking the agentic AI space. The readers are builders. They ship autonomous agents, multi-agent workflows, and AI tools for a living.

The number one question I get: "Which framework should I use?"

There are 15+ major agent frameworks right now. New ones launch weekly. You either scroll GitHub trending, ask Twitter, or hope someone wrote a comparison post this month. There's no single place to browse, compare, and discover what's out there.

That's the community AgentBoard serves: agentic AI builders who need a front door to the tools they're building with.

What I Built

AgentBoard is an open directory for AI agents, frameworks, and tools. Think Product Hunt, but only for agentic AI.

You can:

Browse 15 pre-seeded agents across 8 categories (dev tools, automation, research, infrastructure, and more)
Search by name or filter by category
Sort by GitHub stars, upvotes, or newest
Click into any agent for the full breakdown: tech stack, creator, description, links
Upvote and bookmark your favorites (persists locally)
Submit your own agent through a simple form

No login. No backend. Everything runs client-side with localStorage.

Demo

Live site: natearcher-ai.github.io/agentboard

The home page shows community stats and featured agents. The Discover page is the core: real-time search, category filter tabs, and three sort modes. Click any card for the full agent profile. Hit Submit to add your own.

Code

natearcher-ai / agentboard

AgentBoard — Community-driven AI agent discovery platform. Browse, share, and celebrate AI agents built by the community.

AgentBoard 🤖

Community-driven AI agent discovery platform.

Browse, share, and celebrate the AI agents, skills, and tools shaping the future of autonomous AI.

🔗 Live: natearcher-ai.github.io/agentboard

What is AgentBoard?

AgentBoard is an open directory for the agentic AI community. Think Product Hunt meets Awesome Lists — specifically for AI agents and tools.

Features:

🔍 Browse & search a curated directory of AI agents
🏷️ Filter by category (dev tools, automation, research, etc.)
📋 Detailed agent profiles with tech stack, links, and descriptions
➕ Submit your own agents via a simple form
⬆️ Upvote and bookmark your favorites
📊 Community stats dashboard
🌙 Beautiful dark theme with smooth animations
📱 Fully responsive (mobile + desktop)

Screenshots

Home

The landing page features a hero section, community stats, and featured agents.

Discover

Filterable, searchable directory with category tabs and sort options.

Submit

Clean form to contribute your own AI agent to the directory.

…

View on GitHub

How I Built It

Stack: React 19, Vite, Tailwind CSS v4, React Router, Lucide icons.

I went with a static SPA on purpose. No database means no hosting costs, no auth complexity, and anyone can fork it and run it locally in 30 seconds. The seed data lives in a single JS file. Adding a new agent is one object in an array.

The UI is dark-themed with a purple/blue gradient palette. Cards have hover animations. The discover page supports real-time search, category tabs, and three sort modes. The submit form validates inputs and drops you straight into the directory after submission.

Deployed via GitHub Actions to GitHub Pages. Push to main, site updates in under a minute.

MIT licensed. PRs welcome.

I Promised an iOS App. Kiro CLI and Xcode MCP Built It in Hours.

Vivek V. — Tue, 24 Feb 2026 19:54:46 +0000

Recap

In my previous blog post, I shared a weekend vibe coding project. An AI-powered Costco Receipt Scanner and Price Match Agent. Completely serverless with Amazon Bedrock AgentCore. Nova AI parsing receipts. CDK deploying everything. Weekly email reports with price adjustment opportunities.

My post on LinkedIn got more traction than anything I’d ever shared. More views than all my previous posts combined, which says more about my previous posts than this one. The blog was also featured in DEV’s Top 7 posts of the week, along with a Top-7 badge which got automatically added to my dev.to profile.

I also promised a native iOS app for the frontend. This is that follow-up. But the story took a turn I didn't expect.

10 Years Apart

In 2016, I built my first iOS app as a side project while learning Swift, which had recently debuted as Apple’s programming language for iOS. I outsourced a complex functionality to a developer for around $500. The whole development cycle took months but that is how I learn something new by building it myself. Getting the iOS app approved by Apple was its own ordeal if you know what I mean.

In February 2026, Apple released Xcode 26.3 with MCP support. I pointed Kiro CLI (using latest Claude Opus 4.6 model) at Xcode through the MCP bridge and built the entire iOS app in hours.

Not a toy. Not a single-screen demo. A full four-tab app with receipt scanning, deal tracking, AI-powered price match analysis with streaming responses, and a settings screen with BYOI configuration.

The Xcode MCP Bridge

Apple's official documentation explains how to give agentic coding tools access to Xcode. The Kiro (IDE + CLI) setup is just three lines in your MCP config:

"mcpServers": {
  "xcode-tools": {
    "command": "xcrun",
    "args": ["mcpbridge"]
  }
}

Prerequisites: Xcode 26.3 or later. That's it.

The bridge exposes about 20 MCP tools to the AI agent. BuildProject runs incremental builds in 0.9 seconds. XcodeRead, XcodeWrite, and XcodeUpdate handle file operations directly in the project structure. XcodeGrep searches code. GetBuildLog surfaces compiler errors. RenderPreview shows SwiftUI previews. RunSomeTests executes test suites.

The development loop changes completely. I describe what I want in natural language. The agent writes Swift code, triggers a build through MCP, reads the compiler errors, fixes them, rebuilds. The whole cycle takes seconds.

Here's the actual prompt that kicked it off:

Build me an iOS app using Amplify SDK for Swift, leverage all the backend APIs we already have. Use the Xcode MCP tools. Make it professional and state of the art. I want to publish it, but I don't want to use my AWS infra. Let the user put their API endpoint into Settings, and everything gets picked up from there. That way whoever deploys the stack can use the app from their own infra. I don't worry about scaling or charging them for tokens by being just an Uber or Airbnb of this thing.

That's it. That was the prompt. Kiro CLI took it from there with a few iterations and refinements to polish it up.

Same Backend, New Frontend

The original post described the full serverless backend: Lambda running FastAPI, API Gateway with JWT auth, DynamoDB for receipts and deals, S3 for PDF storage, Bedrock for Nova AI parsing and analysis, AgentCore Runtime for the weekly agent, EventBridge Scheduler firing every Friday at 9pm, SES for email reports.

All of that stays exactly the same. The iOS app just connects to the existing API Gateway endpoint. Same Cognito auth. Same routes. Same everything.

I originally planned to use Amplify Library for Swift. I tried it. Build times jumped to 18 seconds. The SDK pulled in a lot of dependencies I didn't need for this use case.

So I ripped it out. Zero third-party packages. Pure URLSession for API calls. Direct Cognito REST API calls for authentication using USER_PASSWORD_AUTH flow. Build time dropped to 0.9 seconds.

BYOI: Bring Your Own Infrastructure

This is the part that changed my thinking about app distribution.

CostScanner is not a SaaS. I don't host anything for users. I don't run servers. I don't store anyone's data. Note: I had to change the name with no Costco word in it due to obvious trademark and app publising reasons.

Users deploy their own AWS CDK stack. Three stacks: one for DynamoDB tables and S3 bucket, one for Lambda and API Gateway and Cognito, one for the weekly AgentCore agent. One cdk deploy command.

cd infra && npm install
NOTIFY_EMAIL=you@example.com ./deploy.sh

Then they paste their API Gateway URL into the app's Settings screen. The app calls a /api/config endpoint, fetches the Cognito pool details and credentials from Secrets Manager, signs in programmatically, and starts working.

No sign-in screen. No account/user creation flow. No "forgot password" emails. The infrastructure IS the account/user. I would love to see a "sign-in with AWS" or "Builder ID" API from Amazon for the login flows!

The privacy policy literally says "we collect nothing." Because we don't. Every receipt, every deal, every AI analysis result lives in the user's own AWS account. They can cdk destroy and everything disappears.

Here's what this means for scaling: nothing. I don't worry about it. Unlike Airbnb or Uber, I don't provision capacity for peak load. I don't manage database connections. I don't handle multi-tenant data isolation. Each user's infrastructure scales independently through AWS serverless services. If one user uploads 500 receipts, that's their Tokens, Lambda and their DynamoDB handling it.

The Numbers

15 Swift files
0 third-party dependencies
0.9 second incremental builds
3 CDK stacks
Under $1 per month AWS cost per user
Bedrock Nova tokens: $0.10-0.20 per week
Lambda, DynamoDB, API Gateway, S3: free tier for personal use

What I Learned

The original backend and web app were built in hours with Kiro CLI. The iOS frontend? Even faster, thanks to the MCP bridge. The difference isn't just speed. It's the feedback loop.

With the MCP bridge, the AI agent doesn't just write code. It builds it, reads the errors, and fixes them. I'm not copying compiler output into a chat window. The agent sees what Xcode sees. It knows when the build succeeds. It knows when a type doesn't conform to a protocol. It fixes it and moves on.

The BYOI model is something I want to explore more. For personal tools and utilities, the SaaS model adds complexity that nobody asked for. User management, billing, support, scaling, compliance. BYOI sidesteps all of it. The user owns their stack. You ship the app and the CDK templates. Done.

Ten years between my first iOS app and this one. Back then I paid $500 to outsource functionality and spent months shipping it. This time I used Kiro Pro at $20/month, connected through IAM Identity Center (IdC) login to seamlessly use my AWS credits (thanks to the AWS Heroes program). The whole iOS app was done in hours.

In ten years, almost everything about building software feels completely different. The tools have evolved. The cost of building has significantly dropped. Even how software reaches users feels different now.

But the hot dog combo is still $1.50 and the rotisserie chicken is still $7.99 (in Canada). Now I scan my receipt before I leave the Costco parking lot!

❤️ Built with Kiro CLI, Amazon Bedrock, AWS CDK, and Apple's Xcode MCP bridge.

🔗 Full source code: github.com/awsdataarchitect/costco-price-match

📱 Download CostScanner: App Store

What are you going to build with Kiro CLI and Xcode MCP bridge ? Let me know in the comments.

I've Been a Costco Member for 25 Years. Last Month I Built an AI Agent to Get My Money Back

Vivek V. — Fri, 13 Feb 2026 23:45:21 +0000

Background

I've been a Costco member since 2001. That's 25 years of bulk toilet paper, ziplock bags, and the occasional impulse buy of a 48-pack of batteries I definitely didn't need.

Over those years, one thing has kept me loyal: their customer service. It's genuinely good. It reminds me of Amazon's Customer Obsession Leadership Principle, where the customer is the starting point and you work backwards from there. Costco lives that.

The Pattern I Couldn't Ignore

Here's something that kept happening to me. I'd buy a jacket for $24.99 on a Tuesday. The following week, I'd walk past the same jacket with a new price tag: $5.00 off. I'd buy a bag of dumplings for $14.99. Two weeks later, on sale for $11.99. This happened over and over. I started to wonder if Costco was personally timing their sales around my shopping trips.

Costco has a price adjustment policy. If something you bought goes on sale within 30 days, you can go to the membership counter and get the difference back. The problem is you have to know it went on sale. You have to remember what you paid. You have to dig up the receipt. And you have to actually go do it before the 30 days are up.

I never did any of that. I just ate the difference every time.

So I Built a Thing

I'm a builder. When I see a repetitive problem, I want to automate it. So I built an AI-powered Costco Receipt Scanner & Price Match Agent that does the whole thing for me. Completely Serverless with Amazon Bedrock AgentCore!

Here's what it does:

I upload my receipt PDFs (from my phone, from email, wherever)
Amazon Nova AI parses every line item, price, item number, and whether I already got a temporary price drop
Scrapers pull current deals from the web and Costco coupon book
An AI agent cross-references my purchases against every active deal and tells me exactly which items dropped in price, how much I'd save, and what to say at the counter

The whole thing runs on AWS. FastAPI backend, DynamoDB for storage, S3 for receipt PDFs, Bedrock for the AI, and a web UI I can hit from my laptop or phone.

The Weekly Agent

I didn't want to manually check every week. So I built and deployed an Amazon Bedrock AgentCore agent with Strands SDK that runs automatically every Friday at 9 PM. It scrapes all the deal sources, runs the analysis across every receipt I've uploaded, and emails me a formatted HTML report via SES.

The report has two sections. The first table shows price adjustment opportunities: items I paid full price for that are now on sale, with the exact savings per item. The second table shows items where Costco already applied a Temporary Price Drop (TPD) at checkout, so I can see what I saved without doing anything. Every item links back to the actual deal post so I can verify the prices myself, and every receipt reference is a presigned S3 link to the original PDF.

Friday night I get an email. Saturday morning I walk into Costco with my receipts. Done.

The first time it ran, it found $9 in price adjustments I would have missed and confirmed $18 in TPD savings I didn't even know I'd gotten. Not life-changing money, but it adds up when it happens every week.

The Architecture

For anyone who wants to look under the hood:

Frontend: Single HTML file hosted on AWS Amplify, with Cognito authentication. Same file works locally during development with no auth. Environment-aware through a config.js that gets generated at deploy time.
API: API Gateway HTTP API with Cognito JWT authorizer, backed by a Lambda function running the FastAPI app via Mangum. The analysis endpoint streams results back to the browser in real time so you can watch the AI think through each item match as it happens.
AI: Amazon Nova models for receipt parsing (OCR) and price match analysis. Nova 2 Lite for standard parsing, Nova Premier for complex receipts that need a second pass.
Automation: AgentCore Runtime runs the weekly agent inside a container. EventBridge Scheduler triggers it using a universal target (aws-sdk:bedrockagentcore:invokeAgentRuntime) that calls AgentCore directly with zero Lambda functions in between. The agent scans deals, runs analysis, converts the markdown report to inline-styled HTML, and sends it through SES. The SES email identity is created by CDK on first deploy and sends a verification email automatically. One schedule, one container, one email.
Storage: DynamoDB for receipts and deals, S3 for receipt PDFs with presigned URLs for secure access from emails.
Infrastructure: Everything defined in CDK (TypeScript) across three stacks. Repeatable, immutable, deploy to any region.

The flow for the weekly scan looks like this:

One thing worth calling out: EventBridge Scheduler's universal target for AgentCore is undocumented as of this writing. I found it by looking at the supported SDK targets and guessing the ARN format. It works, but the scheduler reports the invocation as failed even when it succeeds (the streaming response confuses its success detection). Setting retries to zero prevents duplicate emails. I learned this the hard way.

What It Costs

Here's what the project cost me in us-west-2 over the first two weeks (Feb 1-13), including all development and testing:

Service	Cost	Notes
Amazon Bedrock (Nova 2 Lite)	$0.47	Receipt parsing + price match analysis
Amazon Bedrock AgentCore	$0.23	Container runtime for weekly agent
Amazon DynamoDB	$0.02	Receipts + deals tables
Amazon ECR	$0.01	Docker image storage
API Gateway	$0.00	Free tier
AWS Amplify	$0.00	Free tier
AWS Lambda	$0.00	Free tier
Amazon SES	$0.00	Free tier
Amazon S3	$0.00	Free tier
Total	$0.73

Under a dollar for two weeks of building and testing. In steady state (one weekly scan, a few receipt uploads), expect roughly $0.10-0.20/week. Lambda, SES, DynamoDB, API Gateway, and Amplify all fall within free tier for personal use. Bedrock has no free tier, but Nova 2 Lite is cheap at $0.32 per million input tokens.

What I Learned

Most of this project was written with Kiro CLI, Amazon's AI coding assistant. What would have taken weeks of wiring up CDK stacks, debugging IAM policies, and figuring out EventBridge Scheduler's undocumented universal targets was done in a few hours of back-and-forth. I described what I wanted, Kiro wrote the code, I tested it, we iterated. The entire CDK infrastructure, the agent, the streaming API, the email converter, all of it.

A few things that tripped us up along the way:

Costco receipt abbreviations are wild. "CKN/VEG DUMP" is dumplings. "T TURTLENECK" is a sweater. Nova handles it well, but I added a two-tier system where Nova Premier reparses anything Nova Lite struggles with.
Deduplication matters. Two of the same item should both show up, but each should only match the best deal. Tracking by receipt position solved this.
TPD (Temporary Price Drop) detection was a late addition that turned out to be one of the most useful features. Costco applies these at checkout automatically. The scanner picks them up and shows what you saved without asking.

Deploy It Yourself

Everything deploys through CDK. Three stacks, one command.

Prerequisites

AWS CLI configured with credentials
Node.js 18+ and npm
Docker running (for Lambda and AgentCore container builds)
Python 3.12+
A verified email address in Amazon SES (the region you're deploying to)

Run Locally

You can run the whole thing on your laptop without deploying anything except the DynamoDB tables and S3 bucket (which the Common stack creates).

# Create a virtual environment and install dependencies
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

# Run the app
./run.sh

This starts FastAPI on http://localhost:8000. The web UI at static/index.html works locally without Cognito auth. Just open the HTML file in your browser and point it at localhost. The run.sh script sets the default env vars (region, table names, bucket) so you don't need to configure anything if you deployed the Common stack with defaults.

Deploy

# Clone and install CDK dependencies
cd costco-scanner/infra
npm install

# Deploy everything (Lambda, Amplify, API Gateway, Cognito, DynamoDB, S3)
# notifyEmail: your email address for weekly reports (SES verification sent on first deploy)
cd .. && ./deploy.sh

# Deploy the weekly agent (optional, requires a verified SES email)
cd infra && npx cdk deploy CostcoScannerAgentCore \
  -c region=us-west-2 \
  -c notifyEmail=your-email@example.com \
  --require-approval never

The region context parameter controls where everything goes. The notifyEmail parameter is the email that receives the weekly report from the AgentCore agent. On first deploy, CDK creates an SES identity for that email and sends a verification link. Click it once and the weekly reports start flowing.

After deploy, CDK outputs the Amplify URL, API endpoint, and Cognito pool details. The AgentCore stack also creates an SES email identity for the notifyEmail address, which triggers a verification email. Click the link in that email, and the weekly reports start working. Subsequent deploys won't re-trigger verification. Create a Cognito user through the AWS console or CLI, then log in to the web UI.

Cleanup

# Destroy the AgentCore stack first (it depends on Common)
cd infra && npx cdk destroy CostcoScannerAgentCore -c region=us-west-2 -c notifyEmail=your-email@example.com

# Destroy Amplify + API stack
npx cdk destroy CostcoScannerAmplify -c region=us-west-2

# Destroy shared resources (DynamoDB, S3, ECR) last
npx cdk destroy CostcoScannerCommon -c region=us-west-2

S3 buckets and DynamoDB tables have RemovalPolicy.DESTROY set, so they'll clean up with the stack. ECR repos too. If you want to keep your receipt data, back up the DynamoDB tables before destroying.

Open Source

I'm making this open source. The code is available on GitHub. If you're a Costco member who's tired of leaving money on the table, clone it, deploy it, and start getting your price adjustments.

The CDK stacks mean you can deploy the entire infrastructure to your own AWS account with a single command. Upload your receipts, let the agent do its thing, and walk into Costco knowing exactly what you're owed.

If you're a developer who wants to learn how to build AI agents on AWS, this is a real working example. Not a toy demo. Not a chatbot that tells you the weather. A thing that actually saves you money every week.

What's Next

I'm building a native iOS app using Amplify Library for Swift, so I can snap a photo of my receipt right at the checkout and upload it on the spot. Same Cognito auth, same API, same backend. Just a better experience on the phone.

25 years of Costco membership. Thousands of dollars in missed price adjustments. One AI agent to make sure that never happens again.

The hot dog combo is still $1.50 and the rotisserie chicken is still $7.99. Some things never change.

How AWS Support Saved Me $530 (And Why You Should Check Your Quick Suite Settings Right Now)

Vivek V. — Wed, 11 Feb 2026 03:50:19 +0000

Background

Forgot to turn off a promo feature. Got hit with $530 in charges. AWS Support waived it all. Here's the full story.

The Setup

From October 9, 2025 to January 31, 2026, I was heavily using Amazon Quick Suite Research during its promotional period. Amazon Quick Suite is an Agentic AI Teammate, a PhD-level researcher, a business analyst, and an automation expert in one workspace. The timing was perfect because I was preparing my AWS re:Invent presentation, and having access to custom datasets across AWS integrations made a huge difference with research quality. Being able to run evaluations against my own data helped me fine-tune everything before going on stage.

If you want to see what I was working on:

The Oops Moment

February rolls around. I forgot to turn off Admin Pro after the promotional period ended.

Suddenly there's an extra $500+ charge on my bill. The promotional waiver for the Amazon Q in QuickSight infrastructure fee ($250/month) had ended on January 31, 2026. Plus there were Reader Capacity Pack charges I wasn't expecting.

Here's the thing about Quick Suite pricing that caught me off guard: during the promo period, Admin Pro was only $40/month. But once the promotional period ends, you're also on the hook for the mandatory Amazon Q in QuickSight fee. That's a significant jump (++ $250/month extra with Admin Pro user) if you're not paying attention.

AWS Support Came Through

I reached out to AWS support. Keep in mind I'm on the free Basic support plan. No Business Support+ or Enterprise plan, no dedicated account manager, nothing fancy.

They credited me the full $530:

$500 for the QuickSight capacity reader pack and Amazon Q charges
$30 for additional user charges from January (accidently activated)

I've worked with a lot of cloud providers. Getting charges waived when you're on a free support tier? That's a rare to find customer obsession these days. The fact that I got proactively alerted by AWS Budgets and CloudWatch alarms before the charges even hit my card made the whole conversation easier.

What Triggers the Amazon Q Fee

This is the part I wish I'd understood earlier. The $250/month fee kicks in when your account has ANY of these:

Pro users (Author Pro, Reader Pro, or Admin Pro)
Topics created
Dashboards with Q&A enabled

So even if you're not actively using the generative BI features, having a Pro user sitting there will trigger the charge.

How to Avoid This

If you want to keep Pro but stop the Q fee:

Go to QuickSight Console > Topics and delete any Q Topics
Check your dashboards and disable Q&A on each one
Save the dashboards

But here's the catch: if you keep Admin Pro, you'll still pay the $250/month Q enablement fee. The Q fee is bundled with Pro subscriptions. You can't separate them.

If you want to avoid the Q fee entirely:
Downgrade from Pro to a regular Reader or non-Pro user type. You lose the Pro authoring capabilities but you also lose the $250/month charge.

To cancel Reader Capacity Pack:

QuickSight Console > Profile icon > Manage QuickSight
Left nav > Manage Subscriptions
Find Reader Capacity Pack (500 sessions)
Click "Switch to user pricing"

Changes take effect the following month.

The Billing Pattern That Tripped Me Up

December 2025: No Q fee (promotional waiver active)
January 2026: No Q fee (promotional waiver still active)
February 2026: $67.34 Q fee (prorated, promo ended January 31)

If you enabled Pro users after October 9, 2025 (the Quick Suite launch date), your promotional period also ended January 31, 2026. Check your February bill.

Bottom Line

Amazon Quick Suite is genuinely powerful for AI evaluation and research work. The ability to use custom datasets across AWS integrations helped me prepare for re:Invent in ways I couldn't have done otherwise using either Perplexity Deep research or ChatGPT Deep research mode.

But watch your billing. Set up AWS Budgets alerts. Set up CloudWatch alarms. And if something goes wrong, reach out to support. Even on the Basic plan, they might surprise you.

Full opt-out instructions: https://docs.aws.amazon.com/quicksuite/latest/userguide/generative-bi-opt-out.html

Relevant Documentation

★ Amazon Quick Suite Pricing: https://aws.amazon.com/quicksuite/pricing/

★ Amazon Quick Suite User Types: https://docs.aws.amazon.com/quicksuite/latest/userguide/user-types.html

★ Amazon Quick Suite Editions: https://docs.aws.amazon.com/quicksuite/latest/userguide/editions.html

★ Configure Quick Suite Subscriptions: https://docs.aws.amazon.com/quicksuite/latest/userguide/managing-subscriptions-configure.html

★ Quick Suite User Guide: https://docs.aws.amazon.com/quicksuite/latest/userguide/

Building Roblox Games with Kiro: A Spec-Driven Development Approach

Vivek V. — Sat, 18 Oct 2025 02:26:54 +0000

The Rise of Kiro and the Roblox Opportunity

The developer community embraced Kiro with unprecedented enthusiasm. In just 3 days of its public preview launched on July 14, over 100,000 developers downloaded Kiro. That number has more than doubled in 90 days, showcasing the massive demand for AI-powered development tools with Agentic-IDE that actually understands how developers work.

The best news? There's no more waitlist. Anyone can now download Kiro and get started with 500 free bonus credits—that's equivalent to 50% of the Kiro Pro plan. It's the perfect opportunity to explore how AI can transform your development workflow.

And speaking of opportunities, let's talk about Roblox.

The Roblox Phenomenon

As of mid-2025, Roblox has approximately 111.8 million daily active users and over 85.3 million in recent reports, with users spending billions of hours on the platform annually. The platform boasts over 6.7 million user-created "experiences," and in 2024, developers earned over $701 million from their creations.

The user base is geographically diverse, with a growing older demographic alongside its traditional younger audience. This isn't just a gaming platform—it's a thriving economy where creators can turn their ideas into real income.

But here's the challenge: building a professional-grade Roblox game requires juggling multiple systems, understanding Lua/Luau, managing complex project structures, and following best practices. That's where Kiro's spec-driven development approach changes everything.

What is Spec-Driven Development?

Traditional AI assisted development with Vibe coding often goes like this: you have an idea, you start coding, you realize you forgot something, you refactor, you add features, things get messy, and before you know it, your codebase is a tangled mess.

Spec-driven development flips this on its head. You start with a clear specification—a prompt to generate structured requirements document that defines what you want to build, how it should work, and what the end result should look like. Then, Kiro uses this spec to guide the entire development process, with design and tasks ensuring consistency, completeness, and quality from start to finish powered by its steering, agent hooks and MCP capabilities.

Building an Educational Math Game: A Real Example

Let me show you how I used Kiro to build a complete Roblox educational math game—from concept to deployment—using spec-driven development. I talked about this game briefly in my livestream with Darko on the Kiro bi-weekly show.

The Initial Prompt

Instead of diving straight into code, I started with a clear, structured prompt. Here's the template I used:

Create an <educational math game> for Roblox that <teaches addition through 
engaging gameplay with progressive difficulty>. The project should be built 
using Rojo with Cargo for professional external development workflow, proper 
version control, and organized code structure.

Core Features:
- <Progressive difficulty system that adapts from simple (1-9) to complex 
  (up to 99) addition problems>
- <Multiple game modes: Classic, Blitz, Zen, Survival, Time Attack>
- <Power-up system with 5 power-ups: Time Freeze, Double Points, Skip, 
  Extra Time, Hint Mode>
- <Achievement system with 12+ achievements>
- <Enhanced scoring with speed bonus, streak multipliers, combo system>
- <Visual and audio effects: particle explosions, floating text, dynamic music>
- <Real-time leaderboards>
- <Data persistence for player stats and achievements>

Technical Requirements:
- Use Rojo for external development and live sync with Roblox Studio
- Organize code following Roblox service-based structure
- Implement <game logic, answer validation, data management> on server
- Implement <UI, visual effects, user input handling> on client
- Create SharedModules for <MathUtils, PowerUpManager, EffectsManager, 
  SoundManager, GameModeManager, ComboManager, RewardsManager, MascotManager>

That's it. One clear prompt with placeholders for the specific features I wanted.

What Kiro Generated

From this single prompt, Kiro created:

1. Complete Project Structure

roblox-additive-game/
├── src/
│   ├── ReplicatedStorage/
│   │   ├── GameConfig.lua
│   │   └── SharedModules/
│   │       ├── MathUtils.lua
│   │       ├── PowerUpManager.lua
│   │       ├── EffectsManager.lua
│   │       ├── SoundManager.lua
│   │       ├── GameModeManager.lua
│   │       ├── ComboManager.lua
│   │       ├── RewardsManager.lua
│   │       └── MascotManager.lua
│   ├── ServerScriptService/
│   │   ├── GameManager.server.lua
│   │   └── PlayerDataManager.server.lua
│   ├── StarterGui/GameUI/
│   │   ├── MainMenu.lua
│   │   ├── GameScreen.lua
│   │   ├── GameModeSelector.lua
│   │   ├── PowerUpShop.lua
│   │   └── DailyRewardsUI.lua
│   └── StarterPlayerScripts/
│       └── ClientController.client.lua
├── build/
│   └── additive-game.rbxl
├── default.project.json
└── README.md

2. Fully Functional Game Systems

All 5 game modes working with unique mechanics
Complete power-up system with purchase and activation logic
12 achievements with progress tracking
Real-time scoring with multipliers and combos
Visual effects using particle systems
Dynamic audio system
Data persistence using Roblox DataStores

3. Professional Development Setup

Rojo configuration for external development
Live sync capability with rojo serve
Build pipeline with rojo build
Proper separation of client and server code
Security-focused with server-side validation

4. Comprehensive Documentation

README with setup instructions
Steering documents for best practices
Code comments explaining complex logic
Deployment guide

The Kiro Advantage: Steering Documents

One of Kiro's most powerful features is steering documents. These are markdown files that automatically guide Kiro's code generation based on context.

For this project, Kiro created:

tech.md - Technology stack and build system guidelines

- Platform: Roblox Studio & Roblox Engine
- Language: Lua/Luau
- Build System: Rojo
- Common commands and architecture patterns

structure.md - Project organization rules

- Root directory layout
- Source code organization by Roblox services
- Naming conventions
- Module organization patterns

product.md - Product overview and features

- Core features and value propositions
- Target audience
- Key game mechanics

lua-best-practices.md - Lua/Luau coding standards

- Naming conventions
- Performance best practices
- Roblox-specific patterns
- Error handling
- Security considerations

These steering documents ensure that every piece of code Kiro generates follows the same standards, uses the same patterns, and maintains consistency throughout the project.

The Development Experience

Traditional Approach

Set up Roblox Studio project
Figure out Rojo configuration
Create folder structure manually
Write GameConfig.lua
Implement MathUtils module
Build game logic
Create UI components
Add visual effects
Implement data persistence
Debug and refactor
Write documentation

Time estimate: 2-3 weeks for an experienced developer

Kiro Spec-Driven Approach

Write clear prompt with specifications
Review generated code structure
Test in Roblox Studio
Iterate on specific features if needed

Time estimate: 2-3 hours

Key Takeaways

1. Start with Clarity

The better your initial prompt, the better the output. Use the template structure with clear placeholders for your specific features.

2. Leverage Steering Documents

Let Kiro create steering documents that guide all future development. This ensures consistency even as you iterate.

3. Use Professional Tools

Rojo + Kiro is a powerful combination. External development with version control beats working directly in Roblox Studio.

4. Focus on What Matters

Instead of writing boilerplate and setting up infrastructure, spend your time on game design, balancing, and player experience.

5. Iterate Quickly

With Kiro, you can test ideas rapidly. Don't like a game mode? Adjust the spec and regenerate. Want to add a new power-up? Update the prompt and let Kiro handle the implementation.

The Results

The final game includes:

✅ 5 fully functional game modes
✅ 5 power-ups with purchase system
✅ 12 achievements with tracking
✅ Real-time leaderboards
✅ Particle effects and animations
✅ Dynamic audio system
✅ Data persistence
✅ Professional UI
✅ Comprehensive documentation
✅ Production-ready code

All from a single well-structured prompt.

Play the game on Roblox →

Getting Started with Kiro for Roblox Development

Ready to build your own Roblox game with Kiro? Here's how to get started:

1. Download Kiro

Visit kiro.dev and download the IDE. No waitlist, and you get 500 free credits to start.

2. Install Prerequisites

# Install Rust and Cargo
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

# Install Rojo
cargo install rojo

3. Install Roblox Studio

Download from roblox.com/create and install the Rojo plugin.

4. Use the Template

Copy the prompt template from this article, fill in your game idea, and let Kiro do the heavy lifting.

5. Iterate and Deploy

Test in Studio, iterate on features, and publish to Roblox when ready.

The Future of Game Development

With 111.8 million daily active users and $701 million paid to developers in 2024, Roblox represents a massive opportunity. But the barrier to entry has always been the technical complexity.

Kiro's spec-driven development approach democratizes game creation. You don't need to be an expert in Lua, understand Roblox's service architecture, or know how to set up Rojo. You just need a clear idea and the ability to describe what you want to build.

The 100,000+ developers who joined Kiro in the first 3 days understood this. They saw that AI-powered development isn't about replacing developers—it's about amplifying their creativity and removing the tedious parts of coding.

Your Turn

The template is ready. The tools are available. The platform has 111.8 million daily users waiting to play your game.

What will you build?

Resources:

Download Kiro - Get 500 free credits
Rojo Documentation
Roblox Creator Hub
Example Project - Full source code

Have you built something with Kiro? Share your experience in the comments below!

Taming Large Codebases with Kiro: Lessons from a 58K-LoC Rust Migration

Vivek V. — Tue, 23 Sep 2025 19:25:47 +0000

The Scale Problem

AI assistants excel at small tasks but struggle with large codebase management. In the vibe mode, I asked Kiro to pick the largest open-source repo for testing Rust migration and Kiro shortlisted PostgreSQL repo containing 1.5M lines of C code. One advantage using Claude Sonnet 4 with Kiro was that the LLM's training data mostly included the PostgreSQL open-source repo, so it understood the codebase structure to some extent.

MCP Tool Selection: Disabled 15+ tools, kept only:

sequential-thinking - Complex problem breakdown
git-repo-research - Easy access to source repo analysis
aws-knowledge-mcp-server - AWS Documentation access
aws-api-mcp-server - AWS Cloud integration Although the 2 AWS MCP Servers could be disabled for this project, I keep them for other tasks, as they are my favourite ones.

Anthropic's official sequential-thinking MCP server helped break down complex PostgreSQL migration specs into manageable steps through dynamic and reflective problem-solving. It enables iterative thought refinement, allowing revision of
previous reasoning and branching into alternative approaches, which helped Kiro systematically work through dependencies and edge cases with adaptive thinking rather than linear progression.

AWS Labs git-repo-research - The search_repos_on_github and access_file tools provided access to postgres repository and codebase, enabling discovery and analysis design patterns and implementation strategies.

After multiple iterations of specs and using my 3 Kiro accounts (kiro hackathon google account, AWS Builder ID account and AWS IAM Identity Center account), I got a working postgres server and a psql client built in Rust with core UPSERT functionality. Here are the generated code stats: 58,478 lines Rust code, 167 files, 264 total files.

Top 3 Steering Guides Used with Spec-driven development approach:

• Visibility: Making failing tests visible to Kiro
• Organization: Preventing LLM codebase chaos
• Efficiency: Avoiding duplication and waste

Guide 1: Visibility - "If Kiro Can't See It, It Didn't Happen"

# Critical for shell integration issues
cargo test 2>&1 | tee compilation_errors.log
cargo build --workspace 2>&1 | tee build_errors.log
cargo clippy --workspace 2>&1 | tee lint_errors.log

Problem: Shell integration failures caused Kiro to assume command success when tests actually fail.

Technical Solution:
• 2>&1 redirects stderr to stdout
• tee writes to both file and terminal
• Always clean up: rm *.log after verification

Real Impact: Prevented LLM loops debugging phantom "passing" tests that were actually compilation failures.

Side Benefit: As a pro tip, when my Kiro free tier limits were running out of one account, and the tests were actually reporting success due to my shell integration issue, I used the Q Developer Extension in Kiro IDE itself to fix the failing tests and saved on my Kiro credits usage. I also upgraded my AWS Builder ID account to a Kiro pro account and later also got benefit of free August credits, and also the extra limits that were reset for everyone in August/September months.

Guide 2: Organization - "Every File Has a Home"

postgres-rust-migration/
├── docs/{spec-name}/                    # Implementation summaries
│   └── insert-storage-persistence_8_summary.md
├── scripts/verification/{spec-name}/    # Verification scripts
│   └── database-durability_verification.rs
├── crates/{crate}/tests/temp/          # Temporary test files
│   └── temp_sql-update_integration_test.rs
└── target/                             # Build artifacts gitignored

Critical Rules:
• Never create files in project root - causes workspace pollution
• Spec-name prefixes for all artifacts: {spec-name}{task-number}{type}
• Immediate cleanup of temp files and logs
• Use tempfile crate for truly temporary files

Guide 3: Efficiency - "Search Before You Code"

# Before implementing any function
rg "fn.*storage.*persist" --type rust
rg "struct.*Buffer" --type rust  
rg "impl.*Transaction" --type rust

Code Duplication Prevention:
• Search entire codebase before implementing
• Check similar filenames: find . -name "storage" -name "*.rs"
• Verify existing functionality in related crates

Rust-Specific Rules:

# Always use cargo, never rustc directly
cargo build --workspace    # ✓ Handles dependencies
rustc src/main.rs          # ✗ Fails in multi-crate workspace

# Testing workflow
cargo test --workspace                    # All tests
cargo test --package postgres-storage     # Specific crate
cargo run --example verification_script   # Examples

Repository Hygiene:
.gitignore

/target/
*.log
.env
*_temp*
*_backup*

Agent Hooks: Automation

Tokei Integration (auto-updates README):

# Post-task hook
tokei --output json

Instructions for Kiro agent: A task completion document has been updated. Please run tokei . --output json to get the current lines of code statistics, then update the README.md file with the latest code metrics. Include total lines of code, lines by language (especially Rust), and any other relevant statistics from the tokei output. Make sure to update any existing code statistics section or add a new one if it doesn't exist.

Other Kiro Tips

If you move the Kiro project directory, and restart Kiro from different location, then you loose the chat and spec sessions history, so its always recommended to save the session history using task summary as mentioned in the steering rule above
Always ask Kiro to run cargo commands from workspace root to avoid duplicate target directories, e.g.

cd $HOME/project && cargo build

Have Kiro run tests with the lowest verbosity and to filter with grep if necessary to avoid context filling up quickly due to large outputs
When Kiro runs an AWS CLI command, have it include --no-cli-pager. This prevents interactive pager output that the agent can't see or exit from. Other similar commands that generate huge outputs quickly fill the session context, so use similar technique to skip this output in the response if it is not useful for the agent.
When multiple approaches exist for tasks like publishing to Amplify, ask Kiro to create standardized script and instruct to always use that script rather than improvising different methods each time.

Testing the Postgres-Rust

# Start the postgres server
./target/release/postgres-server --config postgresql.conf > server.log 2>&1 &

# 1. Create table
./target/release/psql -c "CREATE TABLE kiro (id INTEGER, name TEXT, age INTEGER, email TEXT);"

# 2. Insert records
./target/release/psql -c "INSERT INTO kiro (id, name, age, email) VALUES (1, 'Alice Johnson', 28, 'alice@example.com');"
./target/release/psql -c "INSERT INTO kiro (id, name, age, email) VALUES (2, 'Bob Smith', 35, 'bob@example.com');"

# 3. Select to verify
./target/release/psql -c "SELECT * FROM kiro;"

# 4. Update Alice's record
./target/release/psql -c "UPDATE kiro SET age = 29, email = 'alice.updated@example.com' WHERE id = 1;"

# 5. Select to verify update
./target/release/psql -c "SELECT * FROM kiro;"

Postgres client psql with update statements work!

Restarting Postgres server to verify persistent updates

Check out my postgres-rust-migration repository for the complete implementation with 58K+ lines of Rust code across modular crates.

Watch the livestream recording | Kiro bi-weekly show | An engineer's take on Kiro

Results: Measurable Impact (AI - calculated numbers)

• Project size: Reduced repo size by excluding targets
• Build time: 15% faster with proper workspace structure
• Debug efficiency: 80% reduction in false-positive "passing" tests
• Code reuse: 23% of functions found existing implementations before coding

RAG-based Presentation Generator built with Kiro

Vivek V. — Mon, 15 Sep 2025 18:25:58 +0000

How a presentation emergency inspired a new approach to AI-powered development

The Crisis That Started Everything

Picture this: 15 minutes before a major presentation, your file is corrupted. Hundreds of developers are waiting. Most would panic.

However, Donnie Prakoso, Principal Developer Advocate at AWS, turned to Amazon Q CLI. His methodical approach - requirements, task-based workflows, MCP tools - saved the day. But his key insight changed everything: "It's not about the AI tool itself, but how you integrate it into your workflow."

This real life scenario inspired me with the idea to build a full self-service serverless AI app, a Retrieval-Augmented Generation (RAG) - based Presentation Generator by using Kiro and leveraging these key capabilities:

Serverless AWS architecture with Bedrock Models
Real-time document processing with Bedrock Knowledge Base
Per-user data isolation for enterprise security
S3 Vectors integration (no Amazon OpenSearch Serverless) for cost-optimized storage
React frontend with modern Amplify v6 authentication
CDK infrastructure scaling from prototype to production

The Kiro Transformation

Remembering the workflow-first approach, I opened Kiro: "Help me build an AI-based Presentation Generator system with above key capabilities that can help with edit slides, geneate content, export the presentation to Marp, Reveal.js or HTML formats"

What happened next was unlike any coding experience I'd had.

Kiro didn't give generic answers. It broke down complexity into manageable tasks, analyzed my specific architecture needs with an accurate design, and hooked me to spec-driven development.

The Spec-Driven Revolution

Instead of one massive requirements document, over the development cycle, I created 5 different modular specs:

AWS-Native RAG spec: Core system with Bedrock and S3 Vectors
System Fixes spec: Surgical improvements without breaking production
UI Enhancement spec: Professional interface without backend risk
Blog Platform spec: Content creation system (generating this post)
Security Vulnerability Assessment specs: Full assessment of the system for any vulnerabilities to make sure the app is secure and production ready

Each spec operated independently. I could iterate fearlessly on complex use-cases separately and one-after-other.

Building Production AI: The Technical Journey

The S3 Vectors Breakthrough

When I mentioned vector storage costs, Kiro's MCP integration with my configured awslabs aws-knowledge-mcp-server immediately suggested S3 Vectors - a preview service yet fully searchable with the MCP server containing access to all examples and ready to use code from AWS blog posts and official AWS documentation:

"S3 Vectors can reduce costs by 90% compared to OpenSearch Serverless."

The implementation was game-changing. For instance, this single line saved hours of debugging.

s3vectors.create_index(
    vectorBucketName=bucket_name,
    indexName=index_name,
    dimension=1024,
    distanceMetric="cosine",
    dataType="float32",
    metadataConfiguration={
        "nonFilterableMetadataKeys": ["AMAZON_BEDROCK_TEXT"]  # CRITICAL
    }
)

The result: 90% cost reduction while maintaining full functionality.

I asked Kiro about CDK's current lack of native support for S3 Vectors (which would require implementing a Custom Lambda Resource), and we ended up with the optimal architectural decision to handle vector index creation programmatically at runtime using the boto3 SDK during document ingestion, ensuring future compatibility and per-user isolation.

Kiro's test-driven development approach was revolutionary - it iterates on generated tests until they pass and the code achieves full functionality. By structuring specifications in repeatable, "declarative format", Kiro essentially functions as a specifications "compiler", transforming human-readable requirements directly into working code. This paradigm shift turns Kiro into an intelligent coding agent that bridges the gap between architectural intent and executable implementation, making spec-to-code transformation as reliable as traditional compilation processes.

System Architecture

Per-User Architecture Innovation

Kiro proposed something I hadn't considered - per-user Knowledge Bases:

Traditional: Shared KB → Complex filtering → Performance issues
Innovation: User A → KB A, User B → KB B → Perfect isolation

This architecture eliminated:

Complex metadata filtering
S3 Vectors 2KB metadata limits
Cross-user data contamination
Query performance bottlenecks

Complete CDK Infrastructure Generation

Instead of generic boilerplate, Kiro generated production-ready infrastructure:

// Generated by Kiro - Complete serverless stack
const knowledgeBaseRole = new iam.Role(this, 'KnowledgeBaseRole', {
  assumedBy: new iam.ServicePrincipal('bedrock.amazonaws.com'),
  inlinePolicies: {
    S3VectorsPolicy: new iam.PolicyDocument({
      statements: [
        new iam.PolicyStatement({
          actions: [
            's3vectors:CreateVectorBucket',
            's3vectors:GetIndex',  // Often missed, critical for debugging
            's3vectors:QueryVectors'
          ],
          resources: ['*'],
        }),
      ],
    }),
  },
});

The code (thanks to the awslabs mcp server) included the often-missed s3vectors:GetIndex permission that would have taken hours to debug.

Sophisticated Lambda Functions

Kiro generated complete backend Lambda Function code with proper error handling:

class BedrockRAGService:
    def search_similar_content(self, query: str, user_id: str, top_k: int = 5):
        try:
            user_kb_info = self._get_user_kb_info(user_id)
            if not user_kb_info:
                raise ValueError(f"No Knowledge Base found for user {user_id}")

            response = self.bedrock_agent_runtime.retrieve(
                knowledgeBaseId=user_kb_info['knowledge_base_id'],
                retrievalQuery={'text': query},
                retrievalConfiguration={
                    'vectorSearchConfiguration': {'numberOfResults': top_k}
                }
            )

            return self._format_search_results(response)

        except Exception as e:
            logger.error(f"RAG search failed: {str(e)}")
            return {'error': 'Search temporarily unavailable'}

The code included timeout handling, user-specific routing, and graceful error recovery - patterns that would have taken days to implement properly.

The Production Architecture

The application runs on:

Frontend: Next.js 15.4.5 + React 19.1.0, AWS Amplify v6, Webpack 5 (~170 KiB bundle)

Backend: Python 3.11 Lambda functions with Bedrock Knowledge Base integration

AI Services: Amazon Nova Pro + Titan embeddings, S3 Vectors storage

Data Layer: DynamoDB + S3 with per-user isolation

Cost Optimization: 90% reduction in vector storage costs vs traditional approaches

The Velocity Impact

Traditional Approach (Estimated):

Feature planning: 2-3 weeks
Cross-system coordination: 1-2 weeks
Implementation with risk mitigation: 4-6 weeks
Testing and validation: 2-3 weeks
Total: 9-14 weeks per feature

Spec-Driven Approach (Actual):

Focused spec creation: 2-3 days
Independent implementation: 1-2 days
Isolated testing: 3-5 days
Total: 1-2 weeks

Beyond Code Generation

Kiro understood broader context:

User Experience: Suggested async processing to avoid wait times
Cost Optimization: Recommended S3 Vectors for 90% savings
Security: Implemented per-user isolation without being asked
Scalability: Designed for 100 users per AWS account with clear scaling paths

The Automation Revolution

Kiro helped create agent hooks that eliminated entire bug categories:

CDK Synth Hook: Automatically validates infrastructure changes
README Spell Check: Maintains documentation quality
Test Automation: Runs comprehensive validation on every change

These hooks transformed development from reactive debugging to proactive quality assurance.

I heavily used my Kiro steering files that helped to maintain best practices all throughout the development cycle. Occasionally, I asked Kiro to automatically refine my steering files with the codebase, so it does not go off-track whenever implementing a new spec (I had total 5 specs for this project)

The Compound Effect

Spec-driven development changed how I approach complex systems:

Before: "How can I add this feature without breaking anything?"
After: "What focused spec addresses this specific concern?"

Before: "This change might affect multiple systems."
After: "This spec targets exactly one area."

The spec-driven development eliminated the fear of changing complex production systems.

Real-World Results

Milestone 1: AWS-Native RAG spec → Production deployment with S3 Vectors
Milestone 2: System Fixes spec → Critical issues resolved without disruption
Milestone 3: UI Enhancement spec → Professional interface without backend changes
Milestone 4: Blog Platform spec → Content creation system for sharing this story
Milestone 5: Security Assessment spec → Full vulnerability assessment of the system

Each spec operated independently, allowing rapid iteration without fear of breaking existing functionality.

The Future of AI Development

This approach scales beyond the RAG-based Presentation Generator:

Enterprise Applications: Core business logic, UI enhancement, performance optimization as separate specs

Microservices: Service foundation, API enhancement, monitoring as isolated concerns

AI Systems: Model integration, data processing, user interface as modular specifications

Key Takeaways

Workflow-first thinking beats tool-first approaches
Spec-driven development enables fearless iteration on complex systems
AI assistants excel at architectural guidance within structured processes
Modular specs prevent technical debt accumulation
Per-user architectures solve isolation and scaling challenges elegantly

Try It Yourself

The complete code is available at github.com/awsdataarchitect/ai-ppt-generator with detailed instructions for reproducing this spec-driven development approach.

The live AI PPT Generator showcases these techniques in production: https://main.d2ashs0ytllqag.amplifyapp.com

Experience how workflow-first AI development transforms complex AWS projects from chaotic research cycles into predictable, scalable methodologies.

The future of software development isn't about AI replacing developers - it's about integrating AI into workflows that amplify human creativity and eliminate the fear of building complex systems.

Building an AI Dining Assistant in 30 Minutes: From Local Development to Cloud Deployment

Vivek V. — Fri, 05 Sep 2025 19:27:42 +0000

How I built a restaurant discovery and dining plan generator AI Agent using Amazon Bedrock AgentCore, and why it's easier than you think.

The Idea: AI Agent for Dining

You've just landed in Seattle for a business trip. It's 7 PM, you're hungry, and you have no idea where to eat. You want something authentic, not touristy, with good reviews, and ideally within walking distance of your hotel.

That's when I decided to build my own AI dining assistant that could not only find restaurants but create complete dining plans with recommendations, party size considerations, and local insights.

What I Built: The Bedrock AgentCore Dining Agent

The agent I created does three things exceptionally well:

Smart Restaurant Discovery: Uses real-time web search to find restaurants based on location, cuisine, or specific requirements
Intelligent Menu Analysis: Automatically scrapes restaurant websites to understand their offerings
Personalized Dining Plans: Creates detailed recommendations including party size, budget estimates, and local tips/taxes

But here's the kicker - it took me less than 30 minutes to build and deploy, thanks to Kiro for building the frontend code in React and the backend AgentCore agent using Strands Agent framework (app.py) and deploying it on the Amazon Bedrock AgentCore Runtime.

The Magic Behind the Scenes

Real Data, Real Results

Unlike other AI assistants that give you generic responses, and incomplete web searches, my agent uses BrightData's MCP integration to perform actual web searches and scrape real restaurant data. When you ask for "Italian restaurants in Seattle" you get current, accurate results with real ratings, addresses, and phone numbers.

Five AI Models, One Interface

The agent supports five different Bedrock models:

Nova Premier (my go-to for complex queries)
Nova Micro (lightning-fast for simple searches)
Claude Sonnet 4 (excellent for creative dining plans)
Claude Opus 4.1 (the most sophisticated reasoning)
GPT-OSS 120B (OpenAI's GPT open-weight Model that works really well with Bedrock and runs fast)

I can switch between models dynamically based on my preference - fast results or deep analysis.

Note: You might need to enable Bedrock model access for Amazon Nova and Anthropic Claude models. The OpenAI's GPT-OSS models are enabled automatically in Bedrock, eliminating the friction between dev teams, however, these GPT-OSS Bedrock model are only available in the us-west-2 (Oregon) region at the time of publishing this blog.

Intelligent Tool Routing

The agent automatically decides which tools to use based on your request:

"Find restaurants" → Triggers web search
"Dining plan at Wild Ginger for 2" → Searches for the Wild Ginger restaurant, finds their website, scrapes the menu, and creates a personalized plan
"Best sushi in Seattle" → Combines search with local insights

The Development Journey: Surprisingly Simple

Step 1: The Foundation (5 minutes)

I started with Amazon Bedrock AgentCore and the Strands Agent framework. The setup was straightforward:

from strands import Agent
from strands.models import BedrockModel

agent = Agent(
    model=BedrockModel("us.amazon.nova-premier-v1:0"),
    tools=[search_engine, scrape_as_markdown, create_dining_plan]
)

Step 2: MCP Integration (10 minutes)

The real power came from integrating BrightData's MCP (Model Context Protocol) server. This gave my agent access to:

CAPTCHA-protected Google search
Professional web scraping capabilities
Real-time data extraction

 api_token = os.getenv('BRIGHTDATA_API_TOKEN')
        if not api_token:
            raise ValueError("BRIGHTDATA_API_TOKEN environment variable not set")

        mcp_url = f"https://mcp.brightdata.com/sse?token={api_token}"

        async with sse_client(mcp_url) as (read_stream, write_stream):
            async with ClientSession(read_stream, write_stream) as session:
                await session.initialize()

                result = await session.call_tool(tool_name, arguments)
                return str(result.content[0].text) if result.content else "No result"

No more mock data or limited APIs - this agent works with the real web.

Step 3: React Frontend (15 minutes)

I built a clean React frontend with Kiro prompts:

Model selection dropdown
Local vs cloud endpoint switching
Real-time response streaming
Mobile-responsive design

The entire frontend took just 15 minutes because I focused on functionality over fancy animations.

Important Note: As a best practice, I recommend to use a separate frontend layer for the agent, and keep the Agent Business Logic separate in AgentCore, although you can still use AgentCore local itself as an UI option without needing a separate frontend layer. So in essence, you can use any of these options to host your frontend - a localhost frontend or cloud hosted single page app (S3, CloudFront, Amplify), Lambda, ECS, EKS, or AgentCore.
For my frontend, I used the React based localhost UI for this quick demo.

For my backend, I provided an option in UI (screenshot in next section) for switching between a local AgentCore backend and the AWS Cloud AgentCore Runtime backend just to demo both possibilities for a AgentCore backend.

Real-World Testing: The "Toronto Test"

To test the agent, I asked it: "I'm visiting Toronto with 3 friends. Create a dining plan at Canoe in downtown core"

Here's what happened:

Search Phase: The agent found Canoe restaurant in Toronto
Menu Discovery: Found Canoe's website and scraped their current menu
Plan Creation: Generated a complete dining plan including:
- Recommended dishes for sharing
- Wine pairings
- Budget estimate (~$322 CAD for 4 people)
- Reservation tips

Total response time: 50 seconds. Quality: Better than a human concierge or other AI conversation agent.

Deployment: From Local to Cloud in One Command

Local Development (for frontend in React and backend dining agent in AgentCore local)

Running locally is very simple:

python app.py &
cd frontend && npm start &

Two commands, and you have a full-stack AI dining assistant running on your laptop.

Cloud Deployment (for backend dining agent in AgentCore Runtime)

Here's where AgentCore really shines. Deploying backend to AWS AgentCore Runtime took literally one command:

agentcore launch

That's it. No Docker files, no Kubernetes manifests, no infrastructure headaches. Following simple prompts with agentcore CLI, AgentCore handled:

Container building via CodeBuild
ECR repository creation
IAM role configuration
Runtime deployment
Auto-scaling setup

To test the deployed Cloud AgentCore runtime with my local frontend:

python cloud_proxy.py &

This starts a proxy server on port 8081 that connects my local frontend to the deployed AgentCore runtime, enabling seamless local-to-cloud testing.

In 15 minutes, I had a production-ready AI agent running in the cloud with enterprise-grade reliability.

Screenshot of Agent sandbox in AgentCore Console to test the AgentCore Runtime Hosted Endpoint:

The Secret Sauce: Environment Variables Done Right

One critical lesson I learned: AgentCore has two configuration layers. The YAML file handles deployment settings, but runtime environment variables (like an API token) require a separate step:

aws bedrock-agentcore-control update-agent-runtime \
  --agent-runtime-id YOUR_AGENT_ID \
  --environment-variables 'BRIGHTDATA_API_TOKEN=your_token'

This separation ensures security and flexibility in production environments.

Agent Beyond Just Restaurants

While I built this for restaurant discovery, the architecture demonstrates something bigger. This is how AI agents should work:

Real data integration with MCP Tools (not hallucinated responses)
Multiple model support (choose the right tool for the job)
Seamless deployment (from laptop to cloud in minutes)
Production-ready security (proper environment variable handling)

The same pattern works for travel planning, event coordination, research assistance, or any domain where you need AI to interact with real-world data.

Why Bedrock AgentCore Wins

Traditional Approach:

2-3 days for infrastructure setup
Multiple services to manage (API Gateway, Lambda, ECS, etc.)
Complex deployment and orchestration pipelines
Ongoing maintenance overhead

AgentCore Agentic AI Approach:

30 minutes total development time
One command deployment
Zero infrastructure management
Built-in scaling and monitoring

The productivity difference is the key.

Try It Yourself

The complete code is available, and you can have your own dining agent running in minutes:

Clone the repository https://github.com/awsdataarchitect/bedrock-dining-agent
Add your BrightData API token (free tier available, I used promo code devto1 for $250 credits) https://brightdata.com
Run locally: python app.py & && cd frontend && npm start &
Deploy to cloud: agentcore launch

That's it. You now have a production-ready AI dining assistant.

What's Next?

This project opened my eyes to the potential of Bedrock AgentCore for rapid Agentic AI application development with seamless integration of ANY model supported by Bedrock (e.g. Claude, Nova, GPT-OSS) and ANY Agent framework (I used Strands Agents SDK), real-time data access through MCP tools, and effortless cloud deployment capabilities.

Next, I'm planning to enhance this agent with new features by using Kiro:
Reservation Agent: Automated table booking through Amazon Connect integration that calls restaurants directly to secure reservations based on your preferred time and group size.
AgentCore Memory: Enabling long term/short term memory that can remember past interactions and use them to create a personalized dining plan for the next time.

The pattern is the same: real data integration + multiple AI models + one-command deployment = powerful applications in minutes, not months.

Conclusion

Building sophisticated AI agents used to require teams of engineers and months of development. With Amazon Bedrock AgentCore, I built and deployed a production-ready dining assistant in 30 minutes.

Ready to build your own AI agent? The dining assistant is just the beginning.

Try the Bedrock Dining Agent: https://github.com/awsdataarchitect/bedrock-dining-agent
Deploy in 30 minutes: Follow the README quick start guide

Questions? Reach out - I'd love to see what you build next. As Werner says, now go build!

DEV Community: Vivek V.

I Crashed My Mac 5 Times So You Don't Have To: Mounting S3 Files on macOS

Why This Matters

The Problem: macOS Can't Speak S3 Files

Attempt 1: Native macOS NFS Mount → 💀 Kernel Panic (x5)

Attempt 2: Raw mount -t nfs4 via NLB → ❌ "access denied"

Attempt 3: efs-proxy Without TLS → ❌ "access denied"

Attempt 4: The IPv6 Detour → ✅ First Success (But Wrong Conclusion)

Attempt 5: efs-proxy ReadBypass → ❌ Proxy Crash Loop

Attempt 6: The Full Stack → ✅ It Works

The Benchmark: WebDAV Destroys SMB on macOS

Region Matters: ca-central-1 vs us-east-2

The Architecture

The Developer Experience: Two Commands

The Backstory: Mountpoint for S3 and the iPhone Backup That Almost Worked

What's Next: Use Cases I'm Excited About

A Note on WSL2

S3 Files vs. Mountpoint for Amazon S3

Security: What's Safe and What's Not

The Failure Table

Try It Yourself

The AWS Dev Setup Nobody Told You About. Claude Code, Kiro Pro, and Agent Plugins.

Agent Plugins for AWS

The Setup

Step 1: Install Claude Code

Step 2: Clone and set up kiro-gateway

Step 3: Configure kiro-gateway

Step 4: Start kiro-gateway

Step 5: Point Claude Code at it

Step 6: Run Claude Code

Step 7. Install Agent Plugins

What each plugin does

Trying it out. Cost estimation

Trying it out. Full plugin-driven deployment

Troubleshooting kiro-gateway:

1. Long tool names trigger a 400 error

2. aws-iac-mcp fails to build on Apple Silicon

Usage (again after fix)

Cost

Credits

I Built a Real-Time Voice AI Confession Guide for 1.39 Billion Catholics. Every Bug Was Invisible.

The Gap

The Architecture

The Bug That Almost Shipped

Two More Invisible Bugs

The Cognito Session Policy Trap

Frugal Architecture: 60 Concurrent Sessions, Zero Quota Increases

Nova 2 Sonic Configuration That Matters

Echo Cancellation: Still an Active Problem

The Economics

What's Next: AgentCore WebRTC

What I'd Do Differently

The Point

I Turned Notion Into a Control Plane for my 18 OpenClaw AI Agents

What I Built

The Agent Migration Problem

Video Demo

The Code

awsdataarchitect / agentops

Notion-powered control plane for OpenClaw AI agents — monitor, dispatch, tune, backup, and clone your agent fleet

🤖 AgentOps — Notion-Powered Control Plane for OpenClaw Agent Fleets

📸 Screenshots

Dashboard

Agent Registry

Task Queue

How I Used Notion MCP

Why This Matters

AgentBoard: A Discovery Platform for the Agentic AI Community

The Community

What I Built

Demo

Code

natearcher-ai / agentboard

AgentBoard — Community-driven AI agent discovery platform. Browse, share, and celebrate AI agents built by the community.

AgentBoard 🤖

What is AgentBoard?

Screenshots

Home

Discover

Submit

Attempt 2: Raw `mount -t nfs4` via NLB → ❌ "access denied"