DEV Community: AWS

How I built MCP Apps based Sales Analytics Agentic UI & deployed it on Amazon Bedrock AgentCore

Ashita Prasad — Wed, 01 Apr 2026 05:38:59 +0000

TL;DR: Learn how to add interactive forms, charts, visualization & PDF viewer - natively in your AI Agent chat window using MCP Apps.

AI Agents are getting smarter with each passing day. But, their interfaces? Not so much. But, what if there is a way to turn the AI chat from a place where you converse into a place where you can actually work?

That's where MCP Apps, an extension of Model Context Protocol, comes to our rescue.

In my previous article, we explored the foundational building blocks of MCP Apps in detail and witnessed how it provides a way to deliver rich, bidirectional UIs. Through a series of minimal examples, we covered various concepts such as the handshake protocol and host-aware theming, to CSP policies and calling tools from within an iframe.

Now, it's time to stitch those pieces together into something real.

In this article, we'll walk through a complete, production-style MCP Apps chatflow (chat + workflow) and build an interactive sales analytics UI where a user can select sales region, pick a metric like revenue or conversion rate, fetch live data, visualize it with charts, and create & download a PDF report - all without ever leaving the AI Agent chat window. We will also learn how to deploy the developed TypeScript MCP server powering our sales analytics MCP Apps on Amazon Bedrock AgentCore Runtime.

You can find the entire source code of this article in the Github repo link provided below 👇

ashitaprasad / sample-mcp-apps-chatflow

Sample MCP Apps Chatflow

Sample MCP server that renders interactive sales analytics UIs inside an MCP Apps-compatible chat client. It includes a sales metric selector, chart-based visualization, and PDF report generation.

Articles

This project is part of the MCP Apps article series published on dev.to:

Part 1: How I render interactive UI in my AI Agent chatflows using MCP Apps - Covers the core architectural patterns for declaring UI resources, practical design principles, and how to handle sandboxed host–server communication.
Part 2: How I built MCP Apps based Sales Analytics Agentic UI & deployed it on Amazon Bedrock AgentCore - Walks through a complete, production-style MCP Apps chatflow (chat + workflow) and build an interactive sales analytics UI where a user can select sales region, pick a metric like revenue or conversion rate, fetch live data, visualize it with charts, and create & download a PDF report - all without…

View on GitHub

The Problem: When chat isn't enough!

It all started when my friend, who is a sales analyst, started exploring AI Agents after reading everywhere that agents can unlock productivity by automating workflows and are also capable of performing data analysis.

He prepared sales analytics reports on a monthly and quarterly basis and felt AI Agents could accelerate this workflow greatly. He started his Agentic journey by uploading CSVs, interacting with the AI Agent & assigning it tasks. The agent would frequently ask him clarifying questions, like the required sales metrics, sales regions he was interested in and more follow-up questions. Often, the AI agent would assume certain parameters and produce random results which meant he had to start the entire workflow all over again.

Although the resulting analysis was accurate, but from the presentation standpoint a simple markdown result was quite underwhelming. After discussing his entire Agentic Experience (AX), I realised that the core friction was due to the limitations of plain chat. While my friend kept answering and re-prompting, the model kept guessing and re-analyzing. The experience never quite graduated from "assistant response" to an actual "working interface".

And, MCP Apps solved exactly this gap!

Instead of returning only text, the server returns a rich, interactive HTML interface rendered directly inside the chat which lets the user drive the experience like an application, not just an answer.

Let's see how.

The Solution: A Chatflow powered by MCP Apps

An end-to-end demo of the complete chatflow is shown below:

Our chatflow involves three MCP Apps (UI resources) orchestrated by four tools. Each MCP App is a self-contained HTML page served by the MCP server, running in a sandboxed iframe, communicating with the host via postMessage JSON-RPC.

The new Agentic experience (AX) unfolds like a real workflow:

User asks for sales insights.
AI agent opens a Sales Metric Selector MCP App which allows user to easily select the sales metric, reporting period, reporting year & sales regions, instead of forcing the user to specify everything in text.
On clicking Submit, the app fetches data through an internal MCP tool and adds it as a structured JSON data in the context.
With the relevant data added in context, user can prompt to generate a visualization or prepare a PDF report.
Upon requesting for a visualization, the Sales Visualization MCP App is rendered which presents the entire data in an insightful & interactive visualization dashboard.
Upon requesting for a PDF report, the AI agent triggers a tool which creates a PDF report server side, and then displays it via a PDF Report Viewer MCP App. The MCP app displays the pdf in the form of an interactive PDF and allows the user to download the report.

The most important thing about this whole new experience is not just that these steps happen, but they happen inside one continuous chat experience.

Let us now go through the individual tools and take a look at some of their salient features:

1. `select-sales-metric` tool

Code - Tool Registration and MCP App

This is where the interactive chatflow begins. When the user prompts - "get sales data", instead of asking the user to specify every parameter via text, the agent calls this tool. VS Code (Host) then reads the linked resource and renders a rich HTML form with dropdown menus, toggle buttons, search region & multi-select state cards inside an iframe.

The Sales metric selector MCP App resides in sales-form.ts, where server-side data such as the list of valid sales regions (Indian states), sales metric and top sales regions are serialized directly into the HTML template:

...
<select id="metricSelect">${metricOptions}</select>
..
..
const indianStates = ${JSON.stringify(indianStates)};
const topStates = ${JSON.stringify(topStates)};

The makes the UI entirely self-contained as the page arrives already primed with the valid states and metrics. And, no further external API calls are required just to render the form or for data validation.

1.1. `get-sales-data` tool

Code - Tool Registration

When the user clicks "Submit" button in the Sales metric selector MCP App, the form doesn't just update the context — it calls another MCP tool from within the iframe itself by executing the below communication:

const toolResult = await sendRequest("tools/call", {
  name: "get-sales-data",
  arguments: {
    states: Array.from(selectedStates),
    metric: currentMetric,
    period: currentPeriod,
    year: currentYear,
  },
});
report = toolResult.structuredContent || null;

We trigger the data fetch manually via this tool as it allows us to have a deterministic control over the most critical element ("data") and we can explicitly define inputs without relying on agent reasoning. The tool is only visible to the app, and not the agent so it cannot call it accidentally. Only the MCP App iframe can invoke it via tools/call. This is a pattern I introduced in my previous article, and here you can see how powerful it becomes in a real workflow.

After fetching the result, ui/update-model-context request is sent to the host with the entire structured data (user input + data obtained for report) is added into the conversation context, so the agent can use it in subsequent turns.

await sendRequest("ui/update-model-context", {
  structuredContent: {
    selections: {
      metric: currentMetric,
      period: currentPeriod,
      year: currentYear,
      states: Array.from(selectedStates),
      selectedStateNames: selectedStateNames,
    },
    report: report,
  },
});
updateStatus("✅ Context updated successfully.");

2. `visualize-sales-data` tool

Code - Tool Registration & MCP App

Once the Agent has the structured data in its context, when the user prompts "visualize", the agent calls visualize-sales-data tool which renders a visualization dashboard inside the chat highlighting some key stats. Three additional complementary chart views are also presented in the dashboard for identifying deeper trends:

A stacked bar or line view for period-by-period comparison.
A doughnut chart to gauge a state's contribution share (%) in the sales metric.
A horizontal bar chart for ranked state comparison.

Two implementation details are especially worth noticing:

i) CSP is not a footnote, it is part of the Security Contract

The visualization MCP App depends on chart.js from a CDN:

<script src="https://cdn.jsdelivr.net/npm/chart.js@4.4.7/dist/chart.umd.min.js"><\/script>

As we discussed it in our previous article, the resource domain dependency is declared explicitly in the UI resource metadata while registering it.

csp: {
resourceDomains: ["https://cdn.jsdelivr.net"],
},

Without this declaration, the host sandbox will block the script. This demonstrates one of the most practical aspects of MCP Apps - the app states what it needs, and the host enforces that contract. An app cannot silently inherit broad network access just because it is an embedded HTML.

ii) MCP App receives tool input through notification

When the host invokes the visualize-sales-data tool, it forwards the structured payload to the iframe:

if (msg.method === "ui/notifications/tool-input") {
  const sc = msg.params?.structuredContent || msg.params?.arguments;
  if (sc && sc.report) {
    reportData = sc.report;
    selections = sc.selections;
    renderDashboard();
  }
}

This hydrates the UI with all the data it needs to render summary cards and charts. There is no string parsing or scraping of the tool response text. Just clean structured data flowing from tool to host to app.

3. `show-sales-pdf-report` tool

Code - Tool Registration & MCP App

Once the user has explored the interactive visualization dashboard, a PDF report generation can be triggered via show-sales-pdf-report tool using "generate pdf" prompt.

The following actions happen after the tool is triggered:

The server generates a PDF report using jsPDF and jspdf-autotable, and sends it to the client as a base64 string via structuredContent.
The PDF viewer MCP App decodes the base64 payload and renders it using PDF.js (from CDN). This interactive PDF viewer includes page navigation (previous/next) & zoom controls (keyboard shortcuts included).

The user also has the option to save the PDF report via a "Download PDF" button as shown below:

On clicking the "Download PDF" button a ui/download-file request is triggered which sends the resource (PDF) to VS Code which displays the save dialog.

const result = await request("ui/download-file", {
  contents: [
    {
      type: "resource",
      resource: {
        uri: "file:///" + pdfFileName,
        mimeType: "application/pdf",
        blob: pdfBase64,
      },
    },
  ],
});

That pattern is important as sandboxed iframes should not get to ability to save any file without informing the host which thereby informs the end user. Thus, the host stays in control, and the user gets a normal, expected download flow.

Serving MCP Apps Over HTTP

Currently, we are running the MCP server locally using Express with the Streamable HTTP transport - a departure from the stdio approach demonstrated in the previous article. This lets us run the server as an HTTP endpoint as we are moving closer to a deployable shape, making it ideal for web-based clients and remote deployments.

We can run the MCP server locally on node by executing:

cd /path/to/sample-mcp-apps-chatflow

# Install dependencies
npm install

# Development mode (with hot reload)
npm run dev

# Test with MCP Inspector
npm run inspector:http

which successfully displays

> sample-mcp-apps-chatflow@1.0.0 dev
> tsx src/index.ts

🚀 MCP Apps Chatflow server running at http://localhost:3000
📡 MCP endpoint: http://localhost:3000/mcp

To connect to this endpoint from VS Code Insiders, add the following config to .vscode/mcp.json:

{
  "servers": {
    "sample-mcp-apps-chatflow": {
      "type": "http",
      "url": "http://localhost:3000/mcp"
    }
  }
}

Deploying to Amazon Bedrock AgentCore Runtime (AgentCore CLI)

What is the value of building an awesome MCP server if you can't take it beyond the localhost? To be truly useful, it needs to be hosted so that your team or your users can connect to it from anywhere, without having to run it on their own system.

That's where Amazon Bedrock AgentCore Runtime comes in. It provides a managed, scalable runtime for your MCP server with built-in OAuth and session isolation.

Let us go ahead and deploy our TypeScript MCP server to Amazon Bedrock AgentCore Runtime.

Note: This guide uses the AgentCore CLI (@aws/agentcore), the current Node.js-based CLI. If you have the older Python-based bedrock-agentcore-starter-toolkit installed, uninstall it first to avoid command conflicts -- both tools use the agentcore command name.
pip uninstall bedrock-agentcore-starter-toolkit   # if installed via pip
pipx uninstall bedrock-agentcore-starter-toolkit  # if installed via pipx

Software prerequisites

Make sure you have the following softwares installed in your system:

AWS CLI with configured credentials (aws sts get-caller-identity must work)
Node.js 20+ and npm
Docker (or podman/finch) for container builds
AWS CDK bootstrapped in your target account/region (npx cdk bootstrap aws://ACCOUNT_ID/REGION)
VS Code or any other MCP Apps compatible Host or even terminal for testing the deployed MCP server

Step 1 - Prepare the server for AgentCore Runtime

AgentCore Runtime expects your MCP server to bind to 0.0.0.0:8000 and expose a POST /mcp endpoint using Streamable HTTP transport. The container must target linux/arm64.

In src/index.ts, update the port and host:

const port = parseInt(process.env.PORT || "8000");
const host = process.env.HOST || "0.0.0.0";

app.listen(port, host, () => {
  console.log(`🚀 MCP Apps Chatflow server running at http://${host}:${port}`);
  console.log(`📡 MCP endpoint: http://${host}:${port}/mcp`);
});

Step 2: Add a Dockerfile

Create a Dockerfile in the project root:

# Build stage
FROM --platform=linux/arm64 node:22-slim AS builder
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --ignore-scripts
COPY tsconfig.json ./
COPY src/ ./src/
RUN npm run build

# Production stage
FROM --platform=linux/arm64 node:22-slim
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --omit=dev --ignore-scripts
COPY --from=builder /app/dist/ ./dist/
ENV PORT=8000
ENV HOST=0.0.0.0
EXPOSE 8000
CMD ["node", "dist/index.js"]

Add a .dockerignore:

node_modules
dist
agentcore
.git
*.md

Verify it builds and starts locally:

docker build --platform linux/arm64 -t sales-mcp-apps .
docker run --platform linux/arm64 -p 8000:8000 sales-mcp-apps
# Test with MCP Inspector:
npx @modelcontextprotocol/inspector http://localhost:8000/mcp

Step 3: Install the AgentCore CLI

npm install -g @aws/agentcore
agentcore --version

Step 4: Create the AgentCore project

From the project root, scaffold the AgentCore configuration:

agentcore create \
  --name salesmcpapps \
  --protocol MCP \
  --build Container \
  --no-agent \
  --skip-python-setup \
  --skip-git

This generates:

agentcore/
  agentcore.json      # Project and runtime configuration
  aws-targets.json    # AWS account and region target
  .cli/               # CLI state (deployed-state.json)
  cdk/                # CDK app for deployment

Configure the runtime

The agentcore create --no-agent command creates an empty runtimes array. You must manually add the runtime configuration to agentcore/agentcore.json. The important fields are:

codeLocation - path to the directory containing your Dockerfile, relative to the project root (the parent of agentcore/). If your Dockerfile is in the project root, use ".". If you isolate your app code in a subdirectory (recommended to avoid CDK bundling issues), use that path (e.g., "app").
entrypoint - the file that starts your server (e.g., "dist/index.js"). Required even for Container builds.
runtimeVersion - must be "NODE_22" for Node.js projects.
protocol - "MCP" for MCP servers.

Example agentcore/agentcore.json:

{
  "$schema": "https://schema.agentcore.aws.dev/v1/agentcore.json",
  "name": "salesmcpapps",
  "version": 1,
  "managedBy": "CDK",
  "tags": {
    "agentcore:created-by": "agentcore-cli",
    "agentcore:project-name": "salesmcpapps"
  },
  "runtimes": [
    {
      "name": "salesmcpapps",
      "build": "Container",
      "entrypoint": "dist/index.js",
      "codeLocation": ".",
      "runtimeVersion": "NODE_22",
      "protocol": "MCP",
      "tags": {}
    }
  ],
  "memories": [],
  "credentials": [],
  "evaluators": [],
  "onlineEvalConfigs": [],
  "agentCoreGateways": [],
  "policyEngines": []
}

Configure deployment target

Edit agentcore/aws-targets.json with your account ID and region:

[
  {
    "name": "default",
    "description": "Production deployment",
    "account": "YOUR_ACCOUNT_ID",
    "region": "us-east-1"
  }
]

Tip: If your Dockerfile is in the project root alongside agentcore/, the CDK asset bundler may hit path-length errors because it recursively copies the cdk.out directory into itself. To avoid this, put your application code (Dockerfile, package.json, src/, tsconfig.json) in a subdirectory (e.g., app/) and set "codeLocation": "app".

Step 5: Set up Cognito authentication

The AgentCore CLI does not have a built-in command to set up Cognito (unlike the deprecated toolkit's agentcore identity setup-cognito). You need to create the Cognito resources manually.

Create a Cognito User Pool

export REGION=us-east-1

# Create user pool
POOL_ID=$(aws cognito-idp create-user-pool \
  --pool-name "salesmcpapps-pool" \
  --region $REGION \
  --query 'UserPool.Id' --output text)
echo "Pool ID: $POOL_ID"

# Add a domain for the OAuth token endpoint
aws cognito-idp create-user-pool-domain \
  --user-pool-id $POOL_ID \
  --domain "salesmcpapps-auth" \
  --region $REGION

Create a Resource Server and App Client

For machine-to-machine authentication (client_credentials flow):

# Create resource server with a custom scope
aws cognito-idp create-resource-server \
  --user-pool-id $POOL_ID \
  --identifier "salesmcpapps-auth" \
  --name "Sales MCP Apps" \
  --scopes '[{"ScopeName":"invoke","ScopeDescription":"Invoke MCP server"}]' \
  --region $REGION

# Create app client with client_credentials flow
CLIENT_OUTPUT=$(aws cognito-idp create-user-pool-client \
  --user-pool-id $POOL_ID \
  --client-name "salesmcpapps-client" \
  --generate-secret \
  --explicit-auth-flows ALLOW_USER_PASSWORD_AUTH ALLOW_REFRESH_TOKEN_AUTH \
  --allowed-o-auth-flows client_credentials \
  --allowed-o-auth-scopes "salesmcpapps-auth/invoke" \
  --allowed-o-auth-flows-user-pool-client \
  --supported-identity-providers COGNITO \
  --region $REGION)

CLIENT_ID=$(echo $CLIENT_OUTPUT | python3 -c "import sys,json; print(json.load(sys.stdin)['UserPoolClient']['ClientId'])")
CLIENT_SECRET=$(echo $CLIENT_OUTPUT | python3 -c "import sys,json; print(json.load(sys.stdin)['UserPoolClient']['ClientSecret'])")

echo "Client ID: $CLIENT_ID"
echo "Client Secret: $CLIENT_SECRET"
echo "Discovery URL: https://cognito-idp.$REGION.amazonaws.com/$POOL_ID/.well-known/openid-configuration"

Add JWT auth to agentcore.json

Update the runtime in agentcore/agentcore.json to add authorizerType and authorizerConfiguration:

{
  "name": "salesmcpapps",
  "build": "Container",
  "entrypoint": "dist/index.js",
  "codeLocation": ".",
  "runtimeVersion": "NODE_22",
  "protocol": "MCP",
  "authorizerType": "CUSTOM_JWT",
  "authorizerConfiguration": {
    "customJwtAuthorizer": {
      "discoveryUrl": "https://cognito-idp.us-east-1.amazonaws.com/YOUR_POOL_ID/.well-known/openid-configuration",
      "allowedClients": ["YOUR_CLIENT_ID"]
    }
  },
  "tags": {}
}

Step 6 - Deploy

agentcore deploy --target default --yes

This will:

Synthesize a CloudFormation template via CDK
Build your Docker container via AWS CodeBuild and push it to Amazon ECR
Create the AgentCore Runtime

The deployment takes roughly 5-10 minutes. On completion, the Runtime ARN is saved to agentcore/.cli/deployed-state.json.

Step 7 - Test the deployment

Get a Bearer token

TOKEN=$(curl -s -X POST \
  "https://salesmcpapps-auth.auth.$REGION.amazoncognito.com/oauth2/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials&client_id=$CLIENT_ID&client_secret=$CLIENT_SECRET&scope=salesmcpapps-auth/invoke" \
  | python3 -c "import sys,json; print(json.load(sys.stdin)['access_token'])")

Invoke the MCP server

URL-encode the Runtime ARN and call the invocations endpoint:

# Get runtime ARN from deployed state
RUNTIME_ARN=$(python3 -c "
import json
with open('agentcore/.cli/deployed-state.json') as f:
    state = json.load(f)
rt = list(state['targets']['default']['resources']['runtimes'].values())[0]
print(rt['runtimeArn'])
")

# URL-encode the ARN
ENCODED_ARN=$(python3 -c "import urllib.parse; print(urllib.parse.quote('$RUNTIME_ARN', safe=''))")

# Test MCP initialize
curl -s -X POST \
  "https://bedrock-agentcore.$REGION.amazonaws.com/runtimes/${ENCODED_ARN}/invocations" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "Authorization: Bearer $TOKEN" \
  -H "User-Agent: test-client/1.0" \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"test","version":"1.0.0"}}}' \
  | python3 -m json.tool

You should see a response with serverInfo, capabilities including resources and tools.

List tools and resources

After initialize, you can send tools/list and resources/list requests (include the mcp-session-id header from the initialize response).

Step 8 - Connect from VS Code

In VS Code with an MCP Apps-compatible client, create a .vscode/mcp.json in your workspace:

{
  "servers": {
    "sales-mcp-apps": {
      "type": "http",
      "url": "https://bedrock-agentcore.REGION.amazonaws.com/runtimes/DOUBLE_ENCODED_ARN/invocations",
      "headers": {
        "Authorization": "Bearer YOUR_TOKEN"
      }
    }
  }
}

Important: double-encode the / in the ARN. VS Code's URL parser decodes %2F back to / before sending the request, which breaks the ARN path segment. Use %252F instead of %2F so that after VS Code decodes once, the server receives the correct %2F.

For example, if your ARN is:
arn:aws:bedrock-agentcore:us-east-1:123456789012:runtime/my-server-abc123
The URL in mcp.json should be:
https://bedrock-agentcore.us-east-1.amazonaws.com/runtimes/arn%3Aaws%3Abedrock-agentcore%3Aus-east-1%3A123456789012%3Aruntime%252Fmy-server-abc123/invocations
Note %252F (not %2F) before the runtime name.

Once connected, VS Code will discover the tools and render the MCP Apps UIs (sales metric selector, visualization charts, PDF report viewer) as interactive HTML panels in the chat as shown below:

Clean up

To remove deployed resources, delete the CloudFormation stack:

aws cloudformation delete-stack \
  --stack-name AgentCore-salesmcpapps-default \
  --region $REGION

Also clean up Cognito:

aws cognito-idp delete-user-pool-domain \
  --user-pool-id $POOL_ID \
  --domain "salesmcpapps-auth" \
  --region $REGION

aws cognito-idp delete-user-pool \
  --user-pool-id $POOL_ID \
  --region $REGION

Final Words

MCP Apps is no longer a theoretical specification - it's a practical framework for building rich, interactive experiences inside AI chatflows. This sales analytics case study demonstrates the full spectrum: forms for structured input, Chart.js for visualization, jsPDF for document generation, and the MCP Apps protocol gluing it all together.

The patterns described here — app-only tools, structured content flow, CSP declarations, server-side PDF generation - are directly transferable to your own use cases. Whether you're building a CRM dashboard, a data annotation tool, or an interactive report builder, the approach remains the same. We also saw how Amazon Bedrock AgentCore can be used for deploying MCP remote servers securely.

I would love to hear your experience with MCP Apps or about any issues you faced while going through this article. Please mention it in the comment section below and I will definitely address it. Also, in case you have any other suggestion, feel free to add it in the comments.

by Ashita Prasad (GitHub, LinkedIn, X, Instagram)

Disclaimer: The opinions expressed here are my own and do not necessarily represent those of current or past employers. Please note that you are solely responsible for your judgement on checking facts. This post does not monetize via any advertising.

5 Techniques to Stop AI Agent Hallucinations in Production

Elizabeth Fuentes L — Mon, 30 Mar 2026 23:58:02 +0000

AI agent hallucinations occur when an LLM-powered agent fabricates data, selects the wrong tool, or ignores business rules during autonomous task execution. This post deploys 5 production-ready techniques to stop them — using managed hosting, serverless tools, database-driven guardrails, semantic tool routing, and a knowledge graph. Everything deploys as infrastructure as code.

TL;DR — 5 techniques, one production stack:

Graph-RAG on Neo4j AuraDB eliminates fabricated aggregations with Cypher queries
Semantic tool routing via AgentCore Gateway replaces custom FAISS indexes
Multi-agent validation on Lambda + DynamoDB catches errors single agents miss
Database-driven steering rules update agent behavior without redeploying
Hard hooks + soft steers separate financial constraints from operational adjustments

Every demo in this series on stopping AI agent hallucinations ran on a laptop. Hardcoded data, in-memory rules, a single user. The techniques worked, but the infrastructure did not scale. Moving to production means replacing local files with managed databases, in-process tools with serverless functions, and hardcoded rules with data you can update without redeploying.

This post walks through a production hotel booking agent that applies every technique from the series. We use Strands Agents for its native support of tool calling, hooks for guardrail enforcement, and MCP (Model Context Protocol) integration for connecting to Amazon Bedrock AgentCore Gateway. Similar patterns can be applied in LangGraph, AutoGen, CrewAI, or other agent frameworks.

Complexity note: This guide assumes familiarity with AWS CDK and core AWS services (Lambda, DynamoDB, S3). New to CDK? Start with the CDK Workshop first.

Working code: github.com/elizabethfuentes12/why-agents-fail-sample-for-amazon-agentcore

Prerequisites

You need the following:

AWS account with CDK bootstrapped in your target region
AWS CLI installed and configured
AWS CDK v2 (Cloud Development Kit) — infrastructure as code framework for deploying all resources
Python 3.11+ and uv package manager
OpenAI API key — the agent uses GPT-4o-mini as the LLM (Large Language Model) provider, swappable for Amazon Bedrock or other providers
Neo4j AuraDB Free account — only if deploying GraphRAG (Stack 2)

Series Overview

This is the final post in the series on stopping AI agent hallucinations:

RAG vs Graph-RAG: When Agents Hallucinate Answers — Knowledge graphs prevent hallucinated aggregations
Reduce Agent Errors and Token Costs with Semantic Tool Selection — Vector filtering reduces wrong tool choices
How to Stop AI Agents from Hallucinating Silently with Multi-Agent Validation — Cross-validation catches errors single agents miss
AI Agent Guardrails: Rules That LLMs Cannot Bypass — Symbolic rules enforced at the framework level
Runtime Guardrails for AI Agents — Steer, Don't Block — Agent self-corrects instead of failing
From Demo to Production (this post) — Deploy all techniques on AWS

Each post can be read independently. The repository contains all demos with runnable code.

How Does Each Anti-Hallucination Technique Map to Production?

The table below shows what each demo built locally and what replaces it in production:

Technique	Demo implementation	Production replacement
Graph-RAG (demo 01)	Local Neo4j Desktop + manual APOC scripts	Neo4j AuraDB Free + automated Lambda builder using SimpleKGPipeline
Semantic tool selection (demo 02)	In-memory FAISS (Facebook AI Similarity Search) index rebuilt on every run	AgentCore Gateway with MCP semantic routing — no custom index needed
Multi-agent validation (demo 03)	Hardcoded validator agents with in-memory state	`validate_booking_rules` Lambda backed by DynamoDB — same safety, lower latency
Neurosymbolic guardrails (demo 04)	Python hooks with hardcoded thresholds	Steering rules in DynamoDB — change rules without redeploying
Agent Control steering (demo 05)	Local Agent Control server with config files	STEER messages stored in DynamoDB rules — agent self-corrects from database-driven guidance

The anti-hallucination techniques remain the same. The infrastructure becomes managed, scalable, and updatable without code changes.

What Does the Production Architecture Look Like?

The production architecture runs on Amazon Bedrock AgentCore. Runtime hosts the agent code, and Gateway routes tool calls to AWS Lambda functions via MCP. Two independent AWS CDK stacks deploy the full infrastructure:

AgentCore Runtime — Hosts and runs your agent code in a managed environment
AgentCore Gateway — MCP-based semantic tool routing that connects agents to serverless functions

Stack 1 — HotelBookingAgentStack (deploy first, works on its own):

Resource	Purpose
3 Amazon DynamoDB tables	Hotels inventory, bookings, steering rules
AWS Secrets Manager	OpenAI API key stored securely
AgentCore Runtime	Managed agent hosting
AgentCore Gateway	MCP semantic routing to Lambda tools
7 AWS Lambda functions	search, book, get_booking, process_payment, confirm, cancel, validate

Stack 2 — GraphRAGStack (deploy when ready, adds FAQ capabilities):

Resource	Purpose
Amazon S3 bucket	300 hotel FAQ documents auto-uploaded during deploy
Lambda build_graph	Builds knowledge graph from documents using SimpleKGPipeline
Lambda query_knowledge_graph	Executes Cypher queries against Neo4j AuraDB
Neo4j AuraDB Free	Managed graph database ($0/month free tier)

How Do Steering Rules Work as Data Instead of Code?

In demo 04, business rules were hardcoded in Python. Changing a threshold meant changing code and redeploying. In production, rules live in DynamoDB. Update a row and the agent's behavior changes immediately.

Each rule has two messages: a fail_message that describes the violation and a steer_message that tells the agent how to self-correct:

{
    "rule_id": "max-guests",
    "action": "book",
    "condition_field": "guests",
    "operator": "gt",
    "threshold": 10,
    "fail_message": "Guest count exceeds maximum of 10",
    "steer_message": "Booking for 15 guests is not available, but you CAN book for up to 10. Adjust to 10 guests, proceed, and tell the user.",
    "enabled": true
}

The validate_booking_rules tool reads rules from DynamoDB before every booking action. When a rule is violated, the agent receives the STEER guidance and self-corrects, completing the task instead of blocking:

from strands import tool

@tool
def validate_booking_rules(
    action: str,
    guests: int = 0,
    check_in: str = "",
    check_out: str = "",
    booking_id: str = "",
) -> str:
    """Validate business rules BEFORE executing a booking action.
    ALWAYS call this before book_hotel, confirm_booking, or cancel_booking.
    Rules are loaded from the SteeringRules database, changeable without redeploying.
    """
    rules = _get_rules_for_action(action)       # DynamoDB scan
    context = _build_context(action, params)     # Derive nights, days_until_checkin
    violated = _evaluate_rules(rules, context)   # Symbolic evaluation

    if not violated:
        return f"PASS: All {len(rules)} rules passed for '{action}'. Proceed."

    lines = []
    for v in violated:
        lines.append(f"- {v['fail_message']}\n  STEER: {v['steer_message']}")
    return f"FAIL: {len(violated)} rule(s) violated:\n" + "\n".join(lines)

Changing a rule takes one command. No redeploy, no PR, takes effect immediately:

aws dynamodb update-item \
    --table-name HotelBookingAgentStack-SteeringRules \
    --key '{"rule_id": {"S": "max-guests"}}' \
    --update-expression "SET threshold = :t" \
    --expression-attribute-values '{":t": {"N": "8"}}'

The 6 steering rules deployed by default:

Rule	Action	What it catches	How the agent self-corrects
max-guests	book	More than 10 guests	Adjusts to 10, informs user
valid-dates	book	Check-out before check-in	Swaps dates, informs user
advance-booking	book	Same-day booking	Moves check-in to tomorrow
payment-before-confirm	confirm	Unpaid booking	Processes payment first
cancellation-window	cancel	Less than 48h to check-in	Suggests modification instead
already-cancelled	cancel	Booking already cancelled	Offers to create new booking

When Should You Block vs Steer?

Not every rule should be steerable. Payment before confirmation is a financial integrity constraint: the LLM must never bypass it, regardless of how it interprets a STEER message. The production agent uses a two-layer approach:

Layer 1 — Hard hooks (framework-level, cannot be bypassed):

from strands.hooks.events import BeforeToolCallEvent
from strands.hooks.registry import HookProvider, HookRegistry

class BookingGuardrailsHook(HookProvider):
    """Hard guardrails for financial and contractual constraints.
    The LLM cannot bypass these. They execute before the tool runs.
    """

    def register_hooks(self, registry: HookRegistry) -> None:
        registry.add_callback(BeforeToolCallEvent, self._validate)

    def _validate(self, event: BeforeToolCallEvent) -> None:
        tool_name = event.tool_use["name"]
        params = event.tool_use.get("input", {})

        if "confirm" in tool_name:
            booking = self._bookings.get_item(
                Key={"booking_id": params.get("booking_id", "")}
            ).get("Item")
            if booking and booking["status"] != "PAID":
                event.cancel_tool = (
                    "BLOCKED: Payment must be processed before confirmation. "
                    "Ask the user if they want to proceed with payment."
                )

Layer 2 — Soft steering (DynamoDB rules, agent self-corrects):

The validate_booking_rules tool shown above. Rules can be updated, disabled, or added without touching agent code.

How to decide which layer to use:

Layer	Mechanism	When to use	Can the LLM bypass it?
Hard hook	`event.cancel_tool` blocks execution	Financial, legal, compliance	No — framework intercepts before the tool runs
Soft steer	STEER message guides correction	Capacity limits, date adjustments, preferences	No bypass — but the agent adapts and completes the task
Prompt rule	System prompt instruction	Workflow order, communication style	Yes — the LLM may ignore under ambiguous input

Use hard hooks for rules where failure means financial or legal risk. Use soft steering for everything else. It reduces user friction without sacrificing safety.

How Does the MCP Integration with AgentCore Gateway Work?

The agent connects to AgentCore Gateway via MCP at startup and discovers all available tools at runtime, with no hardcoded tool list needed. In demo 02, we built a custom FAISS index to pre-filter tools by semantic similarity. In production, the Gateway replaces that entirely, routing each tool call to the right Lambda function based on semantic matching:

from bedrock_agentcore import BedrockAgentCoreApp
from strands import Agent
from strands.tools.mcp.mcp_client import MCPClient
from mcp.client.streamable_http import streamablehttp_client

# Using OpenAI-compatible interface via Strands SDK (not direct OpenAI usage)
from strands.models.openai import OpenAIModel

app = BedrockAgentCoreApp()

@app.entrypoint
def invoke(payload, context=None):
    """Entry point for AgentCore Runtime invocations."""
    model = OpenAIModel(
        model_id="gpt-4o-mini",
        client_args={"api_key": _openai_api_key},
    )
    hooks = [BookingGuardrailsHook()]

    # Gateway handles semantic tool routing via MCP
    mcp_client = MCPClient(lambda: streamablehttp_client(GATEWAY_URL))

    with mcp_client:
        tools = mcp_client.list_tools_sync()
        agent = Agent(
            model=model,
            tools=tools,
            system_prompt=SYSTEM_PROMPT,
            hooks=hooks,
        )
        prompt = payload.get("prompt", "")
        return str(agent(prompt))

The agent does not define tools inline. It connects to the Gateway, which discovers available Lambda functions and routes calls based on semantic matching. Adding a new tool (such as query_knowledge_graph) means registering it in the Gateway. No agent code changes.

How Does GraphRAG Work in Production?

Demo 01 demonstrates that traditional RAG (Retrieval-Augmented Generation) hallucinates when answering aggregation queries. "How many hotels have a pool?" gets a guess instead of a count. Graph-RAG eliminates this by executing Cypher queries on a knowledge graph that computes exact results.

In production, the knowledge graph runs on Neo4j AuraDB Free, a managed graph database with a $0/month free tier (200K nodes, no credit card required). The build pipeline is fully automated:

300 hotel FAQ documents upload to S3 during cdk deploy
build_graph Lambda reads documents, calls OpenAI to extract entities and relationships via SimpleKGPipeline, and loads them into Neo4j AuraDB
query_knowledge_graph Lambda executes Cypher queries and returns structured results
The query Lambda registers in AgentCore Gateway — the agent discovers it via MCP

Questions like "What amenities does the Grand Hotel have?" now traverse the graph (following connections between nodes) instead of guessing from text chunks.

The CDK stack supports two build modes via -c graph_mode=lite|full:

Build mode (`graph_mode`)	What it does	Documents	Build time
lite (default)	Uploads a subset of docs, builds graph in a single Lambda	30	~15 min
full	Uploads all docs, uses Step Functions to batch-process	300	~1-2 hours

cdk deploy GraphRAGStack                      # lite mode (30 docs)
cdk deploy GraphRAGStack -c graph_mode=full   # full mode (300 docs)

The booking agent works without GraphRAG. Deploy Stack 2 when hotel FAQ questions are frequent.

How to Deploy

Step 1 — Clone and install

git clone https://github.com/elizabethfuentes12/why-agents-fail-sample-for-amazon-agentcore
cd why-agents-fail-sample-for-amazon-agentcore/06-agentcore-production-demo

uv venv && uv pip install -r requirements.txt

Step 2 — Build and deploy

./create_deployment_package.sh

cd cdk
python3 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
cdk bootstrap   # Only needed once per AWS account/region
cdk deploy HotelBookingAgentStack

Step 3 — Store your OpenAI API key

Open AWS Secrets Manager Console
Find /HotelBookingAgentStack/openai-api-key
Set the secret value to your OpenAI API key

Step 4 — Seed hotel data

cd ..
AWS_DEFAULT_REGION=us-east-1 uv run python seed_data.py

Step 5 — Test

Open test_agent_local.ipynb and run all cells. The notebook tests every anti-hallucination layer — see the Try It Yourself section for the full scenario list.

Adding GraphRAG (optional, separate stack)

# 1. Create a free Neo4j AuraDB instance at neo4j.com/cloud/aura-free
# 2. Deploy the GraphRAG stack
cd cdk && INCLUDE_GRAPHRAG=1 cdk deploy GraphRAGStack

# 3. Store Neo4j credentials in Secrets Manager (4 secrets)
# 4. Build the knowledge graph
aws lambda invoke --function-name graphrag-build-graph \
    --region us-east-1 --cli-read-timeout 900 \
    /tmp/build-graph-output.json

# 5. Connect GraphRAG to the booking agent
cdk deploy HotelBookingAgentStack \
    -c graphrag_query_lambda_arn=<QueryLambdaArn from GraphRAGStack output>

Try It Yourself

The repository includes test_agent_local.ipynb — a notebook that tests every anti-hallucination layer against the deployed agent:

#	Scenario	Technique (from series)	What the agent does
1	Full booking flow	All layers	validate → book → pay → validate → confirm
2	15 guests (max 10)	Soft steering (demo 05)	Self-corrects to 10, informs user
3	Confirm without payment	Hard hook (demo 04)	Blocks confirmation, asks to pay first
4	Sold-out hotel	Grounded retrieval (demo 01)	Returns "no rooms available" from DynamoDB
5	City with no hotels	Grounded retrieval	Returns "no hotels found", no fabrication
6	Non-existent hotel	Grounded retrieval	Returns error, does not invent a hotel
7	Hotel amenities query	Graph-RAG (demo 01)	Cypher query returns real data from Neo4j

cd 06-agentcore-production-demo
uv venv && uv pip install -r requirements.txt
jupyter notebook test_agent_local.ipynb

Run all cells top to bottom. The notebook reads the AgentRuntimeArn from CloudFormation outputs automatically.

Built-in Observability

AgentCore provides built-in observability when you include the OpenTelemetry dependencies in your agent package. Add strands-agents[otel] and aws-opentelemetry-distro to your agent's requirements.txt:

strands-agents[openai,otel]>=1.27.0
aws-opentelemetry-distro>=0.7.0

With these dependencies, AgentCore automatically instruments Strands Agents — capturing invocation logs, tool call traces (which Lambda was called, input/output, latency), and error tracking (failed tool calls, guardrail blocks). You can monitor how the agent handles each anti-hallucination layer (steering, hooks, grounded retrieval) in Amazon CloudWatch without adding custom logging.

See the observability getting started guide for details.

How Fast Are the Anti-Hallucination Tools?

Tool latency matters in production agents — every tool call adds to the end-to-end response time. If a
validation check takes 2 seconds, users notice. We benchmarked the deployed Lambda functions to measure real
execution duration (from CloudWatch REPORT lines, not CLI round-trip time).

DynamoDB-Backed Tools

Function	Cold Start	Warm p50	Warm p90	Memory Used
`validate_booking_rules`	~550–620 ms	~25 ms	~105 ms	88 MB / 256 MB
`search_available_hotels`	~540–660 ms	~16 ms	~43 ms	88 MB / 256 MB

The steering rules check (validate_booking_rules) runs before every booking action. At ~25 ms warm, it adds negligible latency while preventing hallucinated bookings that violate business rules — a worthwhile trade-off vs. fixing bad bookings after the fact.

Neo4j AuraDB (GraphRAG)

Function	Cold Start	Warm p50	Warm p90	Memory Used
`query_knowledge_graph`	~1.9–2.0 s	~13 ms	~75 ms	122 MB / 256 MB

Neo4j AuraDB Free runs outside your VPC, but the neo4j Python driver reuses TCP connections across warm invocations. After the first call resolves credentials from Secrets Manager and establishes the connection, subsequent Cypher queries execute in 11–30 ms — comparable to DynamoDB.

DynamoDB vs Neo4j AuraDB: Side by Side

Metric	DynamoDB (steering rules)	Neo4j AuraDB (knowledge graph)
Warm p50	~16–25 ms	~13 ms
Warm p90	~43–105 ms	~75 ms
Cold start	~550–660 ms	~1.9–2.0 s
Driver reuse	boto3 (local)	neo4j driver (TCP keepalive)

Both backends deliver sub-100 ms warm latency, which means tool calls add minimal overhead to the agent's end-to-end response time. The cold start difference (~600 ms vs ~2 s) is only relevant for the first invocation after an idle period.

Benchmark methodology: 10 consecutive invocations per function using aws lambda invoke against the deployed stack in us-east-1. Duration values extracted from CloudWatch Lambda REPORT log lines. Cold start = Init Duration + Duration. Warm = Duration only (no Init).

5 Lessons from Moving Anti-Hallucination Techniques to Production

1. Separate hard blocks from soft steers. Payment-before-confirmation is a hard block: the agent cannot work around it. Guest count limits are a soft steer where the agent adjusts and completes the task. Mixing them in the same mechanism (all hooks or all prompts) either blocks too much or steers too little.

2. Store rules in a database, not in code. Business rules change more frequently than agent code. When the maximum guest count changes from 10 to 8, an operations team should update a DynamoDB item, not open a pull request and wait for CI/CD.

3. Deploy stacks independently. The booking agent works without GraphRAG. Independent stacks mean you can ship the core agent quickly and add capabilities when the use case demands it.

4. Test locally against the same data. The test_agent_local.ipynb notebook calls the same DynamoDB tables as production. Run all 7 test scenarios locally before deploying to AgentCore. The behavior is identical.

5. Keep tools as pure CRUD (Create, Read, Update, Delete). Lambda functions do one thing: read or write data. All business rule enforcement happens in the guardrail layers (hooks and validate tool). This keeps tools reusable and guardrails centralized.

Key Takeaways

Hard hooks block what the LLM must never bypass (financial, legal, compliance constraints)
Soft steering corrects what the agent can adapt (capacity, dates, preferences) — reducing user friction
DynamoDB steering rules let operations teams change agent behavior without code deploys
AgentCore Gateway replaces custom tool-selection indexes with managed MCP-based semantic routing
Graph-RAG on Neo4j AuraDB eliminates fabricated aggregations by computing exact results with Cypher queries

Clean Up

To avoid ongoing charges:

cd cdk
cdk destroy HotelBookingAgentStack
INCLUDE_GRAPHRAG=1 cdk destroy GraphRAGStack

Frequently Asked Questions

What is Amazon Bedrock AgentCore?

Amazon Bedrock AgentCore is a managed service for deploying and running AI agents. It provides two components: Runtime (hosts agent code) and Gateway (MCP-based tool routing that connects agents to serverless functions). AgentCore handles scaling, networking, and credential management so you do not need to build that infrastructure yourself.

Can I use Amazon Bedrock models instead of OpenAI?

Yes. The agent supports any provider compatible with Strands Agents, including Amazon Bedrock, Anthropic, or Ollama. Change the model in booking_agent.py. The anti-hallucination techniques work independently of the LLM provider.

What is the difference between hard hooks and soft steering?

Hard hooks use event.cancel_tool to block tool execution at the framework level. The LLM cannot bypass them. Soft steering returns a STEER message that instructs the agent how to self-correct: the agent adjusts parameters and completes the task. Use hard hooks for financial and compliance rules. Use soft steering for operational rules where the agent can adapt.

How much does this architecture cost?

All AWS services used (DynamoDB on-demand, Lambda, Secrets Manager) are eligible for the AWS Free Tier. Neo4j AuraDB Free has a $0/month tier. For current pricing details, see the AWS Pricing page. For a demo or low-traffic deployment, total infrastructure cost is minimal, excluding LLM API costs.

Do I need GraphRAG for the agent to work?

No. Stack 1 (HotelBookingAgentStack) deploys a fully functional booking agent with search, booking, payment, and validation tools. GraphRAG (Stack 2) adds hotel FAQ capabilities. Deploy it when you need answers about amenities, policies, and services.

Can I apply these patterns with other agent frameworks?

Yes. The guardrail patterns (database-driven rules, hard hooks, and soft steering) are framework-agnostic. Strands provides native hook and MCP support, but LangGraph, AutoGen, and CrewAI offer similar extension points for tool interception and pre-validation.

How does the agent discover tools via MCP at runtime?

The agent connects to AgentCore Gateway using MCPClient from Strands. On startup, it calls list_tools_sync() to discover all available Lambda tools registered in the Gateway. When the agent needs a tool, the Gateway routes the call based on semantic matching. There is no hardcoded tool list in the agent code. Adding a new tool means registering it in the Gateway; the agent discovers it automatically on the next invocation.

Research Background

The techniques in this series are grounded in recent research on AI agent reliability:

RAG-KG-IL: Multi-Agent Hybrid Framework for Reducing Hallucinations — Knowledge graphs reduce hallucinations compared to standalone LLMs
Internal Representations as Indicators of Hallucinations in Agent Tool Selection — Tool selection errors increase with tool count; semantic routing mitigates this
Teaming LLMs to Detect and Mitigate Hallucinations — Multi-agent validation detects errors that single agents miss
MetaRAG: Metamorphic Testing for Hallucination Detection — Hallucinations are inherent to LLMs without structured grounding

The complete code — CDK stacks, Lambda tools, agent runtime, steering rules, test notebook, and 300 hotel FAQ documents — is in the repository.

Gracias!

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

Tiempo real en aplicaciones web: Polling vs Subscriptions

Ramses Mata — Mon, 30 Mar 2026 18:48:03 +0000

En este artículo vas a entender las dos estrategias principales para mantener datos frescos en tu aplicación: Polling (tu app pregunta constantemente al servidor) y Subscriptions (el servidor avisa a tu app cuando hay cambios). Vamos a compararlas lado a lado y darte un framework para elegir la correcta según tu caso de uso. Sin atarnos a ninguna tecnología específica, los conceptos aplican ya sea que uses GraphQL, REST, WebSockets, o cualquier otro protocolo o estilo de API.

Imagina que estás usando una app de chat. Envías un mensaje y... ¿cómo sabe tu app que la otra persona ya respondió? ¿Cómo aparecen las notificaciones sin que tú hagas nada? ¿Cómo se actualizan los marcadores de un partido en vivo?

Todas estas experiencias tienen algo en común: necesitan datos frescos sin que el usuario tenga que recargar la página. A esto le llamamos tiempo real (o algo muy cercano a ello). Y hay dos formas principales de lograrlo: que tu app le pregunte al servidor constantemente si hay algo nuevo (Polling), o que el servidor le avise a tu app en el momento que algo cambia (Subscriptions).

¿Qué es Polling?

Polling es la estrategia más simple: tu aplicación le pregunta al servidor "¿hay algo nuevo?" cada cierto tiempo.

Piénsalo como cuando eras niño en un viaje largo por carretera y le preguntabas a tus papás cada 5 minutos: "¿Ya llegamos? ¿Ya llegamos? ¿Ya llegamos?" No importa si la respuesta cambió o no, tú sigues preguntando.

¿Cómo funciona?

Si eres más visual, este diagrama te puede ayudar a entender el flujo:

Tu app envía una petición al servidor (por ejemplo, cada 5 segundos)
El servidor responde con los datos más recientes
Tu app actualiza la interfaz si hay cambios
Espera el intervalo definido y repite

En JavaScript se ve algo así:

// Polling: preguntar cada 5 segundos
setInterval(async () => {
  const datos = await fetch("/api/mensajes");
  actualizarInterfaz(datos);
}, 5000);

Simple, ¿verdad? Y esa es precisamente su mayor fortaleza.

Ventajas y desventajas del Polling

Ventajas	Desventajas
Fácil de implementar: Es una petición HTTP normal en un loop	Desperdicio de recursos: Si no hay datos nuevos, la petición fue innecesaria
Funciona con cualquier infraestructura: No necesitas nada especial en el servidor	Latencia: Hay un retraso entre que el dato cambia y tu app se entera. Con un intervalo de 5s, en el peor caso tu usuario ve el dato 5 segundos tarde. Con subscriptions, la latencia típica es de ~50-150ms
Stateless: Cada petición es independiente, no hay conexiones persistentes	Carga en el servidor: Muchos clientes haciendo polling = muchas peticiones constantes
Fácil de debuggear: Puedes ver cada petición en las herramientas de desarrollo del navegador	Tradeoff del intervalo: Intervalo corto = más carga, intervalo largo = más retraso

💡 Tip importante: El intervalo de polling es una decisión de diseño clave. Un dashboard que muestra métricas cada minuto no necesita polling cada segundo. Ajusta el intervalo a lo que tu usuario realmente necesita ver.

¿Qué son las Subscriptions?

Las Subscriptions invierten el modelo: en lugar de que tu app pregunte constantemente, el servidor le avisa cuando hay algo nuevo.

Siguiendo con la analogía del viaje: en vez de preguntar "¿ya llegamos?" cada 5 minutos, le dices a tus papás "avísenme cuando lleguemos" y te pones a hacer otra cosa. Ellos te avisan solo cuando es necesario.

¿Cómo funcionan?

Si eres más visual, este diagrama te puede ayudar a ver la diferencia con polling:

Tu app establece una conexión persistente con el servidor (generalmente usando WebSockets)
Tu app le dice al servidor "avísame cuando cambien los mensajes"
El servidor mantiene esa conexión abierta
Cuando hay datos nuevos, el servidor los envía inmediatamente por esa conexión
Tu app recibe los datos y actualiza la interfaz

En JavaScript:

// Subscription: el servidor te avisa
const conexion = subscribe("/mensajes");

conexion.on("nuevoDato", (datos) => {
  actualizarInterfaz(datos);
});

Fíjate en la diferencia: no hay intervalo, no hay loop. Tu app simplemente reacciona cuando llegan datos nuevos.

Ventajas y desventajas de las Subscriptions

Ventajas	Desventajas
Tiempo real verdadero: Los datos llegan al instante, sin retraso	Más complejo de implementar: Necesitas manejar conexiones persistentes, reconexiones, y estado
Eficiente: Solo se transfieren datos cuando realmente hay cambios	Infraestructura más sofisticada: El servidor necesita soportar WebSockets o protocolos similares
Menos carga innecesaria: No hay peticiones vacías cuando nada cambió	Stateful: El servidor mantiene el estado de cada conexión activa
Mejor experiencia de usuario: La app se siente viva y responsiva	Escalabilidad diferente: Miles de conexiones abiertas simultáneas requieren planificación

💡 Tip importante: Las subscriptions no son magia, por detrás y mientras no vemos a simple vista, tecnologías como WebSockets mantienen una conexión TCP abierta entre el cliente y el servidor. Esto permite comunicación bidireccional, pero también significa que el servidor necesita gestionar el estado de cada conexión. La buena noticia es que no estamos hablando de tecnología experimental, WebSockets es soportado por más del 97% de los navegadores.

🔗 Conexión con nuestra serie: Si vienes siguiendo la serie de GraphQL, te adelanto algo: cuando implementemos subscriptions con AWS AppSync, no vamos a tener que preocuparnos por manejar WebSockets directamente. AppSync se encarga de toda esa infraestructura por nosotros: conexiones, reconexiones, escalabilidad. Nosotros solo definimos qué datos queremos escuchar.

Polling vs Subscriptions: Comparación lado a lado

Este diagrama muestra ambos modelos con el mismo escenario para que veas la diferencia de un vistazo:

Aspecto	Polling	Subscriptions
Dirección	Cliente pregunta → Servidor responde	Servidor avisa → Cliente recibe
Latencia	Depende del intervalo (segundos)	Casi instantánea (milisegundos)
Carga en servidor	Constante (aunque no haya cambios)	Solo cuando hay datos nuevos
Complejidad	Baja	Media-Alta
Infraestructura	HTTP estándar	WebSockets u otro protocolo persistente
Estado	Stateless	Stateful
Escalabilidad	Más peticiones = más carga	Más conexiones = más memoria
Debugging	Fácil (peticiones HTTP normales)	Más complejo (conexiones persistentes)

Para ponerlo en perspectiva: si tienes 1,000 usuarios conectados con polling cada 5 segundos, tu servidor recibe 12,000 peticiones por minuto aunque no haya cambiado absolutamente nada. Con subscriptions, esas 12,000 peticiones se convierten en 0 hasta que realmente haya datos nuevos.

¿Cuándo gana Polling?

Datos que cambian con poca frecuencia (dashboard de métricas diarias)
Infraestructura simple sin soporte para WebSockets
Cuando la latencia de unos segundos es aceptable
Prototipos rápidos donde la simplicidad importa más

¿Cuándo ganan las Subscriptions?

Datos que cambian constantemente (chat, colaboración en tiempo real)
La latencia baja es crítica (trading, juegos, notificaciones)
Muchos eventos por segundo donde polling sería ineficiente
Experiencias donde el usuario espera actualizaciones instantáneas

💡 Tip: La complejidad de implementar subscriptions se reduce significativamente cuando usas servicios administrados que manejan la infraestructura de WebSockets por ti.

¿Cuándo usar Polling y cuándo usar Subscriptions?

No hay un ganador universal. La mejor opción depende de tu caso de uso específico. Aquí tienes algunos ejemplos para guiarte:

Caso de uso	Enfoque recomendado	¿Por qué?
Chat en tiempo real	Subscriptions	Los usuarios esperan ver mensajes al instante
Dashboard de analytics	Polling	Los datos se actualizan cada minutos u horas
Feed de redes sociales	Polling (o híbrido)	No necesitas ver cada like al instante
Marcadores deportivos en vivo	Subscriptions	Cada segundo cuenta para la experiencia
Notificaciones	Subscriptions	El usuario espera recibirlas inmediatamente
Reporte de inventario	Polling	Se consulta periódicamente, no en tiempo real
Editor colaborativo (tipo Google Docs)	Subscriptions	Cada keystroke necesita sincronizarse

El enfoque híbrido

Algo que vale la pena mencionar: no siempre tienes que elegir uno u otro. Muchas aplicaciones usan ambos enfoques dependiendo de la funcionalidad.

Por ejemplo, una app de delivery podría usar:

Subscriptions para el tracking en tiempo real del repartidor
Polling para actualizar el catálogo de restaurantes cada cierto tiempo

La clave es preguntarte: ¿Qué tan rápido necesita mi usuario ver este cambio?

Si la respuesta es "inmediatamente" → Subscriptions
Si la respuesta es "en los próximos segundos o minutos está bien" → Polling
Si no estás seguro → Empieza con polling (es más simple) y migra a subscriptions si la experiencia lo requiere

Preguntas frecuentes

¿Qué es long polling?

Long polling es un punto intermedio entre polling y subscriptions. En vez de preguntar cada X segundos y recibir una respuesta inmediata (aunque esté vacía), tu app hace una petición y el servidor la mantiene abierta hasta que tenga datos nuevos. Cuando responde, tu app inmediatamente hace otra petición. Es más eficiente que polling tradicional pero no tan eficiente como subscriptions con WebSockets.

¿Las subscriptions consumen más recursos que polling?

Depende. Las subscriptions mantienen conexiones abiertas, lo que consume memoria en el servidor por cada cliente conectado. Polling consume ancho de banda y CPU por cada petición repetida. Con pocos usuarios y cambios frecuentes, subscriptions es más eficiente. Con muchos usuarios y cambios poco frecuentes, polling puede ser más simple de escalar.

¿Se pueden combinar polling y subscriptions?

Sí, y es más común de lo que parece. Muchas aplicaciones usan subscriptions para funcionalidades que necesitan tiempo real (como chat o notificaciones) y polling para datos que cambian con menos frecuencia (como un catálogo de productos). No tienes que elegir uno para toda tu aplicación, puedes usar el enfoque que mejor se adapte a cada funcionalidad.

Conclusión

Recapitulemos lo que aprendimos:

Polling = tu app pregunta constantemente. Simple, stateless, pero puede ser ineficiente
Subscriptions = el servidor te avisa. Eficiente y en tiempo real, pero más complejo
No hay un "ganador" cada enfoque tiene su lugar dependiendo de tu caso de uso
Los enfoques híbridos son completamente válidos y muy comunes en aplicaciones reales

La próxima vez que estés diseñando una funcionalidad que necesite datos frescos, ya tienes las herramientas conceptuales para tomar una decisión informada.

En el próximo artículo de la serie, vamos a poner estos conceptos en práctica implementando subscriptions en nuestra API de GraphQL con AWS AppSync. ¿Recuerdas toda la complejidad que mencionamos sobre manejar WebSockets, conexiones persistentes y reconexiones? AppSync se encarga de todo eso por nosotros, por debajo usa los mismos WebSockets que explicamos aquí, pero nosotros solo necesitamos definir qué datos queremos escuchar. Vamos a ver cómo pasar de la teoría a código funcionando.

8 Agents Wrote Perfect Components - And Nothing Worked

Dennis Traub — Fri, 27 Mar 2026 22:50:44 +0000

TL;DR: Parallel AI agents don't coordinate on shared contracts, such as column names, URL paths, parameter formats, or identifiers. Extract those contracts into a single reference file before generation, and run a review agent that traces end-to-end data flows once the parallel agents are done. This single step fixed all 17 bugs in one pass.

I launched 8 AI agents in parallel to build a full-stack app on AWS: infrastructure stacks, a React frontend, and a Java backend. Each agent owned one piece, and they all delivered clean, compiling code. The CDK type-checked, the Java backend followed Spring Boot conventions, the React UI looked nice.

But when I tried to wire them together I hit bugs at every single boundary.

The architecture

A full-stack app on AWS with a lot of moving parts. Multiple CDK stacks for the infrastructure (IAM, VPC, DB with seed functions, Cognito, CodePipeline, CloudFront/WAF), a Spring Boot backend on ECS Fargate, and a React frontend hosted on S3.

The implementation plan was thorough and covered every component. But it wasn't detailed enough for agents that need to agree on shared contracts.

The bugs

The first two block everything. Bugs 3 through 5 only show up after you fix the previous ones.

Bug 1: The Spring Boot app won't even start

The seed data function creates a schema with passenger_id and full_name, but the Spring Boot entity maps to id and name:

-- Agent 1: seed data function creates the schema
CREATE TABLE passengers (
    passenger_id   VARCHAR(64) PRIMARY KEY,
    full_name      VARCHAR(255) NOT NULL,
    ...
);

// Agent 2: The Spring Boot entity maps the table
@Column(name = "id")       // Schema says "passenger_id"
@Column(name = "name")     // Schema says "full_name"

With ddl-auto: validate, Hibernate checks the mapping on startup. But the columns don't exist, so the ECS task crashes before serving a single request.

Bug 2: Every call returns 404

The CDK stack registers ALB routes for /approve and /generate while the Java client sends requests to /voucher/approve and /voucher/generate:

CDK ALB routes:  /approve, /generate
Java client:     /voucher/approve, /voucher/generate

Both agents wrote correct, working code in isolation, but the CDK stack used clean paths while the Java client added a service prefix. Neither checked the other.

Bug 3: Missing request fields

A downstream service validates four required fields. The Java client sends three:

Lambda expects:  escalationId, passengerId, amount, situation
Java sends:      escalationId, passengerId, amount

Even with the URLs from bug 2 fixed, every approval returns 400.

Bug 4: User lookup doesn't work

This one was the most interesting: three systems work with the user, and each of them created their own identifier:

Cognito custom attribute:  custom:passenger_id = "pax-a1b2c3d4-e5f6-..."
RDS seed data:             passenger_id = "PAX-a1b2c3d4-e5f6-..."
JWT subject claim:         sub = "a1b2c3d4-e5f6-..."  (Cognito UUID)

The backend uses jwt.getSubject() to look up the user. That's a Cognito UUID - neither prefixed with pax- nor with PAX-. No user lookup ever returns a result.

Three agents. Three naming conventions. Zero coordination.

Bug 5: Every status lookup returns "not found"

A downstream service returns JSON. The Java client parses XML:

{"status": "FOUND_LOCAL", "location": "Warehouse-B-Shelf-47"}

String status = extractXmlElement(xml, "status");  // Looks for <status>...</status>

No XML tags in a JSON string. extractXmlElement returns empty for every single request.

The agent that wrote the downstream service followed one spec (JSON). The agent that wrote the Java client followed a different spec (XML).

Bugs 6 to 17: SSM parameter path mismatches

One CDK stack writes an SSM parameter. Another CDK stack reads it. But they never coordinated on paths:

Producer stack writes:  /${AppName}/test/data/rds-secret-arn
Consumer stack reads:   /${AppName}/${Env}/data/rds-password-secret-arn

...

Twelve SSM parameters mismatched between producer and consumer stacks. The app fails on every one of them.

Why parallel agents can't catch this

Each agent had context about the overall plan and its own component. But none of them could see the implementation details that the others came up with.

When I write an app, I hold the contracts in working memory. "The column is passenger_id, so I'll use that in both the migration and the entity." But an AI agent writing the migration doesn't know what the entity agent chose for its column name - and vice versa.

The plan contained all the high-level information, but the agents were reading different sections and making their own calls on the shared details.

Each agent wrote correct code that followed good conventions. But they never coordinated. Like digging a tunnel from two sides of a mountain - without ever checking in with each other.

How I found all of them at once

After generation, before actually deploying the app. I ran an architecture review agent with a simple instruction:

Trace the actual data flow from user login through form submission to the downstream service calls, following every cross-component boundary.

It found every one of the bugs in a single pass.

The review agent started at the user-facing entry point, traced the request through every boundary, and at each one checked whether what one component sent actually matched what the next one expected. Same thing integration tests do after deployment, but you catch it before deploying anything.

How to prevent seam bugs

Before launching parallel agents, pull every shared contract out of the plan into a single reference file and pass it to every agent as mandatory context.

Then, after your parallel agents did their thing, run a review agent that traces a few real user flows across all the boundaries.

Fix the seam bugs in one pass, then deploy.

FAQ

What are seam bugs in AI-generated code?

Seam bugs are integration defects at the boundaries between components built by different AI agents. Each agent writes correct, working code in isolation, but the components don't fit together because the agents each made their own decisions about shared details - things like what a column is called, what path an API lives at, or what format an identifier uses.

Why does parallel AI code generation produce integration bugs?

Each agent only sees its own component and the plan it was given. When two agents need to agree on something - say, what a database column is called - they each pick a reasonable name independently. Those names often don't match. The plan says what the column should represent, but not necessarily the exact string both sides should use.

How do you catch integration bugs from parallel AI agents?

Run a single review agent after generation that traces real user flows across all the boundaries. Give it a prompt like "trace the data flow from user login through the frontend, backend, to databases and downstream service calls, checking every boundary." It will catch the mismatches in one pass.

My 8 Agents Wrote Perfect Components - And Nothing Worked

Dennis Traub — Fri, 27 Mar 2026 22:50:44 +0000

But when I tried to wire them together I hit bugs at every single boundary.

The architecture

The implementation plan was thorough and covered every component. But it wasn't detailed enough for agents that need to agree on shared contracts.

The bugs

The first two block everything. Bugs 3 through 5 only show up after you fix the previous ones.

Bug 1: The Spring Boot app won't even start

The seed data function creates a schema with passenger_id and full_name, but the Spring Boot entity maps to id and name:

-- Agent 1: seed data function creates the schema
CREATE TABLE passengers (
    passenger_id   VARCHAR(64) PRIMARY KEY,
    full_name      VARCHAR(255) NOT NULL,
    ...
);

// Agent 2: The Spring Boot entity maps the table
@Column(name = "id")       // Schema says "passenger_id"
@Column(name = "name")     // Schema says "full_name"

With ddl-auto: validate, Hibernate checks the mapping on startup. But the columns don't exist, so the ECS task crashes before serving a single request.

Bug 2: Every call returns 404

The CDK stack registers ALB routes for /approve and /generate while the Java client sends requests to /voucher/approve and /voucher/generate:

CDK ALB routes:  /approve, /generate
Java client:     /voucher/approve, /voucher/generate

Both agents wrote correct, working code in isolation, but the CDK stack used clean paths while the Java client added a service prefix. Neither checked the other.

Bug 3: Missing request fields

A downstream service validates four required fields. The Java client sends three:

Lambda expects:  escalationId, passengerId, amount, situation
Java sends:      escalationId, passengerId, amount

Even with the URLs from bug 2 fixed, every approval returns 400.

Bug 4: User lookup doesn't work

This one was the most interesting: three systems work with the user, and each of them created their own identifier:

Cognito custom attribute:  custom:passenger_id = "pax-a1b2c3d4-e5f6-..."
RDS seed data:             passenger_id = "PAX-a1b2c3d4-e5f6-..."
JWT subject claim:         sub = "a1b2c3d4-e5f6-..."  (Cognito UUID)

The backend uses jwt.getSubject() to look up the user. That's a Cognito UUID - neither prefixed with pax- nor with PAX-. No user lookup ever returns a result.

Three agents. Three naming conventions. Zero coordination.

Bug 5: Every status lookup returns "not found"

A downstream service returns JSON. The Java client parses XML:

{"status": "FOUND_LOCAL", "location": "Warehouse-B-Shelf-47"}

String status = extractXmlElement(xml, "status");  // Looks for <status>...</status>

No XML tags in a JSON string. extractXmlElement returns empty for every single request.

The agent that wrote the downstream service followed one spec (JSON). The agent that wrote the Java client followed a different spec (XML).

Bugs 6 to 17: SSM parameter path mismatches

One CDK stack writes an SSM parameter. Another CDK stack reads it. But they never coordinated on paths:

Producer stack writes:  /${AppName}/test/data/rds-secret-arn
Consumer stack reads:   /${AppName}/${Env}/data/rds-password-secret-arn

...

Twelve SSM parameters mismatched between producer and consumer stacks. The app fails on every one of them.

Why parallel agents can't catch this

Each agent had context about the overall plan and its own component. But none of them could see the implementation details that the others came up with.

The plan contained all the high-level information, but the agents were reading different sections and making their own calls on the shared details.

Each agent wrote correct code that followed good conventions. But they never coordinated. Like digging a tunnel from two sides of a mountain - without ever checking in with each other.

How I found all of them at once

After generation, before actually deploying the app. I ran an architecture review agent with a simple instruction:

Trace the actual data flow from user login through form 
submission to the downstream service calls, following every 
cross-component boundary.

It found every one of the bugs in a single pass.

How to prevent seam bugs

Before launching parallel agents, pull every shared contract out of the plan into a single reference file and pass it to every agent as mandatory context.

Then, after your parallel agents did their thing, run a review agent that traces a few real user flows across all the boundaries.

Fix the seam bugs in one pass, then deploy.

FAQ

What are seam bugs in AI-generated code?

Why does parallel AI code generation produce integration bugs?

How do you catch integration bugs from parallel AI agents?

How I trained a computer vision model on the AWS Free Tier

Esin Saribudak — Fri, 27 Mar 2026 01:20:43 +0000

Last updated: March 26, 2026

Developers hide Easter eggs in code. Filmmakers hide them in scenes. I hid them in AI-generated images and asked Amazon Rekognition to find them.

If you've ever wondered whether AWS Free Tier gives you enough credits to build something cool, this post is for you. I built an Easter egg detector powered by Amazon Rekognition, tested its standard object detection API on 37 images, and trained a custom model, all with my AWS Free Tier credits.

(If you haven't set up a Free Tier account, check out this great guide!)

The idea

I wanted to build a simple and fun app where I can upload a photo and have the app tell me if there's an Easter egg in it. It sounds kind of silly, but the technical problem it maps to — locating a small, specific object in a complex scene — is a foundational one for the field of computer vision.

AWS has a lot of services for different AI/ML use cases, including Amazon Rekognition for computer vision. I learned that organizations like C-SPAN and the NFL use it to understand what's in their images and video. And Amazon Rekognition is available on the AWS Free Tier, which makes experimenting with it easier.

The service gives you different ways to figure out what's in images. The DetectLabels API works out of the box and recognizes thousands of common objects and concepts, everything from aircraft to zucchini to birthday parties. Custom Labels let you train your own computer vision model when the built-in labels fall short. With this project, I wanted to find out where the first one stops being useful and the other is needed.

What I built

The app I built to explore that question is a Streamlit app with two modes. Standard mode sends your image to the DetectLabels API and checks if it returns "Egg" or "Easter Egg" in the labels. Custom Labels mode uses a custom model I trained on my own images. Both draw bounding boxes around any eggs they find.

The application code is about 200 lines of Python, 100 lines of which is UI-related, and you can check it out at this GitHub repo. You upload an image, the app calls Rekognition using the AWS SDK for Python (Boto3), checks the response, and draws some boxes around any eggs that it finds.

Here’s an example of code that handles regular DetectLabels requests.

response = rekognition.detect_labels(
    Image={"Bytes": image_bytes},
    MaxLabels=30,
    MinConfidence=30.0,
)

Generating test images

I needed images with scenes where Easter eggs would be unexpected. I used an image generator to create 19 images: a messy desk with an egg tucked next to the monitor, a toy box with a painted Easter egg between two teddy bears, a picnic spread with a couple eggs in between the sandwiches.

Then I generated 18 images with no eggs at all, but similar to the other scenes. That gave me a relatively balanced dataset to start with.

Round 1: DetectLabels

I wrote a batch test script (also in the GitHub repo) that ran every image I had through DetectLabels and checked whether Rekognition found an egg.

The results at a 30% confidence threshold:

Metric	Score
Accuracy	75.70%
Precision	100%
Recall	52.60%

100% precision means it never hallucinated an egg where there wasn't one in the no-egg images. But 52.6% recall means it missed about half the eggs in the egg images. Imagine you're doing an Easter egg hunt, and there are 19 eggs hidden in the yard. A recall of 52.6% means you only found 10 of them.

At a stricter 70% confidence threshold, recall dropped to 36.8%, so you'd only find about 7 out of 19.

I added logging to see what objects Rekognition detected for the missed eggs. The logged objects were pretty accurate, which told me that Rekognition identified the gist of the images well but couldn't "see" the Easter eggs.

I realized the out-of-the-box API was great for detecting Easter eggs in more typical scenes, like this one.

Script output:

  ✅ 1774389521556_img.png eggs: Egg (99.9%), Easter Egg (99.1%)

DetectLabels had a harder time finding Easter eggs in less obvious scenarios or with more competing objects, like this one.

Script output:

❌ MISS 1774389716587_img.png eggs: none
↳ saw instead: Toy (98.7%), Teddy Bear (93.5%), Lego Set (69.8%), 
   Plush (53.7%), Doll (48.1%), Play Area (48.0%), Handicraft (47.7%), 
   Hedgehog (46.9%)

Round 2: Custom Labels

Custom Labels exist for situations where you need to detect specific objects in specific scenes that go beyond the capabilities of DetectLabels, like my Easter egg images. With Custom Labels, you can train a computer vision model on your own images. The model can learn to spot what you care about, even when the object is small, partially hidden, or surrounded by lots of visual noise. The benefit here is that rather than training a computer vision model from scratch on tens of thousands of images, you can build on existing capabilities by just uploading a relatively small set of training images. Then, Rekognition handles the model training and evaluation process for you.

I did this all directly in the Amazon Rekognition console, where I created a new project and uploaded my dataset of images. Rekognition automatically split my data 80/20 for training and testing.

I created my custom label of "Easter egg" and drew bounding boxes around the Easter eggs in my dataset images, then hit Train.

Training took around 30 minutes. When it finished, I got a model ARN and performance metrics. Here's how the custom model did on the test dataset compared to the standard DetectLabels API:

Metric	DetectLabels (30% threshold)	Custom Labels
Precision	100%	77.80%
Recall	52.60%	75%
F1 score	(not calculated)	0.764

Recall jumped from 52.6% to 75%. This meant that the custom model was finding eggs that DetectLabels missed entirely. Precision dropped from 100% to 77.8% (more false positives), meaning it occasionally saw an egg where there wasn’t one, but I think that's a reasonable trade-off for catching 22% more of the eggs.

The F1 score is a metric that shows how well the model balances precision and recall, indicating its overall accuracy. A score of 0.764 from a dataset of 37 images is a good starting point.

Going back to the Easter egg hunt analogy, DetectLabels was the careful egg hunter who only picked up real eggs but walked past half of them. The custom label found most of the eggs but also grabbed a few eggish-looking rocks along the way in the test dataset.

Considering the fact that I only had 37 total images in the dataset, these are promising results, but there's definitely room to improve. I'd expect the model's performance to climb if I added more training data. But this experiment was for learning and my own curiosity, and that F1 score worked for me. I plugged my custom model’s ARN into my Streamlit app, and uploaded a few images. The custom model did a pretty good job of detecting Easter eggs on new images that weren’t part of the training dataset.

It also was pretty good about not registering false positives, even with temptingly bright round objects in the image.

Cost

Everything in this project fits comfortably within the AWS Free Tier credits for new accounts. Here are some more details on the pricing for training and inferencing with a custom model in the us-east-1 region:

DetectLabels (Group 2 API)

74 images × $0.001/image = $0.074
- I had 37 images, but I ran the batch analysis script twice (first checking for egg presence, then again to log the labels that were found for false negatives).

Custom Labels training:

0.52 hours × $1/hour = $0.52
- The docs note that Amazon Rekognition may run multiple compute resources in parallel, so actual billed hours can be higher than elapsed time for model training.

Custom Labels inferencing:

1.41 hours x $4/hour = $5.71

If you build this in your own account, be sure to STOP the model when you’re done inferencing to avoid accumulating further charges. In total for this project, I was billed for 85.7 inference minutes and 31 training minutes, which amounted to $6.24. This amount was deducted from my Free Tier credits. (The charges for other services in the following cost breakdown image are related to other Free Tier projects.)

What I learned, and what I'd do differently

The jump from DetectLabels to Custom Labels was the most interesting part of this project for me. With Custom Labels, you get to label your own data, train a model, evaluate its performance, and iterate. That loop (data → train → evaluate → improve) is the same loop behind every ML system. Custom Labels just makes it accessible without needing to have ML experience or having to spin up your own dedicated hardware.

I also came away with a better sense of when to use what. You could send an image to one of the newer multimodal foundation models and ask, "Are there any Easter eggs in this picture?" It would probably give you a very good answer. But for a tightly-scoped detection task like this one, I think a purpose-built service is a better fit. A single API call returns predictable JSON with labels, confidence scores, and bounding box coordinates. No system prompt to write, no natural language to parse. And the whole project cost me $6.24 in Free Tier credits.

A couple things I'd change if I were starting over:

Create more images for the dataset. The docs say that most custom models need a few hundred images or less, but I only had 37. I'd aim for 50+ per class (Easter egg and no Easter egg). I'd also set up a script to generate text for image prompts and call an image generating API to quickly create a bunch of training and test images.
Test with real photos, not just AI-generated ones. Generated images have a certain look to them. Real phone photos with unexpected lighting and odd angles would be a tougher test.

Try it yourself

The full code and installation directions are on GitHub here.

If you want to skip the training and just play with DetectLabels, the standard mode works immediately. Upload a photo of your breakfast and see what happens. 🍳

If you want more ideas for Free Tier projects, let me know in the comments!

AI Agents Don’t Need Complex Workflows. Build One in Python in 10 Minutes

Morgan Willis — Thu, 26 Mar 2026 22:16:10 +0000

Building an AI agent in Python can be as easy as giving a model some tools and letting it figure out the rest.

Most agent setups start the same way: you wire up tool calls, manage retries, track state, and write the routing logic that decides what happens when. It works, but it's brittle. Every time the workflow changes, you're back in the code rewiring the sequence.

Strands is an open-source Python SDK built around a different idea.

Instead of you hardcoding the orchestration, you let the model handle it. You give it tools and a goal, and the SDK takes care of the agent loop, tool execution, and conversation state. You can go from zero to a working agent in about 10 minutes, and the same primitives that make a simple agent easy to build can be combined to give you more complex setups when you need them.

A Model Driven Approach to AI Agents

The Strands team calls this a model-driven approach. The LLM is the orchestrator and you define the capabilities it can use.

In practice, your agent code is mostly plugging in the different desired components. Here's what a basic agent looks like:

from strands import Agent

agent = Agent(system_prompt="You are a helpful assistant.")
response = agent("What's the capital of France?")
print(response)

That's a working agent. It uses Amazon Bedrock as the model provider by default, but you can swap in any supported provider. We'll use OpenAI for the rest of this post.

Setting Up a Python AI Agent with OpenAI

Install the SDK with the OpenAI extension:

pip install 'strands-agents[openai]' strands-agents-tools

Set your API key:

export OPENAI_API_KEY=your_api_key_here

Now create an agent that uses OpenAI:

import os
from strands import Agent
from strands.models.openai import OpenAIModel

model = OpenAIModel(
    client_args={"api_key": os.environ["OPENAI_API_KEY"]},
    model_id="gpt-4o",
)

agent = Agent(
    model=model,
    system_prompt="You are a helpful assistant.",
)

response = agent("What's the capital of France?")
print(response)

Run it with python agent.py and you should get a response. The agent handles the API call to the OpenAI model and response parsing for you.

So far, this doesn't have any tools it can use to interact with the real world. It does however have a main agent loop handled, and is the starting point from which you will build a more capable agent.

The Building Blocks of an AI Agent

Strands has a couple of main building blocks you should be aware of: agents, tools, models, and hooks. Understanding how they fit together is most of what you need to know.

Models

A model is the LLM provider. Strands supports Bedrock (the default), OpenAI, Anthropic, Google Gemini, Meta Llama, Ollama for local models, and several others. You configure the model once and pass it to your agent.

model = OpenAIModel(
    client_args={"api_key": os.environ["OPENAI_API_KEY"]},
    model_id="gpt-4o",
    params={"temperature": 0.3},
)

You can set inference parameters using params. One good one to note is temperature. Use a lower temperature for factual tasks or a higher temperature for creative ones. Other supported inference parameters depend on the model.

Giving Your Agent Tools

Tools are Python functions that extend what the agent can do beyond generating text.

Here's a custom tool to return weather data:

from strands import tool

@tool
def get_weather(location: str) -> str:
    """Get the current weather for a location.

    Args:
        location: City name, e.g. "Seattle"
    """
    # In a real app, this would call a weather API
    return f"Weather in {location}: Sunny, 72°F"

The @tool decorator is all you need. The docstring matters because the model uses it along with the function's type hints to decide when to call this function and what arguments to pass. Clear docstrings lead to better tool usage.

Strands also ships with a community tools package that includes common utilities:

from strands_tools import calculator, python_repl, http_request

These give your agent the ability to do math, run Python code, and make HTTP requests out of the box.

Wiring It All Together

The agent brings everything together. You give it a model, tools, and a system prompt:

agent = Agent(
    model=model,
    tools=[get_weather, calculator],
    system_prompt="You are a helpful assistant that can check weather and do math.",
)

When you call the agent with a message, it enters an agent loop. The model reads the message, decides if it needs to use any tools, calls them if it does, reads the results, and either calls more tools or generates a final response. This loop continues until the model decides it has enough information to answer.

You don't write any of that loop logic, the SDK handles it for you.

Hooking into the Agent Lifecycle

Hooks let you subscribe to lifecycle events in the agent loop without modifying the agent's core logic. The agent emits events at specific points during execution: before and after model calls, before and after tool calls, when messages are added, and at the start and end of each invocation. You register callbacks for the events you care about.

Here's a hook that logs every tool call:

from strands.hooks import BeforeToolCallEvent, AfterToolCallEvent

def log_tool_call(event: BeforeToolCallEvent):
    print(f"Calling tool: {event.tool_use['name']}")
    print(f"With input: {event.tool_use['input']}")

def log_tool_result(event: AfterToolCallEvent):
    print(f"Tool {event.tool_use['name']} completed")

agent = Agent(
    model=model,
    tools=[get_weather, calculator],
    system_prompt="You are a helpful assistant.",
)

agent.add_hook(log_tool_call, BeforeToolCallEvent)
agent.add_hook(log_tool_result, AfterToolCallEvent)

The available events cover the full lifecycle:

BeforeInvocationEvent / AfterInvocationEvent for the overall request
BeforeModelCallEvent / AfterModelCallEvent for LLM calls
BeforeToolCallEvent / AfterToolCallEvent for tool execution
MessageAddedEvent when messages are added to conversation history

Hooks are useful for logging, metrics, basic guardrails, and adding logic to your agents lifecycle. You can also cancel a tool call from a BeforeToolCallEvent hook by setting event.cancel_tool to a message, which stops the tool from executing and sends that message back to the model as an error. For example, you can check the tool name and arguments, and block it if something looks wrong.

Once you start building more complex agents, you'll find yourself wanting to bundle related hooks and tools into reusable packages. We'll get to that later in this post.

Building a Multi-Tool Agent

Here's a more complete example. This agent has a few tools as examples to do things like look up weather, do calculations, and count letters in words. The actual tools themselves don't matter much for learning how to build an agent, as those will be unique to your specific use case. For now, we are just exploring how to wire all of the pieces together into an agent that does things:

import os
from strands import Agent, tool
from strands.models.openai import OpenAIModel
from strands_tools import calculator

@tool
def get_weather(location: str) -> str:
    """Get the current weather for a location.

    Args:
        location: City name, e.g. "Seattle"
    """
    return f"Weather in {location}: Sunny, 72°F"

@tool
def letter_counter(word: str, letter: str) -> int:
    """Count occurrences of a specific letter in a word.

    Args:
        word: The word to search in
        letter: The single letter to count
    """
    return word.lower().count(letter.lower())

model = OpenAIModel(
    client_args={"api_key": os.environ["OPENAI_API_KEY"]},
    model_id="gpt-4o",
)

agent = Agent(
    model=model,
    tools=[get_weather, calculator, letter_counter],
    system_prompt="You are a helpful assistant.",
)

response = agent("""I have a few questions:
1. What's the weather in Seattle?
2. What is 1547 * 382?
3. How many r's are in "strawberry"?
""")
print(response)

The agent will call each tool as needed, collect the results, and give you a single coherent response. You didn't have to write any routing logic or decide which tool to call for which question. The model handles that.

How AI Agents Remember Conversations

Agents maintain conversation context automatically within a running process. Each call to the agent adds to the conversation history, so the model remembers what was said earlier:

agent("My name is Morgan.")
response = agent("What's my name?")
print(response)  # Will remember "Morgan"

This works across multiple turns without any extra code because the SDK manages the message history internally.

That said, this memory only lives as long as the agent's process lives. If you're running a script locally and it exits, the history is gone. If you're hosting an agent behind an API, the process restarts with every request so message history is not maintained.

This is because LLMs are stateless by default, and the conversation history that makes them feel stateful is just a list of messages that gets sent with every request.

For anything beyond a local script, you need to persist that history somewhere.

Session Managers

Strands provides session managers that save and restore conversation state across invocations. The simplest option is FileSessionManager, which writes session data to the local filesystem:

from strands import Agent
from strands.session.file_session_manager import FileSessionManager

session_manager = FileSessionManager(
    session_id="my-session",
    storage_dir="./sessions",
)

agent = Agent(
    model=model,
    system_prompt="You are a helpful assistant.",
    session_manager=session_manager,
)

# First run
agent("My name is Morgan.")

# Later, even after a restart, the agent remembers
agent = Agent(
    model=model,
    system_prompt="You are a helpful assistant.",
    session_manager=FileSessionManager(
        session_id="my-session",
        storage_dir="./sessions",
    ),
)
response = agent("What's my name?")
print(response)  # Still remembers "Morgan"

FileSessionManager stores each message as a JSON file on disk. It works well for local development. For hosted setups, you'd swap in a session manager backed by a database or a managed memory service like Amazon Bedrock AgentCore Memory. The integration pattern is the same, but you'd need to provision the infrastructure for the data store.

Managing the Context Window

There's another problem that shows up in longer conversations. Every LLM has a context window, which is the maximum amount of tokens it can process in a single request. Your system prompt, the full conversation history, tool definitions, and the model's response all have to fit inside that window.

For short conversations this isn't an issue. But if your agent runs for dozens of turns, or if tools return large results, the conversation history can grow past what the model can handle.

Strands provides a few out of the box conversation managers to deal with this:

The sliding window manager keeps the most recent messages and drops the oldest ones when the history gets too long:

from strands import Agent
from strands.agent.conversation_manager.sliding_window_conversation_manager import SlidingWindowConversationManager

agent = Agent(
    model=model,
    conversation_manager=SlidingWindowConversationManager(
        window_size=40,  # keep the last 40 messages
    ),
)

This is simple and predictable: old messages fall off the end. The downside is that the agent loses context from earlier in the conversation. If a user said something important 50 messages ago, it's gone.

The summarizing manager takes a different approach. Instead of dropping old messages, it summarizes them and then keeps the summary:

from strands import Agent
from strands.agent.conversation_manager.summarizing_conversation_manager import SummarizingConversationManager

agent = Agent(
    model=model,
    conversation_manager=SummarizingConversationManager(
        summary_ratio=0.3,  # summarize the oldest 30% of messages
        preserve_recent_messages=10,  # always keep the last 10
    ),
)

When the context gets too large, the summarizing manager takes the context and generates a summary using the LLM. It then replaces those messages with the summary. The agent keeps the gist of what happened earlier without the full verbatim history. This costs an extra model call when summarization triggers, but it preserves more context than a simple sliding window.

Which one you pick depends on your use case. For short, focused interactions, the sliding window is fine. For longer sessions where earlier context matters, the summarizing manager is worth the extra cost.

There are also more advanced techniques you can use to manage your context window. Figuring out all the ways to manage context is called context engineering, and is an entire discipline in the AI engineering world. For simple agents, sliding window or summarization are good places to start.

How the Agent Loop Ties It All Together

Stack these pieces together and you get a pretty capable agent without writing much code. A model handles reasoning and tool selection.

Tools extend what the agent can do.
Hooks give you control over the lifecycle.
Session managers persist state across restarts.
Conversation managers keep the context window under control.

The agent loop ties it all together: the model calls tools, reads results, handles errors by trying a different approach, and returns the final response.

This is the starting point. Once you start building more advanced agents you'll need more capabilities. That's where plugins come in.

Plugins are classes that bundle hooks and tools together into behavioral modifications you can attach to any agent. The SDK ships with a few built-in plugins that show what this looks like in practice, and you can build your own custom plugins as needed.

Extending Your Agent with Plugins

Steering

Steering is a plugin that evaluates the agent's output and sends corrective feedback when the response drifts from your guidelines. You give it a system prompt that defines the rules, and it uses a separate LLM call to judge each response before it reaches the user.

from strands import Agent
from strands.vended_plugins.steering import LLMSteeringHandler

agent = Agent(
    model=model,
    tools=[get_weather, calculator],
    plugins=[
        LLMSteeringHandler(
            system_prompt="Ensure all responses are professional and concise. "
            "Reject any response that includes speculation or unverified claims."
        ),
    ],
)

Under the hood, the steering plugin hooks into the agent's lifecycle using a BeforeToolCallEvent hook. It intercepts tool calls, runs them through the evaluator, and returns one of three actions: proceed (let it through), guide (reject with feedback so the agent retries), or interrupt (escalate to a human). You don't write any of that logic. You just describe the rules in the system prompt for the steering handler.

This is useful for enforcing tone in customer-facing agents, preventing agents from calling tools with dangerous arguments, or evaluating if agents are following directions.

Skills

Skills are modular instructions that agents discover and activate at runtime. They follow the Agent Skills specification, an open standard for packaging agent capabilities as folders containing instructions, scripts, and resources.

A skill might teach an agent how to perform a code review following your team's conventions, how to deploy to a specific environment, or how to write content in a particular style.

The agent only loads a skill's metadata (name and description) initially. When the agent decides a skill is relevant to the current task, it activates it and pulls in the full instructions. This keeps the context window clean since the agent only loads what it needs.

Building Your Own Plugins

You can also build custom plugins. A plugin is a class that extends Plugin and uses @hook and @tool decorators:

from strands import Agent, tool
from strands.plugins import Plugin, hook
from strands.hooks import BeforeToolCallEvent, AfterToolCallEvent

class LoggingPlugin(Plugin):
    """A plugin that logs all tool calls and provides a utility tool."""

    name = "logging-plugin"

    @hook
    def log_before_tool(self, event: BeforeToolCallEvent) -> None:
        """Called before each tool execution."""
        print(f"[LOG] Calling tool: {event.tool_use['name']}")
        print(f"[LOG] Input: {event.tool_use['input']}")

    @hook
    def log_after_tool(self, event: AfterToolCallEvent) -> None:
        """Called after each tool execution."""
        print(f"[LOG] Tool completed: {event.tool_use['name']}")

    @tool
    def debug_print(self, message: str) -> str:
        """Print a debug message.

        Args:
            message: The message to print
        """
        print(f"[DEBUG] {message}")
        return f"Printed: {message}"

# Using the plugin
agent = Agent(plugins=[LoggingPlugin()])
agent("Calculate 2 + 2 and print the result")

When the agent initializes, it scans the plugin for @hook and @tool methods and registers them automatically. You can stack multiple plugins on the same agent, and each one manages its own hooks and state without interfering with the others.

Beyond plugins, Strands supports multi-agent patterns where agents invoke other agents as tools, MCP (Model Context Protocol) servers for connecting to external tool providers, and structured output for getting typed responses. These are all topics for another post. The point is that the same primitives (agents, tools, models, hooks) compose into more complex setups without requiring you to learn a different API.

Install and Build Your First AI Agent

The fastest path from here:

Install: pip install 'strands-agents[openai]' strands-agents-tools
Set your API key: export OPENAI_API_KEY=your_key
Write a simple agent with one custom tool
Run it and see what happens

The Strands documentation has more examples, including multi-agent setups, observability, and production deployment patterns. The GitHub repo has the source and community tools.

The SDK is open source and actively developed. If you've been putting off building an agent because the frameworks felt heavy, give Strands a look. The barrier to entry is low, and it provides enough composability to keep up with you as your use case gets more complex.

JavaScript e SDK: Como sua aplicação web pode falar com a nuvem

Giovana Armani — Thu, 26 Mar 2026 19:29:54 +0000

Em artigos passados, falei sobre o que é SDK e por que ele é importante e construímos uma aplicação back-end para conversão de documentos usando o SDK da AWS. Vamos usar o SDK mais uma vez, mas agora para construir nosso front-end!

O que é SDK mesmo?

Podemos pensar SDK (Software Development Kit) como uma caixa de ferramentas para construir aplicações sobre uma plataforma, sistema operacional ou linguagem de programação. Ele pode incluir bibliotecas, APIs, documentação, exemplos de código, debuggers, entre outras coisas. Caso queira saber mais sobre SDK e sua diferença para APIs e bibliotecas, veja esse artigo.

O SDK da AWS para JavaScript permite fácil acesso a serviços da AWS a partir de seu código JS. Você verá como com algumas importações e comandos rápidos podemos conversar diretamente com a nuvem!

Tudo que construiremos nesse tutorial, assim como o tutorial do back-end, pode ser reproduzido com uma conta Free Tier da AWS. Com ela, você ganha 100 dólares em créditos na conta e pode ganhar até 100 dólares adicionais ao explorar os diferentes serviços da AWS e não será cobrado a não ser que explicitamente escolha trocar de plano. Se quiser saber mais sobre como criar sua conta e as melhores configurações de segurança, veja esse artigo.

O que vamos construir

No nosso backend, temos uma função Lambda que converte arquivos CSV para JSON. Ela é acionada quando colocamos um arquivo no bucket S3 de input e coloca os arquivos convertidos em um outro bucket do S3 de output. Como queremos fazer o front-end para essa aplicação, vamos construir uma tela que rodará no navegador. Ela será dividida em duas partes: uma seção para fazer o upload de arquivos CSV e outra para o download dos arquivos JSON.

Primeiros passos: rodando a página web

Para esse projeto, vamos usar React, uma biblioteca do JavaScript para criação de interfaces. Para isso, é preciso ter o node.js. Caso não tenha node na sua máquina, comece baixando no site oficial. Selecione "Get Node.js" para baixar.

Nesse repositório você encontrará o código completo do front-end na pasta "front", assim como o back-end que já construímos. Para começar a reproduzir a aplicação, clone ele para editar o código. Siga os passos:

Crie uma pasta no seu computador para o projeto
No terminal, navegue até a pasta criada através do comando cd <caminho-ate-a-pasta>
Clone o repositório com o comando git clone https://github.com/gi-armani/CSV-JSON-Converter-sample-for-aws-SDK
Para rodar a aplicação, navegue até a raiz do projeto com o comando cd <caminho-ate-a-pasta-criada>/CSV-JSON-Converter-sample-for-aws-SDK/front
Execute npm install para instalar as dependências e npm start para iniciar

Você deverá ver uma mensagem parecida com a mensagem abaixo:

Agora você pode abrir http://localhost:3000/ no seu navegador de preferência e ver os elementos visuais da aplicação. Lembre-se que ela ainda não está conectada na nuvem, mas vamos cuidar disso!

Entendendo a estrutura da página

Quando iniciamos um projeto React, o principal arquivo da aplicação estará localizado em CSV-JSON-Converter-sample-for-aws-SDK/front/src/App.js que contém a seguinte estrutura:

// importação de bibliotecas, imagens e outros elementos
import logo from './logo.svg';
import './App.css';

function App() {
  // Aqui colocamos a lógica (variáveis e funções que precisaremos usar)

  return (
    // Aqui estarão os diferentes elementos do site, declarados em componentes similares ao html
  );
}

export default App;

O trecho de código acima tem indicativos de onde estarão os nossos elementos visuais (textos, inputs, botões, etc) e onde estará a lógica dos processos. Veja que no código que você clonou tudo isso já está criado, mas ainda vamos precisar substituir algumas constantes para conectar com a nuvem.

Configurando permissões

Pausando um pouco no código e indo para a conexão com a nuvem, precisamos configurar permissões para nosso código conseguir acessar os arquivos. Agora vamos conectar o front-end com o back-end que criamos anteriormente. Caso você não tenha os buckets do S3 e a função Lambda na sua conta, recomendo criá-los primeiro usando as instruções do artigo anterior.

Para isso, vamos usar o IAM (AWS Identity and Access Management). Esse é um serviço da AWS que permite controlar acesso a permissões dentro da sua conta. Se quiser entender mais sobre como funciona o IAM e os diferentes tipos de permissão, veja esse artigo.

Na minha conta AWS, estou na região de us-west-2 (Estados Unidos Oregon). É importante criar todos os seus recursos na mesma região para evitar problemas de comunicação entre eles. Você pode identificar a região que você está a qualquer momento no menu superior da conta ao lado do nome e número da conta.

Criando a política de acesso ao S3

Vamos começar criando a política de acesso, ou seja, o documento que diz o que é permitido fazer e onde.

No console da AWS da sua conta Free Tier, navegue até a página do IAM e selecione "Políticas" no menu da esquerda
Clique em "Criar política"
No canto superior direito do editor de políticas, selecione a opção JSON e cole o conteúdo abaixo. Não se esqueça de substituir os locais indicados em "Resource" com os nomes dos seus buckets

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowWriteInput",
            "Effect": "Allow",
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::<NOME-DO-SEU-BUCKET-DE-INPUT>/*"
        },
        {
            "Sid": "AllowReadOutput",
            "Effect": "Allow",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::<NOME-DO-SEU-BUCKET-DE-OUTPUT>/*"
        },
    {
      "Sid": "AllowListOutput",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::gio-csv-converter-output"
    }
    ]
}

Aqui temos uma política que permite subir arquivos no bucket de input (operação PutObject) e ler arquivos do bucket de output (operação GetObject). Temos também uma última permissão que permite listar os objetos de um bucket (operação ListBucket). Essa última é importante porque caso a conversão do json ainda não tenha sido terminada, fará com que o S3 retorne um erro mais amigável dizendo que o arquivo ainda não existe. Sem essa permissão, o S3 retornaria um erro de acesso negado.

Na opção "Visual" do editor de políticas, é possível construir essa mesma política de forma interativa selecionando os serviços e as operações que serão usadas (deixo para a curiosidade de quem quiser explorar 😉).

Para terminar a criação, basta selecionar "Próximo", dar um nome à sua política na próxima página (chamei a minha de "jsWebClientS3Access") e então selecionar "Criar política" no canto inferior direito.

Criando um identity pool

Para essa parte, vamos usar o Amazon Cognito, um serviço da AWS de autenticação para aplicações. Ele nos ajuda a identificar quem é o usuário que está acessando nossa aplicação e gerar credenciais de acesso que são atualizadas automaticamente.

Os Identity pools (ou grupos de identidade) são diretórios de identidades que podem ser usados para obter credenciais para acessar outros serviços da AWS através do nosso front-end. Para criá-lo, siga os passos abaixo:

Na sua conta Free Tier, navegue até o Amazon Cognito
Selecione "Grupos de identidades" no menu esquerdo e em seguida "Criar grupo de identidades" no botão laranja à direita
Na página de criação, selecione "Acesso de convidado". Isso permitirá que nosso código front-end acesse os recursos que queremos sem precisar de um login. Clique em "Próxima" para continuar
Em seguida, vamos criar um perfil do IAM que usaremos para declarar as permissões. Selecione "Criar um novo perfil do IAM" e dê um nome a ele. Chamei o meu de "jsWebClientRole". Clique em "Próxima" para continuar
Dê um nome ao grupo de identidades. Chamei o meu de "jsWebClientIdentity". Clique em "Próxima" para continuar
Revise os detalhes do grupo de identidade que estamos criando e selecione "Criar grupo de identidades" para concluir.

De volta na página dos Grupos de identidade do Amazon Cognito, você verá seu grupo de identidade criado. Salve o ID dele pois será usado logo mais para autenticação no código.

Por último, precisamos ligar a política de acesso que criamos na seção anterior ao grupo de identidade:

Navegue até o console de IAM
No menu esquerdo, selecione "Funções"
Busque pelo perfil que criamos junto ao Grupo de identidade. O meu é o "jsWebClientRole"
Na aba de "Permissões", selecione "Adicionar permissões" e "Anexar políticas"
Busque pela política de acesso ao S3 que criamos anteriormente e clique em "Adicionar permissão"

Configurando CORS

Um conceito clássico que vemos quando integramos aplicações, como integração entre front e back-end, é CORS. CORS significa Cross-Origin Resource Sharing, ou compartilhamento de recursos entre origens, e é um mecanismo para compartilhar conteúdo entre diferentes domínios de forma segura. Com ele, declaramos o que pode ser compartilhado e quais domínios podem enviar conteúdo. Precisamos configurar CORS para o bucket de input e de output.

No console da AWS, navegue até a página do S3
Selecione o nome do bucket de input que criamos no último tutorial quando construímos o back-end
Clique em "Permissões" e desça até o final da página onde encontrará "Compartilhamento de recursos de origem cruzada (CORS)"
Clique em editar e cole o conteúdo abaixo:

[
    {
        "AllowedHeaders": [
            "*"
        ],
        "AllowedMethods": [
            "GET",
            "PUT"
        ],
        "AllowedOrigins": [
            "http://localhost:3000"
        ],
        "ExposeHeaders": [
            "ETag"
        ]
    }
]

⚠️ Note que adicionamos especificamente o localhost na porta 3000 em "AllowedOrigins" o que significa que o bucket aceitará receber recursos apenas desse domínio. A melhor prática de segurança é sempre restringir acesso para o mínimo necessário. Para um site que estivesse deployado na internet, adicionaríamos o domínio específico da aplicação que faz o envio.

Repita os mesmos passos para habilitar CORS no bucket de output.

Conectando tudo: chamando o SDK da AWS

Agora que temos as permissões configuradas na conta AWS, vamos fazer a conexão com o S3 no código.

No começo do arquivo App.js do repositório clonado, você encontrará o seguinte trecho:

const REGION = 'us-west-2';
const IDENTITY_POOL_ID = '';

const clienteS3 = new S3Client({
  region: REGION,
  credentials: fromCognitoIdentityPool({
    clientConfig: { region: REGION }, 
    identityPoolId: IDENTITY_POOL_ID
  })
});

O IdentityPoolId usado para criar o clienteS3 será o ID do Grupo de Identidades que criamos com Amazon Cognito. Preencha esse valor na constante IDENTITY_POOL_ID. Note que a constante REGION, que indica a região, está declarada como us-west-2. Caso seus recursos estejam em outra região da AWS, mude essa constante para a região correspondente.

⚠️ Essa é a forma recomendada pela AWS para obter credenciais para o navegador. Muito cuidado com expor suas credenciais abertamente, jamais publique elas na internet!

Por fim, preencha as constantes que representam os buckets de input e output com os nomes dos seus buckets:

const BUCKET_ENTRADA = '';
const BUCKET_SAIDA = '';

Pronto! Se seu back-end também estiver configurado, você terá um sistema completo incluindo front e back-end que utiliza o SDK da AWS para comunicação com os serviços em nuvem. Você pode usar esse csv de exemplo para testar a aplicação.

Conclusão

Agora você já sabe como construir uma aplicação front-end que se comunica diretamente com serviços da AWS. Nesse tutorial, você aprendeu a:

Instalar e usar o AWS SDK para JavaScript para interagir com o S3
Configurar permissões no IAM para que sua aplicação acesse serviços da AWS de forma segura
Configurar CORS para permitir a comunicação entre seu front-end e a nuvem

Reproduza esse tutorial na sua máquina e dê seu próprio estilo ao design da página. Experimente trocar cores, fontes e layout, deixe com a sua carinha. Com o front-end e o back-end que construímos no artigo anterior, você tem uma aplicação serverless completa funcionando na AWS!

Escala Inteligente con Microservicios Serverless

Hazel Saenz — Tue, 24 Mar 2026 17:57:16 +0000

Cuándo dividir, cómo conectar y qué patrones usar para no crear un monolito distribuido.

Hace un tiempo me tocó trabajar en un proyecto donde todo funcionaba. Un monolito. Un deploy, un repo, un equipo. Respondía rápido, los usuarios estaban contentos, el jefe estaba contento.

Hasta que alguien en una conferencia dijo: "los microservicios son el futuro".

Y miramos nuestro monolito y pensamos: "esto no escala, necesitamos microservicios".

Tres meses después teníamos 15 servicios. Un request del usuario pasaba por 7 de ellos antes de responder. Si inventario iba lento, el checkout se caía. Si notificaciones fallaba, nadie sabía por qué el pedido se quedó a medias.

Teníamos un monolito distribuido. Los mismos problemas de antes, pero ahora con latencia de red y 12 dashboards que nadie entendía.

La complejidad no desapareció. Solo cambió de forma.

Si alguna vez sentiste que migrar a microservicios iba a resolver todos tus problemas y terminó creando nuevos... este artículo es para ti.

¿Realmente necesitas microservicios?

Antes de hablar de cómo, hablemos de cuándo. Porque la decisión más inteligente a veces es no dividir.

Cuando empecé a investigar más sobre el tema, me di cuenta de que muchas migraciones a microservicios no nacen de un problema real. Nacen del hype. De escuchar que "Netflix usa microservicios" y asumir que nosotros también deberíamos.

Pero Netflix llegó a microservicios después de años de crecimiento y con miles de ingenieros dedicados a esa transición. El contexto importa: lo que funciona para una empresa con esa escala no necesariamente aplica para todos los equipos.

Señales reales vs. falsas alarmas

✅ Señales reales para dividir	❌ Falsas alarmas
Equipos se bloquean entre sí para hacer deploy	"Netflix usa microservicios"
Un componente necesita escalar 100x más que el resto	"Mi monolito es legacy"
Dominios de negocio claramente independientes	"Quiero usar tecnologías diferentes por servicio"
Ciclos de release muy diferentes entre componentes	"Los microservicios son más modernos"
Un fallo en un módulo tumba todo el sistema	"Mi equipo de 3 personas necesita agilidad"

Si tu equipo es pequeño y todo cabe en un deploy, no necesitas microservicios. Necesitas un monolito bien estructurado.

Divide cuando el dolor es real: equipos que se bloquean, componentes que necesitan escalar de forma radicalmente diferente, dominios de negocio que evolucionan a ritmos distintos.

No dividas porque suena moderno.

No es binario — hay un espectro

Algo que me costó entender al principio es que no es "monolito o microservicios". Hay un espectro completo entre ambos:

La mayoría de los sistemas no necesitan ir directo a microservicios.

Empieza con un monolito modular: un solo deploy, pero con límites claros entre dominios. Cuando un módulo necesite escalar o evolucionar independientemente, lo extraes.

Eso es escalar inteligente: dividir cuando hay evidencia, no cuando hay hype.

Serverless cambia las reglas

Cuando trabajas con microservicios tradicionales, cada servicio necesita su servidor, su scaling, su service discovery. Es mucha carga operativa.

Serverless cambia eso por completo:

Microservicios Tradicionales	Microservicios Serverless
Tú manejas servidores por servicio	Sin servidores que gestionar
Tú configuras auto-scaling	Escala automática por función
Pagas por servidor encendido	Pagas por ejecución
Tú manejas service discovery	Eventos y colas conectan servicios
Kubernetes, Docker, load balancers	Lambda, API Gateway, EventBridge

Pero hay algo que quiero dejar claro porque es una confusión muy común:

Un microservicio serverless no es UNA Lambda.

Es la colección de Lambdas detrás de un API Gateway que resuelven un dominio de negocio. Pedidos, inventario, pagos, cada uno es un microservicio compuesto por varias funciones pequeñas y enfocadas.

Si metes toda la lógica en una sola Lambda gigante, estás creando un monolito dentro de una función.

La pregunta ya no es "cómo escalo este servicio" sino "cómo conecto estos servicios de forma inteligente".

Y ahí es donde entran los patrones.

Los 3 patrones clave

Después de haber pasado por varias migraciones (algunas exitosas, otras no tanto), identifiqué tres patrones que marcan la diferencia entre una arquitectura de microservicios que funciona y un monolito distribuido disfrazado.

Los presento aquí a nivel conceptual. Cada uno tendrá su artículo dedicado con implementación práctica y código real.

Patrón 1: Comunicación desacoplada — eventos, no llamadas directas

Este fue el error que más me costó entender.

Cuando empezamos a dividir servicios, lo primero que hicimos fue conectar Lambdas en cadena. Lambda A llama a B, B llama a C. Parecía lógico.

El problema:

Si C falla, todo falla. Las latencias se suman. Estás recreando el monolito pero con más latencia.

El patrón correcto es usar eventos asíncronos:

Tu microservicio responde al usuario y emite un evento. Los demás microservicios reaccionan al evento a su propio ritmo.

Desacoplados. Independientes. Resilientes.

Amazon EventBridge actúa como un bus de eventos serverless que desacopla la lógica de enrutamiento de tus microservicios. Amazon SQS te da colas de mensajes para procesamiento asíncrono con garantías de entrega. Ambos son piezas fundamentales para este patrón.

En el próximo artículo de la serie vamos a implementar este patrón paso a paso con EventBridge y SQS, incluyendo las trampas que te puedes encontrar.

Patrón 2: Cada servicio, su data

Este es directo y no tiene vuelta:

Si todos tus servicios leen y escriben en la misma tabla de DynamoDB, no tienes microservicios. Tienes un monolito disfrazado.

El patrón correcto:

Cada servicio es dueño de su data. Si otro servicio necesita esa información, la pide por evento o por API.

Nunca por query directo a la base de datos ajena.

¿Por qué? Porque si compartes la base de datos, cualquier cambio de schema puede romper múltiples servicios al mismo tiempo. Y ahí se fue tu independencia.

Esto se conoce como database per service y suena simple, pero tiene implicaciones importantes, como qué pasa cuando una transacción involucra múltiples servicios (spoiler: necesitas el patrón Saga).

En el tercer artículo de la serie vamos a profundizar en este patrón y en cómo manejar transacciones distribuidas con Sagas.

Patrón 3: Observabilidad desde el día 1

En un monolito, un error aparece en un log. En microservicios, un error puede estar en cualquiera de 10 servicios.

Sin observabilidad, estás debuggeando a ciegas. Y te lo digo por experiencia: no hay nada más frustrante que saber que algo falló y no poder encontrar dónde.

Los tres pilares que necesitas desde el día 1:

1. Logs estructurados con correlation ID

Nota importante: Cada request que entra a tu sistema debe llevar un ID único que viaje por todos los servicios. Cuando algo falla, buscas ese ID y ves el camino completo.

Lambda Powertools te lo da casi gratis, inyecta correlation IDs, estructura tus logs en JSON y agrega contexto automáticamente.

2. Traces distribuidos

AWS X-Ray y AWS Distro for OpenTelemetry (ADOT) te permiten ver el viaje completo de cada request a través de todos los servicios. Puedes identificar exactamente dónde está el bottleneck.

Nota importante: AWS está convergiendo hacia OpenTelemetry como estándar de instrumentación. ADOT te da una distribución optimizada para AWS que envía traces y métricas a X-Ray, CloudWatch y otros destinos.

3. Métricas de negocio

No solo "cuántos errores 500" sino "cuántos pedidos se perdieron por minuto". Las métricas técnicas te dicen que algo falló. Las métricas de negocio te dicen cuánto te costó.

Si no puedes ver qué pasa, no puedes arreglar lo que falla. En el cuarto artículo de la serie vamos a implementar observabilidad completa con Lambda Powertools, X-Ray y métricas custom.

El framework de decisión

Después de todo lo que vimos, quiero dejarte algo práctico. Un framework que puedes usar la próxima vez que alguien diga "necesitamos microservicios":

No empieces por la tecnología. Empieza por las preguntas.

Si la respuesta a todo es no, quédate con tu monolito. Si es sí, extrae con estrategia.

Lo que quiero que te lleves

🧠 Decide con evidencia, no con hype: Microservicios no son el default. Son una herramienta para problemas específicos.
📐 Empieza modular, extrae después: Monolito modular → macro-servicios → microservicios. En ese orden.
🔌 Eventos sobre llamadas directas: Desacopla con EventBridge/SQS. Nunca encadenes Lambdas síncronamente.
🗄️ Cada servicio, su data: Base de datos compartida = monolito disfrazado.
👀 Observabilidad no es opcional: Correlation IDs, X-Ray/OpenTelemetry, métricas de negocio. Desde el día 1.

Qué sigue

Este artículo es el mapa conceptual. Los siguientes artículos de la serie van a profundizar en cada patrón con implementación práctica y código real:

Comunicación desacoplada con EventBridge y SQS: Implementación paso a paso, trampas comunes y demo funcional
Database per service y el patrón Saga: Cómo manejar transacciones distribuidas con acciones compensatorias
Observabilidad en microservicios serverless: Lambda Powertools, X-Ray/OpenTelemetry y métricas de negocio en acción

"Escalar inteligente no es tener más servicios. Es tomar mejores decisiones."

Recursos

Si quieres profundizar más, estos son los recursos oficiales de AWS que recomiendo:

Implementing Microservices on AWS — Whitepaper completo sobre patrones API-driven, event-driven y data streaming
Microservices on Serverless Technologies — Arquitecturas serverless con Lambda, API Gateway y Fargate
Integrating Microservices by Using AWS Serverless Services — Guía prescriptiva sobre comunicación síncrona y asíncrona entre microservicios
Cloud Design Patterns, Architectures, and Implementations — Patrones como Saga, circuit breaker, event sourcing y strangler fig aplicados con servicios AWS

¿Te resultó útil este artículo? Compártelo con tu equipo. Y si ya pasaste por una migración a microservicios exitosa o no me encantaría escuchar tu experiencia.

AI Agents Are Your API's Biggest Consumer. Do They Care About Good Design?

Morgan Willis — Tue, 24 Mar 2026 13:50:14 +0000

We've always designed APIs for humans. A well built API means obsessing over naming conventions, RESTful patterns, and clear documentation because the goal is simple: make systems easy for developers to understand. But AI is changing who the consumer of software is, and developers are asking whether the rules we've followed for decades still hold up.

When the primary user of an API is an AI system that reads documentation, adapts to unfamiliar patterns, and experiments when something fails, maybe consistent APIs and clean abstractions don't matter anymore.

Everything in me wants to reject this concept. My gut instinct is to say "my APIs need to be pretty or I'll die".

I've been thinking about this a lot lately, and unfortunately I think good arguments are made from both angles on this. Let's walk through both sides.

The Case for "Abstractions Don't Matter Anymore"

Some developers believe AI will reduce the importance of traditional abstractions. I've heard this take a lot.

LLMs are extremely good at pattern recognition. They can read documentation, inspect responses, experiment, and adapt when things fail. From this perspective, messy systems don't seem like a big problem. A human might struggle with inconsistent naming or poor documentation, but an AI can simply figure it out through trial, error, and being smarter than me.

So maybe if abstractions exist to make code understandable to humans, and the primary consumer is no longer human, then the old rules don't apply.

In practice, you can build agent systems that work around poorly designed APIs. Say you're integrating with an API where half the endpoints return errors as HTTP status codes and the other half always return 200 with an error field buried in the response body.

The agent pulls the docs, writes the code, and it looks reasonable. Then it runs the tests and it breaks because the code is checking status codes on an endpoint that never returns them.

The agent reads the error, adds response body parsing, and tries again. Maybe it over-corrects and starts modifying the way it's handling status codes everywhere, breaking a different call. So, it adjusts again. Then finally, the third try works. These systems exist today and they get there eventually.

As models continue to improve, API design will matter less and less as the models can brute force their way to working code.

The Case for "Abstractions Still Matter"

Now for the other side of the argument.

A human developer interacts with an API occasionally. An AI system like a coding agent might interact with it hundreds of times in a single session. When something is poorly designed, the problems compound fast in the form of unnecessary retries, token-heavy debugging loops, and ugly workarounds.

I ran into this with an API that had inconsistent naming across its endpoints. I was debugging an issue with an app I was building, and my coding agent kept thinking it had identified the issue because a parameter name for an API I was using didn't align with historical patterns for this type of API. That wasn't the issue at all, it was completely irrelevant, but the agent kept getting hung up on it.

Every time I debug something that uses this specific API my coding agent always says "I found it! The parameter name should be X instead of Y!" Then it changes it and deploys again and it doesn't work because that wasn't the issue. It kept making the same wrong assumption across sessions.

Unlike a human who hits a weird error and remembers it next time, LLMs are stateless by default. Every new session starts fresh, and agents can spin up tons of sessions in a single workflow. Each of which will run into the same problem.

Every ambiguity in an API has a token cost and poor API design has direct financial consequences in a way that wasn't true when the only cost was developer frustration.

And another thing I've noticed: if you watch a coding agent work through a problem like this, it often gives up and tries a different approach entirely after a few tries. It'll swap libraries, use a different endpoint, or cobble together a workaround using some other approach. That's the AI doing exactly what it should do, adapting.

From the developer perspective, I don't always like the workarounds the AI chooses. Sometimes one unclear API makes my AI think it needs to redesign my entire component. Other times it bypasses the API in a way where it looks like it's working but it's actually relying on some weird hardcoded values somewhere.

And from your perspective of an API owner, the AI just decided not to use your API. Your messy design just cost you a new user.

The Human Compatibility Problem

There's another angle to this too. The abstractions we built for humans are now embedded in how AI systems learn.

Modern software ecosystems contain decades of common coding conventions. These were originally created to help humans understand systems. But those same patterns now appear throughout model training data, and that has consequences.

When you name your endpoint /api/v2/users/{id}, the model has seen that pattern millions of times. It knows what to expect. When you name it /backend/person/fetch?identifier={id}, you're fighting against the weight of its training. The model can learn your pattern, but there's friction.

Coding assistants are increasingly abstracting away the act of writing syntax from developers which is great until you need to peek under the abstraction.

If an agent generates code using unfamiliar patterns or unconventional APIs, a human still has to review it, debug it, and maintain it. We wouldn't want agents writing assembly language even if it ran faster, because most of us can't read it. The same logic applies to API conventions. Familiar patterns keep the code understandable for the humans who still have to live with it.

The patterns we created to help humans are now baked into how AI understands software, and that path dependence matters in both directions. Breaking conventions costs you in AI effectiveness and in human readability.

You Can Engineer Around It (If You Can Afford It)

Writing this blog turned my question from "does API design and thoughtful abstraction matter anymore?" into "how much money do you have?"

Every time an AI system has to figure out how something works, that's tokens being consumed and a potentially hacky workaround making its way into your code base. The adaptability is real, but anyone who's been ripping Claude Opus 4.6 with the 1 million token context window using agent teams knows that this is not free.

You can throw tokens at bad abstractions, build sophisticated systems to work around them, add layers of verification, validation, and correction. Multiple agents checking each other's work. Memory and caching layers to avoid repeated discovery. But wouldn't it be nice to just get it right the first try? Clean abstractions and good API design can give that to you.

Ideally you have both things in place. Clean APIs, meaningful abstractions, and clear documentation means the agent has minimal friction and looping. Then add in enough scaffolding around the agent to recover when an API it's using doesn't have all of those things. That combination reduces the cost of code generation, keeps code human readable and debuggable, and the adaptability is still built in.

Why AI Agents Fail: 3 Failure Modes That Cost You Tokens and Time

Elizabeth Fuentes L — Tue, 24 Mar 2026 02:14:33 +0000

AI agents don't fail like traditional software — they don't crash with a stack trace. They fail silently: returning incomplete answers, freezing on slow APIs, or burning tokens calling the same tool over and over. The agent appears to work, but the output is wrong, late, or expensive.

This series covers the three most common failure modes with research-backed solutions. Each technique has a runnable demo that measures the before/after difference.

Working code: github.com/aws-samples/sample-why-agents-fail

The demos use Strands Agents with OpenAI (GPT-4o-mini). The patterns are framework-agnostic — they apply to LangGraph, AutoGen, CrewAI, or any framework that supports tool calling and lifecycle hooks.

This Series: 3 Essential Fixes

Context Window Overflow — Memory Pointer Pattern for large data
MCP Tools That Never Respond — Async handleId pattern for slow external APIs
AI Agent Reasoning Loops — DebounceHook + clear tool states to block repeated calls

What Happens When Tool Outputs Overflow the Context Window?

Context window overflow occurs when a tool returns more data than the LLM can process — server logs, database results, or file contents that exceed the token limit. The agent does not crash with an error. It silently degrades: truncating data, losing context, or producing incomplete answers.

Research from IBM quantifies this: a Materials Science workflow consumed 20M tokens and failed. The same workflow with memory pointers used 1,234 tokens and succeeded.

The fix — Memory Pointer Pattern: Store large data in agent.state, return a short pointer to the context. The next tool resolves the pointer to access the full data:

from strands import tool, ToolContext

@tool(context=True)
def fetch_application_logs(app_name: str, tool_context: ToolContext, hours: int = 24) -> str:
    """Fetch logs. Stores large data as pointer to avoid context overflow."""
    logs = generate_logs(app_name, hours)  # Could be 200KB+

    if len(str(logs)) > 20_000:
        pointer = f"logs-{app_name}"
        tool_context.agent.state.set(pointer, logs)
        return f"Data stored as pointer '{pointer}'. Use analyze tools to query it."
    return str(logs)

@tool(context=True)
def analyze_error_patterns(data_pointer: str, tool_context: ToolContext) -> str:
    """Analyze errors — resolves pointer from agent.state."""
    data = tool_context.agent.state.get(data_pointer)
    errors = [e for e in data if e["level"] == "ERROR"]
    return f"Found {len(errors)} errors across {len(set(e['service'] for e in errors))} services"

The LLM never sees the 200KB — it only sees "Data stored as pointer 'logs-payment-service'" (52 bytes).

Why Strands Agents? The ToolContext API provides agent.state as a native key-value store scoped to each agent — no global dictionaries, no external infrastructure. For multi-agent workflows, invocation_state shares data across agents in a Swarm with the same API.

Metric	Without pointers	With Memory Pointers
Data in context	214KB (full logs)	52 bytes (pointer)
Agent behavior	Truncates or fails	Processes all data
Errors detected	Partial	Complete

Full demo: 01-context-overflow-demo — single-agent and multi-agent (Swarm) implementations with notebooks.

Why Do AI Agents Freeze When Calling External APIs?

AI agents freeze when MCP tools call slow or unresponsive external APIs. The agent blocks on the tool call, the user sees no progress, and after 7 seconds many implementations return a 424 error. MCP (Model Context Protocol) enables agents to call external tools, but does not handle timeout or retry by default.

The fix — Async handleId pattern: The tool returns immediately with a job ID. The agent polls a separate check_status tool:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("timeout-demo")
JOBS = {}

@mcp.tool()
async def start_long_job(task: str) -> str:
    """Return handle immediately — prevents timeout."""
    job_id = str(uuid.uuid4())[:8]
    JOBS[job_id] = {"status": "processing", "task": task}
    asyncio.create_task(_process_job(job_id))  # Background work
    return f"Job started. Handle: {job_id}. Use check_job_status to poll."

@mcp.tool()
async def check_job_status(job_id: str) -> str:
    """Poll job status — returns 'processing' or 'completed' with result."""
    job = JOBS.get(job_id)
    if not job:
        return f"FAILED: Job '{job_id}' not found"
    return f"{job['status'].upper()}: {job.get('result', 'Still processing...')}"

Scenario	Response time	UX
Fast API (1s)	3s total	OK
Slow API (15s)	18s blocked	Agent frozen
Failing API	424 error after 7s	Agent crashes
Async handleId	~4s (immediate + poll)	Agent responsive

Why Strands Agents? The MCPClient connects to any MCP server with one line. The agent discovers tools at runtime via list_tools_sync() — no hardcoded tool list. When the MCP server implements the async pattern, the agent automatically polls without extra orchestration code.

Full demo: 02-mcp-timeout-demo — local MCP server with all 4 scenarios and notebook.

Why Do AI Agents Repeat the Same Tool Call?

AI agent reasoning loops happen when the agent calls the same tool repeatedly with identical parameters, making no progress. The root cause is ambiguous tool feedback — responses like "more results may be available" make the agent think another call will produce better results. Research shows agents can loop hundreds of times without delivering an answer.

Fix 1 — Clear terminal states: Tools return explicit SUCCESS or FAILED instead of ambiguous messages:

# Ambiguous (causes loops)
return f"Found flights: {results}. More results may be available."

# Clear (agent stops)
return f"SUCCESS: Booked flight {conf_id} for {passenger}. Confirmation sent."

Fix 2 — DebounceHook: Detect and block duplicate tool calls at the framework level:

from strands.hooks.registry import HookProvider, HookRegistry
from strands.hooks.events import BeforeToolCallEvent

class DebounceHook(HookProvider):
    """Block duplicate tool calls in a sliding window."""
    def __init__(self, window_size=3):
        self.call_history = []
        self.window_size = window_size

    def register_hooks(self, registry: HookRegistry) -> None:
        registry.add_callback(BeforeToolCallEvent, self.check_duplicate)

    def check_duplicate(self, event: BeforeToolCallEvent) -> None:
        key = (event.tool_use["name"], json.dumps(event.tool_use.get("input", {})))
        if self.call_history.count(key) >= 2:
            event.cancel_tool = f"BLOCKED: Duplicate call to {event.tool_use['name']}"
        self.call_history.append(key)
        self.call_history = self.call_history[-self.window_size:]

Strategy	Tool calls	Result
Ambiguous feedback (baseline)	14 calls	No definitive answer
DebounceHook	12 calls (2 blocked)	Completes with blocks
Clear SUCCESS states	2 calls	Immediate completion

Why Strands Agents? The HookProvider API intercepts tool calls via BeforeToolCallEvent before they execute. Setting event.cancel_tool blocks execution at the framework level — the LLM cannot bypass it. This makes hooks composable: stack DebounceHook, LimitToolCounts, and custom validators on the same agent.

Full demo: 03-reasoning-loops-demo — all 4 scenarios with hooks and notebook.

Prerequisites

You need Python 3.9+, uv (a fast Python package manager), and an OpenAI API key.

git clone https://github.com/aws-samples/sample-why-agents-fail
cd sample-why-agents-fail/stop-ai-agents-wasting-tokens

# Pick any demo
cd 01-context-overflow-demo   # or 02-mcp-timeout-demo, 03-reasoning-loops-demo
uv venv && uv pip install -r requirements.txt
export OPENAI_API_KEY="your-key-here"

uv run python test_*.py

Each demo is self-contained with its own dependencies, test script, and Jupyter notebook.

Frequently Asked Questions

What are the most common AI agent failure modes?

The three most common failure modes are context window overflow (tool returns more data than the LLM can process), MCP tool timeouts (external APIs block the agent indefinitely), and reasoning loops (agent repeats the same tool call without progress). Each failure mode causes token waste and degrades response quality.

How do I reduce AI agent token costs?

The two most effective techniques are memory pointers and clear tool states. The Memory Pointer Pattern stores large tool outputs in external state and passes short references to the LLM context — reducing token usage from 200KB+ to under 100 bytes per tool call. Clear terminal states (SUCCESS/FAILED) in tool responses prevent the agent from retrying completed operations, which can reduce tool calls from 14 to 2.

Can I use these patterns with frameworks other than Strands Agents?

Yes. The Memory Pointer Pattern works with any framework that supports tool context (passing state between tools). The async handleId pattern is an MCP server design pattern — it works with any MCP-compatible agent. DebounceHook requires lifecycle hooks, which are available in LangGraph, AutoGen, and CrewAI with different APIs.

References

Research

Solving Context Window Overflow in AI Agents — IBM Research, Nov 2025
Towards Effective GenAI Multi-Agent Collaboration — Amazon, Dec 2024
Resilient AI Agents With MCP — Octopus, May 2025
Language models can overthink — The Decoder, Jan 2025

Implementation

Strands Agent State — ToolContext and agent.state
Strands MCP Tools — Connect any MCP server
Strands Hooks — Lifecycle events and tool cancellation

Which failure mode have you hit in your agents? Share in the comments.

Gracias!

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

Elizabeth Fuentes LFollow

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

When Did Every AWS Service Launch?

Brooke Jamieson — Fri, 20 Mar 2026 20:49:31 +0000

Last updated: 20 March 2026

Last week I made a 6-minute video about the history of AWS and S3 to celebrate S3's 20th birthday (our baby is all grown up!). I did extensive research for this and as part of this I kept finding myself looking up things like "when did Lambda launch?" and "was DynamoDB before or after Redshift?" and getting frustrated that there wasn't a single page with all the dates in one place.

I've always wanted to put one together, but I was too lazy to manually go through hundreds of launch announcements across 20 years of What's New posts. But now we live in the future!

Then I started using the AWS MCP Server - a remote Model Context Protocol server that gives AI assistants authenticated access to AWS documentation, APIs, and pre-built workflows. One of its tools (search_documentation) lets you search across all AWS documentation, including the "What's New" announcements. This is super handy for keeping track of launches too - if you want to learn more, I have a whole blog on this called "You Should Just Use the Docs MCP to Keep Up with Launches During re:Invent Because Everything Else Is Too Annoying". (You can tell I did not use AI to write that title because it breaks every rule there is!)

So buckle up, here we go - every AWS service launch date I could find, from SQS in 2004 to Route 53 Global Resolver in 2026. Some services have both a preview and a general availability (GA) date so I've included everything that was available. And every launch links back to the original announcement so you can read it yourself.

Looking for a specific service?

Here are the most-searched AWS service launch dates. Click through to the full entry below for links to the original announcements.

Amazon SQS - 3 November 2004 (preview), 11 July 2006 (GA)
Amazon S3 - 13 March 2006
Amazon EC2 - 24 August 2006 (preview), 23 October 2008 (GA)
Amazon RDS - 27 October 2009
Amazon DynamoDB - 18 January 2012
Amazon Redshift - 14 February 2013
AWS Lambda - 13 November 2014 (preview), 9 April 2015 (GA)
Amazon ECS - 13 November 2014 (preview), 9 April 2015 (GA)
Amazon API Gateway - 9 July 2015
Amazon Aurora - 12 November 2014 (preview), 27 July 2015 (GA)
Amazon EKS - 29 November 2017 (preview), 5 June 2018 (GA)
AWS Fargate - 29 November 2017
Amazon SageMaker - 29 November 2017
Amazon EventBridge - 11 July 2019
AWS CDK - 11 July 2019
Amazon Bedrock - 13 April 2023 (preview), 28 September 2023 (GA)
Amazon Aurora DSQL - 3 December 2024 (preview), 28 May 2025 (GA)
Amazon Bedrock AgentCore - 21 July 2025 (preview), 14 October 2025 (GA)

What did AWS launch in 2004?

This is my favourite trivia question to ask user groups - did you know that the first AWS Service was SQS? It all started with a queue!

Amazon Simple Queue Service (SQS) - 3 November 2004 (preview) · announcement
A managed message queue service. SQS was the very first AWS service, launching in preview more than a year before S3 existed. It went GA on 11 July 2006. (GA announcement)

What did AWS launch in 2006?

S3 and EC2. Two services, and suddenly you could store objects and run virtual servers without owning hardware.

Amazon S3 - 13 March 2006 · announcement
Object storage. The service that started it all (well, after SQS). S3 turned 20 in 2026.

Amazon EC2 - 24 August 2006 (preview) · announcement
Virtual servers in the cloud. Launched in beta in 2006, went GA on 23 October 2008. (GA announcement)

What did AWS launch in 2008?

EC2 went GA, and EBS gave instances persistent storage for the first time.

Amazon Elastic Block Store (EBS) - 20 August 2008 · announcement
Persistent block storage for EC2 instances. Before EBS, your data disappeared when your instance stopped.

Amazon CloudFront - 18 November 2008 (preview) · announcement
Content delivery network. Went GA on 9 November 2010 with custom origin support. (GA announcement)

What did AWS launch in 2009?

Monitoring, managed databases, and networking. You could now run an app on EC2, put it in a VPC, store data in RDS, and watch it all with CloudWatch.

Amazon EMR - 2 April 2009 · announcement
Managed Hadoop (and now Spark, Hive, Presto, and more). Originally called Elastic MapReduce - the name tells you what era of big data this came from.

Amazon CloudWatch - 17 May 2009 · announcement
Monitoring and observability. Launched alongside Auto Scaling and Elastic Load Balancing.

Amazon VPC - 26 August 2009 (preview) · announcement
Virtual private networking. Originally optional - now every AWS resource lives inside a VPC by default.

Amazon RDS - 27 October 2009 · announcement
Managed relational databases. Started with MySQL, now supports PostgreSQL, MariaDB, Oracle, SQL Server, and (later) Aurora.

What did AWS launch in 2010?

SNS, Route 53, and IAM. Messaging, DNS, and the service that controls who can do what.

Amazon SNS - 7 April 2010 · announcement
Pub/sub messaging and push notifications.

AWS Identity and Access Management (IAM) - 2 September 2010 (preview) · announcement
The service that controls who can do what in your AWS account. Went GA on 3 May 2011. (GA announcement)

Amazon Route 53 - 6 December 2010 · announcement
DNS and domain registration. Named after the port number for DNS (53).

What did AWS launch in 2011?

CloudFormation, Elastic Beanstalk, SES, Direct Connect, and ElastiCache. Deploying and managing apps got a lot easier.

Amazon Elastic Beanstalk - 19 January 2011 · announcement
Platform-as-a-service for deploying web apps. You give it your code, it handles the infrastructure.

Amazon SES - 25 January 2011 · announcement
Email sending service.

AWS CloudFormation - 25 February 2011 · announcement
Infrastructure as code using JSON/YAML templates. The original IaC service on AWS.

AWS Direct Connect - 3 August 2011 · announcement
Dedicated network connection from your data centre to AWS.

Amazon ElastiCache - 22 August 2011 · announcement
Managed Redis and Memcached.

What did AWS launch in 2012?

DynamoDB, Glacier, SWF, Trusted Advisor, and Storage Gateway.

Amazon DynamoDB - 18 January 2012 · announcement
Managed NoSQL database.

AWS Trusted Advisor - 30 January 2012 · announcement
Automated best-practice checks for your AWS account.

Amazon Simple Workflow Service (SWF) - 21 February 2012 · announcement
Workflow coordination service. Largely superseded by Step Functions these days.

Amazon S3 Glacier - 20 August 2012 · announcement
Cold archival storage. Originally a standalone service, now integrated as S3 storage classes.

AWS Storage Gateway - 29 October 2012 · announcement
Hybrid cloud storage that connects on-premises environments to AWS.

What did AWS launch in 2013?

Redshift, CloudTrail, Kinesis, WorkSpaces, and a few others. Analytics and streaming showed up alongside the first virtual desktops.

Amazon Elastic Transcoder - 28 January 2013 · announcement
Media transcoding service.

Amazon Redshift - 14 February 2013 · announcement
Managed data warehouse. Launched on Valentine's Day, which feels appropriate for a service data teams love.

AWS OpsWorks - 18 February 2013 · announcement
Configuration management using Chef and Puppet.

AWS CloudHSM - 26 March 2013 · announcement
Hardware security modules in the cloud.

AWS CloudTrail - 13 November 2013 · announcement
API call logging. Records every action taken in your AWS account.

Amazon WorkSpaces - 13 November 2013 (preview) · announcement
Virtual desktops. Went GA on 26 March 2014. (GA announcement)

Amazon Kinesis Data Streams - 14 November 2013 (preview) · announcement
Real-time data streaming. Went GA on 16 December 2013. (GA announcement)

What did AWS launch in 2014?

Lambda, Aurora, ECS, Cognito, KMS, Config, and CodeDeploy. A big November - Lambda and ECS both previewed on the 13th.

AWS Cost Explorer - 8 April 2014 · announcement
Visualise and analyse your AWS spending over time.

Amazon Cognito - 10 July 2014 · announcement
User authentication and identity management for apps.

Amazon WorkDocs - 10 July 2014 (preview) · announcement
Enterprise document storage and sharing. Originally launched as Amazon Zocalo.

AWS Directory Service - 21 October 2014 · announcement
Managed Microsoft Active Directory in the cloud.

AWS CodeDeploy - 12 November 2014 · announcement
Automated code deployments to EC2, Lambda, and on-premises servers.

AWS Config - 12 November 2014 · announcement
Tracks configuration changes across your AWS resources.

AWS Key Management Service (KMS) - 12 November 2014 · announcement
Managed encryption keys.

Amazon Aurora - 12 November 2014 (preview) · announcement
MySQL and PostgreSQL-compatible relational database built for the cloud. Went GA on 27 July 2015. (GA announcement)

AWS Lambda - 13 November 2014 (preview) · announcement
Run code without provisioning servers. Went GA on 9 April 2015. (GA announcement)

Amazon Elastic Container Service (ECS) - 13 November 2014 (preview) · announcement
Managed container orchestration. Went GA on 9 April 2015. (GA announcement)

What did AWS launch in 2015?

API Gateway, IoT Core, OpenSearch (then Elasticsearch), WAF, Snowball, CodeCommit, CodePipeline, and more. Eighteen services across the year.

Amazon WorkMail - 28 January 2015 (preview) · announcement
Managed business email and calendar. Went GA on 4 January 2016. (GA announcement)

Amazon Elastic File System (EFS) - 9 April 2015 (preview) · announcement
Managed NFS file storage for EC2.

AWS Budgets - 29 June 2015 · announcement
Set custom cost and usage budgets with alerts.

AWS CodeCommit - 9 July 2015 · announcement
Managed Git repositories.

AWS CodePipeline - 9 July 2015 · announcement
Continuous delivery pipeline service.

AWS Device Farm - 9 July 2015 · announcement
Test mobile apps on real devices in the cloud.

AWS Service Catalog - 9 July 2015 · announcement
Create and manage approved IT service catalogues.

Amazon API Gateway - 9 July 2015 · announcement
Create, publish, and manage REST and WebSocket APIs.

Amazon OpenSearch Service - 1 October 2015 · announcement
Managed search and analytics. Originally launched as Amazon Elasticsearch Service, rebranded in 2021.

AWS WAF - 6 October 2015 · announcement
Web application firewall.

AWS Snowball - 7 October 2015 · announcement
Physical data transport device. Ship your data to AWS on a rugged appliance.

Amazon Kinesis Data Firehose - 7 October 2015 · announcement
Load streaming data into data stores and analytics services.

Amazon Inspector - 7 October 2015 (preview) · announcement
Automated security assessment. Went GA on 19 April 2016. (GA announcement)

Amazon QuickSight - 7 October 2015 (preview) · announcement
Business intelligence and data visualisation. Went GA on 15 November 2016. (GA announcement)

AWS IoT Core - 8 October 2015 (preview) · announcement
Connect IoT devices to the cloud. Went GA on 18 December 2015. (GA announcement)

Amazon Elastic Container Registry (ECR) - 21 December 2015 · announcement
Managed Docker container registry.

What did AWS launch in 2016?

Certificate Manager and DMS shipped in Q1, Flink arrived mid-year, and then November brought Lightsail, Athena, Polly, Rekognition, Step Functions, and a dozen more. Over 25 services this year.

AWS Certificate Manager - 21 January 2016 · announcement
Free SSL/TLS certificates for AWS services.

Amazon GameLift - 9 February 2016 · announcement
Managed game server hosting.

Amazon Lumberyard - 9 February 2016 · announcement
Game engine. (Later evolved into Open 3D Engine.)

AWS Database Migration Service (DMS) - 15 March 2016 · announcement
Migrate databases to AWS with minimal downtime.

AWS Application Discovery Service - 19 April 2016 (preview) · announcement
Discover on-premises applications for migration planning. Went GA on 12 May 2016. (GA announcement)

Amazon Managed Service for Apache Flink - 11 August 2016 · announcement
Real-time stream processing. Originally launched as Amazon Kinesis Analytics.

AWS Server Migration Service - 24 October 2016 · announcement
Migrate on-premises workloads to AWS.

AWS Organizations - 29 November 2016 (preview) · announcement
Centrally manage multiple AWS accounts. Went GA on 27 February 2017. (GA announcement)

Amazon Athena - 30 November 2016 · announcement
Query data in S3 using SQL. No infrastructure to manage.

Amazon Lightsail - 30 November 2016 · announcement
Simple virtual private servers with fixed monthly pricing.

Amazon Polly - 30 November 2016 · announcement
Text-to-speech service.

Amazon Rekognition - 30 November 2016 · announcement
Image and video analysis using deep learning.

Amazon Lex - 30 November 2016 (preview) · announcement
Build conversational interfaces (the tech behind Alexa). Went GA on 19 April 2017. (GA announcement)

AWS IoT Greengrass - 30 November 2016 (preview) · announcement
Run AWS Lambda functions on edge devices. Went GA on 7 June 2017. (GA announcement)

AWS Snowball Edge - 30 November 2016 · announcement
Snowball with local compute capabilities.

AWS Snowmobile - 30 November 2016 · announcement
A literal shipping container truck for exabyte-scale data transfer. My favourite AWS Service of all time.

AWS CodeBuild - 1 December 2016 · announcement
Managed build service for compiling and testing code.

AWS Personal Health Dashboard - 1 December 2016 · announcement
Personalised view of AWS service health events affecting your resources.

AWS Shield - 1 December 2016 · announcement
DDoS protection.

AWS Step Functions - 1 December 2016 · announcement
Visual workflow orchestration for distributed applications.

Amazon AppStream 2.0 - 1 December 2016 · announcement
Stream desktop applications to any device.

Amazon Pinpoint - 1 December 2016 · announcement
Targeted push notifications and campaign management.

AWS Glue - 1 December 2016 (preview) · announcement
Serverless ETL (extract, transform, load) service. Went GA on 14 August 2017. (GA announcement)

AWS Artifact - 7 December 2016 · announcement
On-demand access to AWS compliance reports.

AWS Managed Services - 12 December 2016 · announcement
AWS operates your infrastructure for you.

What did AWS launch in 2017?

Connect and X-Ray shipped in the spring. The Elemental media suite arrived in November. Fargate, SageMaker, EKS, and GuardDuty followed days later. Over 30 services this year - the most in a single year until that point.

AWS Batch - 5 January 2017 · announcement
Run batch computing workloads.

Amazon Chime - 13 February 2017 · announcement
Video conferencing and online meetings.

Amazon Connect - 28 March 2017 · announcement
Cloud-based contact centre.

AWS CodeStar - 19 April 2017 · announcement
Unified interface for managing software development activities.

AWS X-Ray - 19 April 2017 · announcement
Distributed tracing for debugging production applications.

AWS Migration Hub - 14 August 2017 · announcement
Track application migrations across multiple AWS tools.

Amazon Macie - 14 August 2017 · announcement
Discover and protect sensitive data using machine learning.

VMware Cloud on AWS - 28 August 2017 · announcement
Run VMware workloads on AWS infrastructure.

AWS PrivateLink - 8 November 2017 · announcement
Private connectivity between VPCs and AWS services without traversing the public internet.

AWS Amplify - 21 November 2017 · announcement
Build full-stack web and mobile apps. Started as a JavaScript library, now a full development platform.

AWS Elemental MediaConvert - 26 November 2017 · announcement
File-based video transcoding.

AWS Elemental MediaLive - 26 November 2017 · announcement
Live video encoding.

AWS Elemental MediaPackage - 26 November 2017 · announcement
Video origination and packaging.

AWS Elemental MediaStore - 26 November 2017 · announcement
Storage optimised for media.

AWS Elemental MediaTailor - 26 November 2017 · announcement
Server-side ad insertion for video.

Amazon GuardDuty - 28 November 2017 · announcement
Threat detection for your AWS account. Analyses CloudTrail, VPC Flow Logs, and DNS logs.

Amazon MQ - 28 November 2017 · announcement
Managed message broker for Apache ActiveMQ and RabbitMQ.

AWS AppSync - 28 November 2017 (preview) · announcement
Managed GraphQL APIs with real-time data and offline support.

AWS Fargate - 29 November 2017 · announcement
Run containers without managing servers. Serverless compute for ECS and EKS.

AWS IoT Device Management - 29 November 2017 · announcement
Onboard, organise, and remotely manage IoT devices at scale.

AWS Systems Manager - 29 November 2017 · announcement
Operational hub for managing AWS resources. Patch management, parameter store, run commands, and more.

Amazon Comprehend - 29 November 2017 · announcement
Natural language processing - extract insights from text.

Amazon FreeRTOS - 29 November 2017 · announcement
Operating system for microcontrollers.

Amazon Kinesis Video Streams - 29 November 2017 · announcement
Stream video from connected devices to AWS for analytics and ML.

Amazon SageMaker - 29 November 2017 · announcement
Build, train, and deploy machine learning models.

AWS DeepLens - 29 November 2017 (preview) · announcement
Deep learning-enabled video camera for developers.

AWS IoT 1-Click - 29 November 2017 (preview) · announcement
Trigger Lambda functions from simple IoT devices.

AWS IoT Analytics - 29 November 2017 (preview) · announcement
Analytics for IoT data.

Amazon Transcribe - 29 November 2017 (preview) · announcement
Automatic speech-to-text.

Amazon Translate - 29 November 2017 (preview) · announcement
Neural machine translation.

Amazon Neptune - 29 November 2017 (preview) · announcement
Managed graph database. Went GA on 30 May 2018. (GA announcement)

Amazon Elastic Kubernetes Service (EKS) - 29 November 2017 (preview) · announcement
Managed Kubernetes. Went GA on 5 June 2018. (GA announcement)

AWS IoT Device Defender - 29 November 2017 (preview) · announcement
Security management for IoT devices. Went GA on 2 August 2018. (GA announcement)

AWS Serverless Application Repository - 30 November 2017 (preview) · announcement
Discover and deploy serverless applications. Went GA on 21 February 2018. (GA announcement)

AWS Cloud9 - 30 November 2017 · announcement
Cloud-based IDE.

AWS IAM Identity Center - 7 December 2017 · announcement
Centrally manage single sign-on access to multiple AWS accounts. Originally launched as AWS SSO.

What did AWS launch in 2018?

Secrets Manager, Private CA, and Firewall Manager shipped in April. Then November and December brought a wave of preview announcements — many with GA dates stretching into 2019 and even 2020. Transit Gateway and the FSx family also arrived.

AWS Firewall Manager - 4 April 2018 · announcement
Centrally manage firewall rules across accounts.

AWS Private CA - 4 April 2018 · announcement
Managed private certificate authority.

AWS Secrets Manager - 4 April 2018 · announcement
Store, rotate, and manage secrets like database credentials and API keys.

Amazon Corretto - 14 November 2018 (preview) · announcement
No-cost, production-ready distribution of OpenJDK. Went GA on 31 January 2019. (GA announcement)

AWS Resource Access Manager (RAM) - 21 November 2018 · announcement
Share AWS resources across accounts.

AWS Transfer Family - 25 November 2018 · announcement
Managed SFTP, FTPS, and FTP for S3 and EFS. Originally launched as AWS Transfer for SFTP.

AWS DataSync - 26 November 2018 · announcement
Automated data transfer between on-premises storage and AWS.

AWS Global Accelerator - 26 November 2018 · announcement
Improve availability and performance using the AWS global network.

AWS RoboMaker - 26 November 2018 · announcement
Develop, test, and deploy robotics applications.

AWS Transit Gateway - 26 November 2018 · announcement
Connect VPCs and on-premises networks through a central hub.

AWS IoT Events - 26 November 2018 (preview) · announcement
Detect and respond to events from IoT sensors.

AWS IoT Things Graph - 26 November 2018 (preview) · announcement
Visually connect devices and web services for IoT applications.

AWS IoT SiteWise - 26 November 2018 (preview) · announcement
Collect and analyse industrial equipment data. Went GA on 9 July 2020. (GA announcement)

AWS Elemental MediaConnect - 27 November 2018 · announcement
Reliable live video transport.

AWS Cloud Map - 28 November 2018 · announcement
Service discovery for cloud resources.

AWS Inferentia - 28 November 2018 · announcement
Custom ML inference chip designed by AWS.

AWS License Manager - 28 November 2018 · announcement
Manage software licences across AWS and on-premises.

Amazon Elastic Inference - 28 November 2018 · announcement
Attach GPU-powered inference acceleration to any EC2 or SageMaker instance.

Amazon FSx for Lustre - 28 November 2018 · announcement
High-performance file system for compute-intensive workloads.

Amazon FSx for Windows File Server - 28 November 2018 · announcement
Managed Windows-native file system.

AWS App Mesh - 28 November 2018 (preview) · announcement
Service mesh for microservices.

AWS DeepRacer - 28 November 2018 (preview) · announcement
Autonomous 1/18th scale race car for learning reinforcement learning.

Amazon Managed Blockchain - 28 November 2018 (preview) · announcement
Create and manage blockchain networks.

Amazon Managed Streaming for Apache Kafka (MSK) - 28 November 2018 (preview) · announcement
Managed Apache Kafka.

Amazon Textract - 28 November 2018 (preview) · announcement
Extract text and data from documents using ML.

Amazon Personalize - 28 November 2018 (preview) · announcement
ML-powered personalisation. Went GA on 10 June 2019. (GA announcement)

AWS Security Hub - 28 November 2018 (preview) · announcement
Centralised security findings. Went GA on 24 June 2019. (GA announcement)

Amazon Forecast - 28 November 2018 (preview) · announcement
Time-series forecasting using ML. Went GA on 22 August 2019. (GA announcement)

Amazon QLDB - 28 November 2018 (preview) · announcement
Quantum Ledger Database - immutable, cryptographically verifiable transaction log. Went GA on 10 September 2019. (GA announcement)

AWS Outposts - 28 November 2018 (preview) · announcement
Run AWS infrastructure on-premises. Went GA on 3 December 2019. (GA announcement)

Amazon Timestream - 28 November 2018 (preview) · announcement
Managed time-series database. Went GA on 30 September 2020. (GA announcement)

AWS Well-Architected Tool - 29 November 2018 · announcement
Review your workloads against AWS best practices.

What did AWS launch in 2019?

CDK and EventBridge went GA in July. Control Tower shipped in June. Lake Formation arrived in August. December brought another batch of previews including Braket, Detective, and Kendra.

Amazon DocumentDB - 8 January 2019 · announcement
MongoDB-compatible managed document database.

AWS Backup - 16 January 2019 · announcement
Centralised backup across AWS services.

Amazon WorkLink - 23 January 2019 · announcement
Secure mobile access to internal websites and web apps.

AWS Ground Station - 23 May 2019 · announcement
Communicate with satellites. Yes, actual satellites.

AWS Control Tower - 24 June 2019 · announcement
Set up and govern a multi-account AWS environment.

AWS Cloud Development Kit (CDK) - 11 July 2019 · announcement
Define cloud infrastructure using familiar programming languages instead of YAML/JSON.

Amazon EventBridge - 11 July 2019 · announcement
Serverless event bus. Connect applications using events from AWS services, SaaS apps, and your own code.

AWS Chatbot - 24 July 2019 · announcement
ChatOps for AWS - get notifications and run commands in Slack and Teams.

AWS Elemental Appliances & Software - 7 August 2019 · announcement
On-premises video processing hardware and software.

AWS Lake Formation - 9 August 2019 · announcement
Build, secure, and manage data lakes.

AWS Data Exchange - 13 November 2019 · announcement
Find, subscribe to, and use third-party data in the cloud.

AWS Launch Wizard - 13 November 2019 · announcement
Guided deployments for enterprise applications like SQL Server and SAP.

AWS DeepComposer - 1 December 2019 (preview) · announcement
ML-powered music composition. A musical keyboard for learning generative AI.

AWS IAM Access Analyzer - 2 December 2019 · announcement
Identify resources shared with external entities.

Amazon Braket - 2 December 2019 (preview) · announcement
Quantum computing service. Went GA on 13 August 2020. (GA announcement)

Amazon EC2 Image Builder - 2 December 2019 · announcement
Automate the creation and maintenance of AMIs.

AWS Compute Optimizer - 3 December 2019 · announcement
ML-powered recommendations for right-sizing compute resources.

Amazon Augmented AI (A2I) - 3 December 2019 (preview) · announcement
Human review workflows for ML predictions.

Amazon CodeGuru - 3 December 2019 (preview) · announcement
ML-powered code reviews and application performance recommendations.

Amazon Detective - 3 December 2019 (preview) · announcement
Investigate security findings. Went GA on 31 March 2020. (GA announcement)

Amazon Keyspaces (for Apache Cassandra) - 3 December 2019 (preview) · announcement
Managed Cassandra-compatible database. Went GA on 23 April 2020. (GA announcement)

Amazon Kendra - 3 December 2019 (preview) · announcement
ML-powered enterprise search. Went GA on 11 May 2020. (GA announcement)

Amazon Fraud Detector - 3 December 2019 (preview) · announcement
Detect online fraud using ML. Went GA on 28 July 2020. (GA announcement)

AWS Wavelength - 3 December 2019 (preview) · announcement
Ultra-low latency applications at 5G network edges. Went GA on 6 August 2020. (GA announcement)

What did AWS launch in 2020?

Fewer net-new services than previous years. Network Firewall, CloudShell, MWAA (managed Airflow), and a batch of ML services. A lot of 2019 previews also went GA.

Amazon AppFlow - 22 April 2020 · announcement
Transfer data between SaaS apps and AWS without code.

AWS CodeArtifact - 10 June 2020 · announcement
Managed artifact repository for software packages (npm, PyPI, Maven, etc.).

AWS Snowcone - 17 June 2020 · announcement
The smallest Snow family device. Portable, rugged edge computing and data transfer.

Amazon Honeycode - 24 June 2020 (preview) · announcement
Build mobile and web apps without code using a spreadsheet-like interface.

Amazon RDS Proxy - 30 June 2020 · announcement
Managed database proxy that makes applications more scalable and resilient.

AWS App2Container - 1 July 2020 · announcement
Containerise existing .NET and Java applications.

Amazon Interactive Video Service (IVS) - 15 July 2020 · announcement
Managed live streaming.

AWS Distro for OpenTelemetry - 21 October 2020 (preview) · announcement
AWS-supported distribution of the OpenTelemetry project for distributed tracing and metrics.

AWS Glue DataBrew - 11 November 2020 · announcement
Visual data preparation tool - clean and normalise data without writing code.

AWS Network Firewall - 19 November 2020 · announcement
Managed network firewall for VPCs.

Amazon MWAA - 24 November 2020 · announcement
Managed Apache Airflow for workflow orchestration.

Amazon Monitron - 1 December 2020 · announcement
End-to-end machine monitoring system using sensors and ML.

Amazon ECS Anywhere - 1 December 2020 (preview) · announcement
Run ECS tasks on your own infrastructure.

Amazon Lookout for Vision - 1 December 2020 (preview) · announcement
Spot product defects using computer vision. Went GA on 24 February 2021. (GA announcement)

Amazon Lookout for Equipment - 1 December 2020 (preview) · announcement
Detect abnormal equipment behaviour for predictive maintenance. Went GA on 8 April 2021. (GA announcement)

Amazon DevOps Guru - 1 December 2020 (preview) · announcement
ML-powered operations service that identifies application issues. Went GA on 4 May 2021. (GA announcement)

AWS Proton - 1 December 2020 (preview) · announcement
Automated infrastructure provisioning for container and serverless deployments. Went GA on 9 June 2021. (GA announcement)

AWS Panorama - 1 December 2020 (preview) · announcement
Add computer vision to existing cameras. Went GA on 20 October 2021. (GA announcement)

AWS Audit Manager - 8 December 2020 · announcement
Continuously audit your AWS usage for compliance.

Amazon Lookout for Metrics - 8 December 2020 (preview) · announcement
Detect anomalies in business metrics. Went GA on 25 March 2021. (GA announcement)

Amazon HealthLake - 8 December 2020 (preview) · announcement
Store, transform, and analyse health data. Went GA on 15 July 2021. (GA announcement)

AWS CloudShell - 15 December 2020 · announcement
Browser-based shell with the AWS CLI pre-installed.

Amazon Managed Grafana - 15 December 2020 (preview) · announcement
Managed Grafana for operational dashboards. Went GA on 31 August 2021. (GA announcement)

Amazon Managed Service for Prometheus - 15 December 2020 (preview) · announcement
Managed Prometheus for container monitoring. Went GA on 29 September 2021. (GA announcement)

Amazon Location Service - 16 December 2020 (preview) · announcement
Maps, geofencing, and location-based services. Went GA on 1 June 2021. (GA announcement)

What did AWS launch in 2021?

App Runner, MemoryDB, FSx for OpenZFS, Fault Injection Simulator, Resilience Hub, and Elastic Disaster Recovery. Fewer services than the 2017–2019 peak, but this year had a lot of smaller feature launches that are not listed here.

AWS Fault Injection Simulator - 16 March 2021 · announcement
Chaos engineering - run controlled experiments to test resilience.

Amazon Nimble Studio - 28 April 2021 · announcement
Cloud-based content creation for visual effects and animation studios.

Amazon FinSpace - 3 May 2021 · announcement
Data management and analytics for the financial services industry.

AWS App Runner - 18 May 2021 · announcement
Deploy containerised web apps and APIs from source code or a container image.

AWS Application Migration Service - 18 May 2021 · announcement
Lift-and-shift migration to AWS.

Amazon MemoryDB for Redis - 19 August 2021 · announcement
Redis-compatible, durable, in-memory database.

Amazon FSx for NetApp ONTAP - 2 September 2021 · announcement
Managed NetApp ONTAP file system on AWS.

Amazon MSK Connect - 16 September 2021 · announcement
Managed Kafka Connect connectors for streaming data in and out of Apache Kafka.

AWS Cloud Control API - 30 September 2021 · announcement
A uniform API for creating, reading, updating, and deleting AWS resources.

AWS Resilience Hub - 10 November 2021 · announcement
Define, validate, and track the resilience of your applications.

AWS Elastic Disaster Recovery - 17 November 2021 · announcement
Scalable, cost-effective disaster recovery to AWS.

Amazon FSx for OpenZFS - 30 November 2021 · announcement
Managed OpenZFS file system.

AWS IoT TwinMaker - 30 November 2021 (preview) · announcement
Build digital twins of real-world systems. Went GA on 21 April 2022. (GA announcement)

AWS Mainframe Modernization - 30 November 2021 (preview) · announcement
Migrate and modernise mainframe applications. Went GA on 8 June 2022. (GA announcement)

AWS Private 5G - 30 November 2021 (preview) · announcement
Deploy and manage your own private 5G network. Went GA on 11 August 2022. (GA announcement)

AWS IoT FleetWise - 30 November 2021 (preview) · announcement
Collect and transfer vehicle data to the cloud. Went GA on 27 September 2022. (GA announcement)

Amazon VPC IPAM - 1 December 2021 · announcement
IP address management at scale.

AWS Cloud WAN - 2 December 2021 (preview) · announcement
Build and manage a global wide area network. Went GA on 12 July 2022. (GA announcement)

What did AWS launch in 2022?

CodeWhisperer arrived in preview mid-year just before I started my job with AWS. Trainium went GA in October. The end of the year brought Verified Permissions, Supply Chain, Security Lake, and Application Composer.

AWS Billing Conductor - 17 March 2022 · announcement
Customise your billing data for showback and chargeback.

Amazon GameSparks - 23 March 2022 (preview) · announcement
Game backend service.

Amazon EMR Serverless - 1 June 2022 · announcement
Run Spark and Hive without managing clusters.

Amazon CodeWhisperer - 23 June 2022 (preview) · announcement
AI-powered code suggestions. Went GA on 13 April 2023. (GA announcement)

Amazon Redshift Serverless - 12 July 2022 · announcement
Run analytics without managing data warehouse infrastructure.

AWS Wickr - 26 July 2022 (preview) · announcement
End-to-end encrypted messaging.

AWS Trainium - 10 October 2022 · announcement
Custom ML training chip. EC2 Trn1 instances went GA.

Amazon Verified Permissions - 28 November 2022 (preview) · announcement
Fine-grained authorisation using Cedar policy language. Went GA on 13 June 2023. (GA announcement)

AWS SimSpace Weaver - 29 November 2022 · announcement
Run large-scale spatial simulations.

Amazon Omics - 29 November 2022 · announcement
Store, query, and analyse genomic and biological data.

AWS Supply Chain - 29 November 2022 (preview) · announcement
ML-powered supply chain management. Went GA on 4 April 2023. (GA announcement)

AWS Verified Access - 29 November 2022 (preview) · announcement
Zero-trust access to corporate applications without a VPN. Went GA on 28 April 2023. (GA announcement)

Amazon Security Lake - 29 November 2022 (preview) · announcement
Centralise security data in OCSF format. Went GA on 30 May 2023. (GA announcement)

AWS Application Composer - 1 December 2022 (preview) · announcement
Visually design serverless applications. Went GA on 7 March 2023. (GA announcement)

Amazon CodeCatalyst - 1 December 2022 (preview) · announcement
Unified software development service. Went GA on 20 April 2023. (GA announcement)

What did AWS launch in 2023?

Bedrock went GA in September. Amazon Q previewed in November. Clean Rooms, VPC Lattice, and Payment Cryptography also shipped.

AWS Telco Network Builder - 21 February 2023 · announcement
Deploy and manage telco networks on AWS.

AWS Clean Rooms - 21 March 2023 · announcement
Analyse combined datasets without sharing raw data.

Amazon VPC Lattice - 31 March 2023 · announcement
Service-to-service connectivity, security, and monitoring across VPCs and accounts.

Amazon Bedrock - 13 April 2023 (preview) · announcement
Access foundation models from AI21 Labs, Anthropic, Cohere, Meta, Stability AI, and Amazon through a single API. Went GA on 28 September 2023. (GA announcement)

AWS Payment Cryptography - 12 June 2023 · announcement
Managed cryptographic operations for payment processing.

AWS AppFabric - 27 June 2023 · announcement
Connect SaaS applications for security and management.

AWS HealthImaging - 25 July 2023 · announcement
Store, access, and analyse medical imaging data at scale.

AWS HealthScribe - 26 July 2023 (preview) · announcement
Generate clinical documentation from patient-clinician conversations. Went GA on 27 November 2023. (GA announcement)

AWS Entity Resolution - 26 July 2023 · announcement
Match and link related records across data sources.

Amazon DataZone - 4 October 2023 · announcement
Data management service for cataloguing, discovering, and governing data.

AWS B2B Data Interchange - 27 November 2023 · announcement
Automate EDI (electronic data interchange) document transformations.

Amazon Q - 28 November 2023 (preview) · announcement
Generative AI assistant for software development and AWS operations. Went GA on 30 April 2024. (GA announcement)

What did AWS launch in 2024?

Eight new services including Deadline Cloud, App Studio, Nova, Aurora DSQL (in preview), and a lot of ‘feature launches’ that are not full services so they’re not on this list.

AWS Deadline Cloud - 2 April 2024 · announcement
Managed render farm for visual effects and animation.

AWS App Studio - 10 July 2024 (preview) · announcement
Build enterprise applications using natural language. Went GA on 18 November 2024. (GA announcement)

AWS End User Messaging - 29 July 2024 · announcement
Send and manage messages across SMS, MMS, and push channels.

AWS Data Transfer Terminal - 1 December 2024 · announcement
Physical locations for high-speed data uploads to AWS.

AWS Security Incident Response - 1 December 2024 · announcement
Triage and respond to security incidents in your AWS account.

Amazon Nova - 3 December 2024 · announcement
Amazon's own family of foundation models, available through Bedrock. Includes text, multimodal, and image generation models.

Amazon Aurora DSQL - 3 December 2024 (preview) · announcement
Serverless, distributed SQL database with active-active high availability. PostgreSQL-compatible. Went GA on 28 May 2025. (GA announcement)

Amazon S3 Tables - 3 December 2024 (preview) · announcement
Cloud object store with built-in Apache Iceberg support, optimised for analytics workloads.

What did AWS launch in 2025?

AWS Transform went GA in May for mainframe, VMware, and .NET workloads. Bedrock AgentCore previewed in July and went GA in October. December brought Nova Act, S3 Vectors, and the next generation of Nova models.

AWS Transform - 28 May 2025 · announcement
Automates modernisation of mainframe, VMware, and .NET workloads using AI. Launched with support for mainframe, VMware, and .NET workloads, with a custom transformation capability added at re:Invent 2025. (VMware GA) (.NET GA) (Custom GA)

Amazon Bedrock AgentCore - 21 July 2025 (preview) · announcement
Infrastructure for deploying and running AI agents. Includes runtime, memory, gateway, identity, and observability components. Went GA on 14 October 2025. (GA announcement)

Amazon Nova Act - 2 December 2025 · announcement
Build AI agents that automate browser-based UI workflows - form filling, search and extract, QA testing.

Amazon S3 Vectors - 2 December 2025 · announcement
Vector storage and querying built into S3.

What has AWS launched in 2026 so far?

We're only a few months in, but new services are already arriving.

AWS Elemental Inference - 24 February 2026 · announcement
AI-powered live video processing. Automatically generates vertical content and highlight clips for mobile and social platforms in real time, alongside encoding.

Amazon Connect Health - 5 March 2026 · announcement
Agentic AI for healthcare, built on Amazon Connect. Five AI agents handle patient verification, appointment management, patient insights, ambient documentation, and medical coding.

Amazon Route 53 Global Resolver - 9 March 2026 · announcement
Anycast DNS resolver across 30 AWS Regions. Resolves public and private domains from anywhere, with DNS query filtering and centralised logging. Previewed at re:Invent 2025.

What’s missing from this list?

I am definitely sure I have missed something on this list, but I hope you’ll let me know in the comments! There were so many to get through, but then there’s also the thing where AWS has a habit of launching features that blur the line between “new service” and “major feature of an existing service.” So, I decided to try and include things that would have their own console entry, or their own pricing page, or their own “What’s New” launch announcement. There’s also some services I deliberately left out because they’re features rather than standalone services (So things like S3 Intelligent-Tiering, Lambda Layers, EC2 Auto Scaling). And there’s probably others I left out because it was a skill issue on my part. Live laugh love launches!

If you spot a gap, please let me know - I am extremely online and you can find me on LinkedIn or X.

If you want to do your own research like this, the AWS MCP Server is a great place to start! You can use it in Kiro, Claude Code, Cursor, or whatever AI Agent is your current favourite. It’s the reason this post exists - I’d been meaning to compile this list for years and never had the time until I had a tool that could help me find 250 announcements without opening 250 browser tabs.

About the Author:

Brooke Jamieson is a Senior Developer Advocate at AWS, focused on AI agents and developer tools. A former fashion model turned mathematician turned AI Engineer, Brooke moved from Australia to New York City for this role. They make byte-sized tech content about AI and AWS, and you can find them on LinkedIn, Instagram or X.

DEV Community: AWS

How I built MCP Apps based Sales Analytics Agentic UI & deployed it on Amazon Bedrock AgentCore

ashitaprasad / sample-mcp-apps-chatflow

Sample MCP Apps Chatflow

Articles

The Problem: When chat isn't enough!

The Solution: A Chatflow powered by MCP Apps

1. select-sales-metric tool

1.1. get-sales-data tool

2. visualize-sales-data tool

i) CSP is not a footnote, it is part of the Security Contract

ii) MCP App receives tool input through notification

3. show-sales-pdf-report tool

Serving MCP Apps Over HTTP

Deploying to Amazon Bedrock AgentCore Runtime (AgentCore CLI)

Software prerequisites

Step 1 - Prepare the server for AgentCore Runtime

Step 2: Add a Dockerfile

Step 3: Install the AgentCore CLI

Step 4: Create the AgentCore project

Configure the runtime

Configure deployment target

Step 5: Set up Cognito authentication

Create a Cognito User Pool

Create a Resource Server and App Client

Add JWT auth to agentcore.json

Step 6 - Deploy

Step 7 - Test the deployment

Get a Bearer token

Invoke the MCP server

List tools and resources

Step 8 - Connect from VS Code

Clean up

Final Words

5 Techniques to Stop AI Agent Hallucinations in Production

Prerequisites

Series Overview

How Does Each Anti-Hallucination Technique Map to Production?

What Does the Production Architecture Look Like?

How Do Steering Rules Work as Data Instead of Code?

When Should You Block vs Steer?

How Does the MCP Integration with AgentCore Gateway Work?

How Does GraphRAG Work in Production?

How to Deploy

Step 1 — Clone and install

Step 2 — Build and deploy

Step 3 — Store your OpenAI API key

Step 4 — Seed hotel data

Step 5 — Test

Adding GraphRAG (optional, separate stack)

Try It Yourself

Built-in Observability

How Fast Are the Anti-Hallucination Tools?

DynamoDB-Backed Tools

Neo4j AuraDB (GraphRAG)

DynamoDB vs Neo4j AuraDB: Side by Side

5 Lessons from Moving Anti-Hallucination Techniques to Production

Key Takeaways

Clean Up

Frequently Asked Questions

What is Amazon Bedrock AgentCore?

Can I use Amazon Bedrock models instead of OpenAI?

What is the difference between hard hooks and soft steering?

How much does this architecture cost?

Do I need GraphRAG for the agent to work?

Can I apply these patterns with other agent frameworks?

How does the agent discover tools via MCP at runtime?

Research Background

Tiempo real en aplicaciones web: Polling vs Subscriptions

¿Qué es Polling?

¿Cómo funciona?

Ventajas y desventajas del Polling

¿Qué son las Subscriptions?

¿Cómo funcionan?

Ventajas y desventajas de las Subscriptions

Polling vs Subscriptions: Comparación lado a lado

¿Cuándo gana Polling?

¿Cuándo ganan las Subscriptions?

¿Cuándo usar Polling y cuándo usar Subscriptions?

El enfoque híbrido

1. `select-sales-metric` tool

1.1. `get-sales-data` tool

2. `visualize-sales-data` tool

3. `show-sales-pdf-report` tool