DEV Community: Tim Moreton

I Built a Code-Roasting Rubber Duck

Tim Moreton — Wed, 29 Jul 2026 14:14:06 +0000

Every developer knows rubber-duck debugging: you explain your code to a rubber duck on your desk, and halfway through the explanation you spot the bug yourself. The duck just sits there. Silent. Judging.

I wanted a duck that judges out loud.

So I built Unducked. Paste in your code, and a foul-mouthed rubber duck reviews it like Gordon Ramsay reviews a risotto. It roasts you. It calls your function RAW. And then, annoyingly, it finds the actual bug and hands you the fix.

Try it right now: unducked.com. There's a dice button that fires a random piece of broken code at the duck, so you can taste a roast without pasting anything.

It's genuinely useful (the roast is a real code review) and it's the kind of thing you screenshot and send to the group chat.

The whole thing is one TypeScript file, a cheap model, and a public streaming endpoint on AWS. Two things surprised me building it, and both are the interesting part of this post:

The "AI" was the easy bit. The duck's entire personality is one system prompt. The model never changed.
Getting a public endpoint was the hard bit, and not for the reason you'd think. More on that in Step 6.

Here's how to build your own.

The mental model: an agent is a model + a prompt

The "AI" here isn't complicated. An agent is just a model with a personality bolted on via a system prompt. That's the entire trick.

Here's the shape of what we're building:

Browser (unducked.com)
  → CloudFront + Lambda proxy   (public HTTPS; signs requests for the browser)
    → AgentCore Runtime          (hosted agent endpoint)
      → Strands Agent            (Chef Duck persona)
        → Bedrock (Amazon Nova Lite)

You write a Strands agent in TypeScript. The AgentCore CLI deploys it as a hosted endpoint on AWS. A tiny Lambda proxy makes that endpoint safely callable from a browser. No hand-written Lambda business logic, no API Gateway, no Docker. Just TypeScript and a couple of CLI commands.

Step 1: Set up your environment (Node.js, AWS CLI, AgentCore)

You'll need an AWS account, Node.js 22+, and npm. You also need AWS credentials and a couple of CLI tools on your machine.

The fast path (let an AI agent do it). If you use a coding agent (Claude Code, Cursor, Kiro, Codex), hand it this and let it set everything up for you:

Set up Agent Toolkit for AWS by following these instructions:
https://raw.githubusercontent.com/aws/agent-toolkit-for-aws/refs/heads/main/setup-instructions/setup.md

It configures credentials and installs the AWS tooling in one shot.

Or, manually:

# 1. Install the AWS CLI (macOS shown; see AWS docs for other platforms)
brew install awscli

# 2. Configure credentials, then verify they work
aws configure
aws sts get-caller-identity

# 3. Install the AgentCore CLI and the AWS CDK (AgentCore uses CDK to deploy)
npm install -g @aws/agentcore aws-cdk

One more thing: in the Bedrock console, enable model access for Amazon Nova Lite. That's your toolchain.

Step 2: Scaffold the project with AgentCore CLI

One command scaffolds everything:

agentcore create agent \
  --name Unducked \
  --type create \
  --build CodeZip \
  --language TypeScript \
  --framework Strands \
  --model-provider Bedrock \
  --memory none

You get this structure:

Unducked/
├── agentcore/                # Config + CDK (you won't touch this)
└── app/Unducked/
    ├── main.ts               # The agent ← the file that matters
    ├── model/load.ts         # Which Bedrock model to use
    ├── package.json
    └── tsconfig.json

The scaffold drops in an example tool and an MCP client. Nice for later, but we'll strip them out for a pure roasting duck.

Step 3: Write the agent (the system prompt is the product)

This is where the personality lives, and it's the whole product.

// app/Unducked/main.ts
import { BedrockAgentCoreApp } from 'bedrock-agentcore/runtime';
import { Agent } from '@strands-agents/sdk';
import { loadModel } from './model/load.js';

const SYSTEM_PROMPT = `You are Chef Duck — a foul-mouthed-but-brilliant rubber
duck that reviews code like Gordon Ramsay runs a kitchen.

- Open with a short, savage roast of the CODE (never the person). Kitchen
  metaphors encouraged: "this function is RAW", "it's so nested it's got its
  own zip code".
- Then ACTUALLY HELP. Every roast must name the concrete bug and give the fix.
  Useful first, funny second.
- The "no bug" path: if the code has no real defect, roast it for being
  boring, concede in one line ("...fine. It's not garbage."), and STOP.
  Type annotations, input validation, and null checks are NOT bugs — never
  suggest them for code that already works. Inventing improvements is failing.
- Keep it tight. PG-13 — spicy, not vile. Plain prose, no headings, a fenced
  code block for the fix.`;

const model = loadModel();

// One Agent per session so follow-up questions keep the roast in context.
const agents = new Map<string, Agent>();

const app = new BedrockAgentCoreApp({
  invocationHandler: {
    async *process(payload: any, context: any) {
      const sessionId = context?.sessionId ?? 'default-session';
      let agent = agents.get(sessionId);
      if (!agent) {
        agent = new Agent({ model, systemPrompt: SYSTEM_PROMPT });
        agents.set(sessionId, agent);
      }

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

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

Three pieces:

The system prompt is the product. Everything that makes it "Chef Duck" is those few sentences.
BedrockAgentCoreApp wires the agent to the HTTP endpoints the runtime expects. You just write the handler.
Stream the roast back by iterating over agent.stream() and yielding each text delta.

loadModel() points at Amazon Nova Lite, ~$0.06/$0.24 per million tokens on Bedrock, so roasts cost a fraction of a cent. But here's the thing that took the most iteration: the hardest part of the prompt is the "no bug" path. Cheap models are desperate to be helpful. Hand them working code and they'll "improve" it with type checks and validation nobody asked for, which ruins the joke and gives bad advice. The prompt has to explicitly forbid that and tell the duck to just concede when the code is fine. Getting a cheap model to shut up was harder than getting it to roast.

Gotcha that cost me time: the stream emits several event types, and you can only reach event.event after narrowing on event.type first. The three-part if above is what actually compiles. A bare event.event?.delta?.type throws a TypeScript error. Copy it exactly.

Swap the model ID in model/load.ts for Claude Haiku or Sonnet if you want more polish.

Step 4: Test locally with `agentcore dev`

agentcore dev

In another terminal:

agentcore dev "function last(arr) { return arr[arr.length]; }"

You'll get an off-by-one roast streamed back, live. If that works, your duck is alive.

Step 5: Deploy to AWS

agentcore deploy

The CLI compiles your TypeScript, packages it, uses CDK to stand up the IAM roles and an AgentCore Runtime endpoint, and wires up CloudWatch logging. First deploy takes a few minutes while CDK bootstraps; after that it's fast.

agentcore invoke "def add(a, b): return a - b" --stream

If the duck tells you your add function is a liar, you're live on AWS.

Step 6: Make the endpoint public (the actually-hard part)

Here's the wrinkle nobody warns you about. Your agent is deployed, but the AgentCore endpoint requires AWS SigV4-signed requests. A browser can't call it directly, and you must never sign from client-side JS (that ships your AWS credentials in the page source). So you need something in the middle that holds an IAM role and signs on the browser's behalf.

The obvious move, a public Lambda Function URL with AuthType: NONE, does not work. The reason is a great story: AWS's own security tooling detects the world-accessible Lambda and automatically scopes the permissions back down. Your calls quietly start returning Forbidden. The platform is protecting you from yourself.

The setup that actually holds up:

CloudFront distribution   (public HTTPS, injects CORS, SigV4-signs to origin)
  → Lambda Function URL   (AuthType = AWS_IAM, streaming proxy)
    → AgentCore Runtime   (InvokeAgentRuntime)

CloudFront is the public face. It signs each request to a private, IAM-authed Lambda using an Origin Access Control (OAC). The Lambda is never world-accessible; CloudFront is. The Lambda itself is tiny: it forwards the prompt to the runtime and streams the SSE response straight back:

// proxy/index.mjs — the whole proxy, minus CORS boilerplate
export const handler = awslambda.streamifyResponse(async (event, responseStream) => {
  const { prompt } = JSON.parse(event.body ?? '{}');

  const res = await client.send(new InvokeAgentRuntimeCommand({
    agentRuntimeArn: RUNTIME_ARN,
    runtimeSessionId: sessionId,        // AgentCore requires ≥ 33 chars
    accept: 'text/event-stream',
    contentType: 'application/json',
    payload: new TextEncoder().encode(JSON.stringify({ prompt })),
  }));

  // The runtime already emits well-formed `data: ...\n\n` SSE frames. Forward verbatim.
  for await (const chunk of res.response) responseStream.write(chunk);
  responseStream.end();
});

Two gotchas here each cost me an afternoon, so I'll save you both:

POST bodies need an x-amz-content-sha256 header. Lambda Function URLs behind OAC reject unsigned payloads. CloudFront signs assuming the client already hashed the body. So the browser has to send the SHA-256 of the request body, or you get "signature does not match."
CloudFront needs both lambda:InvokeFunctionUrl and lambda:InvokeFunction. Grant only the first and you still get Forbidden.

The repo's blogs/deployment-notes.md has the exact CLI commands for the proxy, the OAC, the CORS response-headers policy, and the IAM. Reproduce it from scratch in a few minutes.

Step 7: The frontend (SSE streaming from the browser)

The UI is one HTML file, no build step, and I'm going to spend almost no time on it because the interesting work is behind it. It's a paste box, an ASCII duck, and that dice button. The only part that matters is how it talks to the agent: send the code, read back a Server-Sent Events stream.

const res = await fetch(API_URL, {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "Accept": "text/event-stream",  // required: the agent streams SSE, not JSON
    "X-Amzn-Bedrock-AgentCore-Runtime-Session-Id": sessionId,
    // For prod, CloudFront's OAC needs the body hash (see Step 6):
    "x-amz-content-sha256": await sha256Hex(body),
  },
  body: JSON.stringify({ prompt: code }),
});

const reader = res.body.getReader();
const decoder = new TextDecoder();
let buffer = "";
while (true) {
  const { done, value } = await reader.read();
  if (done) break;
  buffer += decoder.decode(value, { stream: true });
  const frames = buffer.split("\n\n");
  buffer = frames.pop();                 // keep any partial frame
  for (const frame of frames) {
    const line = frame.split("\n").find((l) => l.startsWith("data:"));
    if (line) onToken(JSON.parse(line.slice(5).trim()));  // append token to the page
  }
}

Two things to remember: the server requires Accept: text/event-stream (without it you get a JSON error, not a stream), and the response is a stream of token strings, not one JSON blob. That's what makes the roast type out live, like the duck is thinking. Locally the frontend detects localhost and skips CloudFront, talking straight to agentcore dev on port 8080.

One safety note since you're injecting model output into the page: escape everything before you format any Markdown. A dozen lines of regex handles bold and code fences without letting raw HTML through.

Step 8: Put it on the internet with GitHub Pages

Push to GitHub, then Settings → Pages → Deploy from branch main, folder /. A minute later your duck is live. HTTPS, free, auto-deploying on every push. Point a custom domain at it (I use unducked.com), set the frontend's production endpoint to your CloudFront URL, and you've got a product.

git clone https://github.com/tmoreton/tutorials
open tutorials/index.html

Watch the bill: cost controls for a public AI endpoint

The endpoint is public and unauthenticated, so anyone with the URL can spend your Bedrock tokens. Nova Lite is cheap (a fraction of a cent per roast), but a viral moment shouldn't become a surprise invoice, so at minimum:

Set a reserved-concurrency cap on the Lambda (I use 2). That's a hard ceiling on how fast anyone can burn tokens.
Add an AWS budget alarm so you find out early.

Rate limiting and WAF: locking it down without a login wall

The whole appeal of Unducked is that you click a link and roast some code, no signup, no API key. That's also the problem: a public, unauthenticated endpoint is a standing invitation for someone to script a loop against it, drain your token budget, and lock everyone else out. The goal is to make that expensive and annoying for an abuser while staying frictionless for a real visitor. Here's the stack of defenses I settled on, cheapest first. None of them ask the user to sign in.

1. Cap the input size (already in the proxy). The single biggest lever on cost is how many tokens each request carries. A roast needs a snippet, not a novel, so the proxy truncates the prompt before it ever reaches Bedrock:

const MAX_PROMPT_CHARS = parseInt(process.env.MAX_PROMPT_CHARS ?? '8000');
// ...
const prompt = (body.prompt ?? '').slice(0, MAX_PROMPT_CHARS);

That one line turns "paste a 2 MB file and cost me dollars" into a non-event. It also bounds output indirectly because the system prompt already tells the duck to keep it tight.

2. Reserved concurrency is your circuit breaker. The Lambda cap from above isn't just about tokens; it's the ceiling on total throughput. With a reserved concurrency of 2, there is no amount of traffic that makes the bill run away; excess requests get throttled at the proxy, not billed at Bedrock. Set it deliberately low and treat it as the backstop behind everything else.

3. Put AWS WAF in front of CloudFront. This is the real fix. WAF (Web Application Firewall) is a rules engine that sits in front of your CloudFront distribution and inspects every request before it reaches your origin. Nothing changes in your Lambda or your frontend; you attach a "Web ACL" (a bundle of rules) to the distribution and CloudFront enforces it. For a public toy the one rule that matters is a rate limit, and it needs no login:

Rate-based rule, keyed by client IP. WAF counts requests per IP over a rolling window (1, 2, 5, or 10 minutes) and acts on anyone over the limit. The floor is 100 requests per 5 minutes, well above a human clicking "Roast it," far below a script in a loop.
Challenge action instead of a hard block. Rather than returning 403, set the over-limit action to Challenge (or CAPTCHA). WAF serves a silent browser proof-of-work that a real browser passes invisibly but a curl loop or headless scraper fails. The challenge only fires on requests above the rate limit, so normal visitors stay under it and never see anything. This is the closest you get to "login-grade" protection with zero friction.
Geo or bot-control rules if you want to go further. The AWS Managed Rules bot-control group catches common scrapers, though it adds cost.

To enable it, in the WAF console: create a Web ACL, set Resource type → CloudFront distributions, associate your distribution, add a rate-based rule (limit 100, aggregate on source IP, evaluation window 5 minutes), set its action to Challenge, and save. Or the one CLI call that does the same thing (CloudFront Web ACLs live in us-east-1):

aws wafv2 create-web-acl \
  --name unducked-rate-limit --scope CLOUDFRONT --region us-east-1 \
  --default-action Allow={} \
  --visibility-config SampledRequestsEnabled=true,CloudWatchMetricsEnabled=true,MetricName=unducked \
  --rules '[{"Name":"rate-per-ip","Priority":0,
    "Statement":{"RateBasedStatement":{"Limit":100,"AggregateKeyType":"IP","EvaluationWindowSec":300}},
    "Action":{"Challenge":{}},
    "VisibilityConfig":{"SampledRequestsEnabled":true,"CloudWatchMetricsEnabled":true,"MetricName":"rate-per-ip"}}]'
# then associate the returned Web ACL ARN with the distribution (set it as the distribution's WebACLId)

That's exactly what's guarding unducked.com right now. WAF's own logs and CloudWatch metrics then show you who got challenged, so you can watch for abuse without watching the bill.

4. Keep CORS locked to your origin. The proxy already restricts Access-Control-Allow-Origin to https://unducked.com. It won't stop a determined attacker (CORS is browser-enforced, and curl ignores it), but it stops the lazy case where someone embeds your endpoint from their own site.

The honest limit: without authentication you can't make abuse impossible, only uneconomical. But layering all four (an input cap, a hard concurrency ceiling of 2, a WAF rate-limit-plus-challenge, and CORS locked to the origin) is exactly what's live on unducked.com, and together they mean a casual attacker bounces off while a real visitor never notices a thing. A budget alarm catches anything that slips through. If it ever went truly viral-with-a-target-on-its-back, the next step would be a lightweight anonymous token (a per-session nonce your page mints), but for a code-roasting duck that's overkill.

The full picture: architecture summary

Layer	What	How
Personality	A system prompt	The whole product, really
Model	Amazon Nova Lite	Amazon Bedrock
Agent	~30 lines of TypeScript	Strands Agents SDK + AgentCore
Backend hosting	`agentcore deploy`	AgentCore Runtime
Public endpoint	Streaming Lambda + CloudFront	Signs requests for the browser
Frontend hosting	Push to GitHub	GitHub Pages

The lesson underneath the jokes: a capable model plus a sharp system prompt is a shippable product, and the AI is the cheap part. The fiddly work is the plumbing that makes it public and safe. Change the prompt and Chef Duck becomes a patient mentor, a passive-aggressive senior dev, or a security auditor. Same stack, same afternoon.

Source code

The complete code is on GitHub →

Go roast some code. Your duck is disappointed in you already.

Ship Your Own Social Listening Agent in ~200 Lines of TypeScript

Tim Moreton — Fri, 17 Jul 2026 14:37:39 +0000

Meet SocialRadar: a daily and weekly research agent built with the Strands SDK, Bedrock AgentCore, and EventBridge Scheduler.

Here's the situation. You ship a developer tool. People are talking about it on X, Reddit, Hacker News, random Medium posts at 2 a.m., and you want to know what they're saying.

Are they happy?
Confused?
Are they comparing you to a competitor and picking the competitor?

Ideally you'd like to know today, not when someone forwards you a screenshot next week.

The enterprise answer is "buy a social-listening platform."

The engineer answer is "let AI cook."

This post walks through building the second thing. We'll build SocialRadar — an agent that researches mentions of a topic across the web, figures out the sentiment per platform, checks how you stack up against competitors, and emails you a tidy brief. On a schedule. Without a laptop that has to stay open.

We'll use the Strands Agents TypeScript SDK for the agent, Amazon Bedrock AgentCore Runtime to host it, Amazon EventBridge Scheduler to run it daily and weekly, and Amazon Simple Email Service (Amazon SES) to deliver the email.

Why AWS for everything? Because the scheduler and email service live on the same platform, no signing up for three or four separate services just to get a cron job and an inbox.

Total moving parts: a model, two tools, a prompt, and about a dozen lines of infrastructure. Let's go.

What you'll need: Node.js 20+ and an AWS account

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.5/install.sh | bash
aws login

The mental model: an agent is a model + tools + a prompt

I picked Strands for its simplicity, the pitch is that an agent is just a model, some tools, and a prompt, running in a loop until the job's done. The model does the thinking and decides which tools to call; you don't write the orchestration, you describe the goal and hand it capabilities. You're relying on the intelligence of the model here, and as models get smarter, so does your agent.

For our application:

Model — Claude Sonnet on Bedrock. The brain.
Tools — webSearch (bundled with Exa search by default) and sendEmail.
Prompt — "go find out what people think about $THING and email me a brief." (With a lot more detail, but that's the gist.)

Everything below is just filling in those blanks.

Step 1: Scaffold the project

Create an AgentCore project. This gives you a runtime definition, a place for config, and a CDK app for the AWS bits.

npm install -g @aws/agentcore
agentcore create agentjs
cd agentjs

If you want to customize the agent, here are some extra params it can be built with:

agentcore create --name SocialRadar --framework Strands --protocol HTTP --model-provider Bedrock --memory none

You get an app/agentjs/ folder for your code and an agentcore/ folder for config and infrastructure. Keep that split in your head — app/ is what the agent does; agentcore/ is how it gets deployed and triggered. It matters later.

Step 2: Give it a brain and eyes

Two tiny files. First, the model (app/agentjs/model.ts):

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

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

That's the whole thing. Swap the modelId if you want a different model — the rest of the code doesn't care.

Now, exposing it to the world wide web. An agent that can't see the internet can't do research, so we give it web search via a Model Context Protocol (MCP) server. MCP is a standard way to plug tools into agents, and Exa runs a hosted one that does web search and crawling with no auth required (sticking to the "don't sign up for 10 services" plan). Perfect for a prototype (app/agentjs/mcp.ts):

import { McpClient } from '@strands-agents/sdk';
import { StreamableHTTPClientTransport } from '@modelcontextprotocol/sdk/client/streamableHttp.js';

export function getStreamableHttpMcpClient(): McpClient {
  const transport = new StreamableHTTPClientTransport(new URL('https://mcp.exa.ai/mcp'));
  return new McpClient({ transport });
}

The agent now has a way to search. It doesn't know how to use it yet, but the capability is wired.

Heads up (learned the hard way): the free hosted Exa endpoint rate-limits bursts. If your prompt tells the model to fire off 12 searches as fast as it can, you'll get throttled mid-run. We deal with this in the prompt later. File it away.

Step 3: Teach it to send email

Here's the part that actually sold me on using AWS for this particular agent: email is notoriously cumbersome to set up, but this was surprisingly straightforward. (Keep in mind you need access to verify the email account you're sending to.)

Here's the whole snippet for a new send_email tool:

import { SESv2Client, SendEmailCommand } from '@aws-sdk/client-sesv2';
import { tool } from '@strands-agents/sdk';
import { z } from 'zod';

const ses = new SESv2Client({ region: process.env.AWS_REGION ?? 'us-east-1' });

export const sendEmail = tool({
  name: 'send_email',
  description: 'Send an email via Amazon SES. Use this to deliver the finished brief.',
  inputSchema: z.object({
    subject: z.string(),
    body: z.string(),
  }),
  callback: async ({ subject, body }) => {
    const res = await ses.send(new SendEmailCommand({
      FromEmailAddress: process.env.DIGEST_SENDER,
      Destination: { ToAddresses: [process.env.DIGEST_RECIPIENT!] },
      Content: { Simple: { Subject: { Data: subject }, Body: { Html: { Data: body } } } },
    }));
    return `Sent (messageId: ${res.MessageId}).`;
  },
});

The Zod schema gives the model a typed contract for the tool — it knows it must produce a subject and a body — and gives you runtime validation for free.

Now the leak. AgentCore's declarative config (agentcore.json) can describe your runtime, your Node version, your environment variables… but it has no field for "this runtime is allowed to send email." That's an AWS Identity and Access Management (IAM) permission, and it lives on the runtime's execution role. So you grant it by hand in the CDK stack (agentcore/cdk/lib/cdk-stack.ts):

for (const env of this.application.environments.values()) {
  env.runtime.addToPolicy(new iam.PolicyStatement({
    actions: ['ses:SendEmail', 'ses:SendRawEmail'],
    resources: [`arn:aws:ses:${this.region}:${this.account}:identity/*`],
  }));
}

Without that grant, the send_email tool compiles fine, deploys fine, runs fine — and then returns AccessDenied at the worst possible moment. Ask me how I know. (AI came to the rescue debugging that one.)

The sender and recipient come from environment variables set in agentcore.json:

"envVars": [
  { "name": "DIGEST_SENDER", "value": "you@example.com" },
  { "name": "DIGEST_RECIPIENT", "value": "you@example.com" }
]

One-time SES setup: SES will not send from an address it hasn't verified. Verify yours:

aws sesv2 create-email-identity --email-identity you@example.com --region us-east-1
# click the link SES emails you, then:
aws sesv2 get-email-identity --email-identity you@example.com --region us-east-1

Two gotchas the docs are quiet about:

Sandbox. New SES accounts are sandboxed — you can only send to verified addresses. Great for a self-addressed brief; you'll need to request production access to email your teammates.

DMARC. If you send from an address on a domain you don't control the mail auth for, the recipient's mail server will slap a "this might be spoofed" banner on it.

Step 4: The prompt

The prompt is where you come in and customize. I've added a basic version here as an example, but you'll certainly want to build it out further (app/agentjs/prompt.ts).

Two callouts to keep in mind:

setTimeout() Exa will rate-limit you if you try to run 100 searches at once — but no worries, since the idea is a daily or weekly email, we can afford to take our time. Space out the searches so we don't hit that limit. Again, ask me how I know about the limit.

429's A cool future feature would be to add social-platform-specific APIs, but some platforms block scraping requests. For now, plain web search won't catch everything, but it's a good start.

Step 5: "What day is it?"

The model has no clock. If you don't tell it the date, it will confidently guess wrong. Mine emailed a brief dated two months in the past.

const tools = [sendEmail, ...mcpClients];

const today = new Intl.DateTimeFormat('en-US', {
  timeZone: 'America/New_York', weekday: 'long', year: 'numeric', month: 'long', day: 'numeric',
}).format(new Date());

const mode = payload.mode === 'weekly' ? 'weekly' : 'daily';   // schedules send this
const prompt = `Today is ${today}. ${KICKOFF[mode]}`;

The mode lets one agent produce both a fast **daily* brief and a heftier weekly review, chosen by the payload.*

Step 6: Deploy

cd app/agentjs && npm install && npm run build
cd ../.. && agentcore deploy --target dev -y

agentcore deploy synthesizes the CDK, provisions the runtime, attaches that SES grant, and (next step) sets up the schedules. If the TypeScript doesn't compile, the deploy stops, which is a feature, not a bug.

Step 7: Run it on a schedule (the second reason to run it on AWS)

Same story as SES: AgentCore's declarative config has no "run this on a cron" field, so scheduling lives in the CDK stack. But here's the trap that cost me a full afternoon: you can't point EventBridge Scheduler straight at the runtime.

The obvious move is a Scheduler "universal target" calling InvokeAgentRuntime directly. It deploys fine, looks right… and silently never fires. Why: the AgentCore runtime responds as a stream (Server-Sent Events), and Scheduler's universal target can't consume a streaming response, so the call errors before the runtime ever runs — with no email and, without a DLQ, no trace. I shipped this, "confirmed" it with manual agentcore invoke tests that worked, and only later realized the cron had never once succeeded on its own.

The fix: a tiny invoker Lambda in between. It calls InvokeAgentRuntime and drains the stream to completion — exactly what agentcore invoke does under the hood — keeping the request open long enough for the agent to finish and send the email. Scheduler triggers the Lambda; the Lambda talks to the runtime.

// invoker Lambda handler (bundled from lib/runtime-invoker.ts)
import { BedrockAgentCoreClient, InvokeAgentRuntimeCommand } from '@aws-sdk/client-bedrock-agentcore';
const client = new BedrockAgentCoreClient({});

export async function handler(event: { mode?: string } = {}) {
  const mode = event.mode === 'weekly' ? 'weekly' : 'daily';
  const res = await client.send(new InvokeAgentRuntimeCommand({
    agentRuntimeArn: process.env.AGENT_RUNTIME_ARN!,
    runtimeSessionId: `sched-${mode}-${Date.now()}`.padEnd(33, '0'), // needs 33+ chars
    contentType: 'application/json',
    accept: 'text/event-stream',                                     // the runtime streams SSE
    payload: new TextEncoder().encode(JSON.stringify({ mode })),
  }));
  await res.response?.transformToString(); // DRAIN the stream so the runtime finishes + emails
}

Then the schedules target the Lambda (not the runtime), with a dead-letter queue so failures are never invisible again (agentcore/cdk/lib/cdk-stack.ts):

const invoker = new NodejsFunction(this, `${cdkId}Invoker`, {
  entry: 'lib/runtime-invoker.ts', handler: 'handler',
  runtime: lambda.Runtime.NODEJS_22_X,
  timeout: Duration.seconds(300),                 // weekly briefs take a few minutes
  environment: { AGENT_RUNTIME_ARN: env.runtime.runtimeArn },
  bundling: { externalModules: [] },              // bundle the bedrock-agentcore client
});
env.runtime.grantInvoke(invoker);
invoker.addToRolePolicy(new iam.PolicyStatement({ // InvokeAgentRuntime checks the endpoint sub-resource
  actions: ['bedrock-agentcore:InvokeAgentRuntime'],
  resources: [env.runtime.runtimeArn, `${env.runtime.runtimeArn}/*`],
}));

const dlq = new sqs.Queue(this, `${cdkId}Dlq`);
for (const { suffix, mode, cron } of SCHEDULES) {
  new scheduler.CfnSchedule(this, `${cdkId}${suffix}`, {
    flexibleTimeWindow: { mode: 'OFF' },
    scheduleExpression: cron,                      // UTC! 13:00 UTC ≈ 9am US Eastern
    target: {
      arn: invoker.functionArn,
      roleArn: schedulerRole.roleArn,
      input: JSON.stringify({ mode }),
      deadLetterConfig: { arn: dlq.queueArn },
    },
  });
}

Four things that cost me time so they don't cost you:

Don't point Scheduler at a streaming runtime. Universal targets can't drain SSE — put a Lambda in between. This is the whole reason this section exists.
The crons are UTC. 13:00 UTC ≈ 09:00 US Eastern.
InvokeAgentRuntime needs a 33+ char session id AND permission on the …/runtime-endpoint/DEFAULT sub-resource — grant runtimeArn and runtimeArn/*, or you get AccessDenied.
Add a dead-letter queue. With no DLQ, a failing schedule fails silently — no error, no email, no clue. Ask me how I know.

Change the cadence by editing the array and redeploying.

Step 8: Trigger it yourself

agentcore invoke --target dev --prompt "daily"    # daily brief, right now
agentcore invoke --target dev --prompt "weekly"   # weekly review
agentcore invoke --target dev --prompt "what's the latest Strands sentiment on Reddit?"  # ad-hoc

Each run does the full research pass and lands an email in ~1–2 minutes. Watch the logs with agentcore logs --target dev.

Verify SES actually sent something — either check your inbox or run:

aws ses get-send-statistics --region us-east-1   # DeliveryAttempts should tick up; Rejects should be 0

The honest gotchas list

Because a tutorial that only shows the happy path is marketing, not engineering:

The model has no clock. Inject the date. (Said it twice on purpose.)
SES sandbox limits you to verified recipients until you request production access.
DMARC will flag mail sent "From" a domain you don't own. Fine for self-sends, not for your team.
Exa's free tier throttles bursts. Pace searches in the prompt, or bring your own key / a provider like Tavily.
Long runs hit a wall. A synchronous streamed invocation gets cut at ~2 minutes. If a brief balloons (a busy week, tons of results), the model can spend longer than that generating the email body and get killed before it sends. Keep briefs tight (cap items per section), or move big jobs to an async invocation.
Scheduler fails silently. EventBridge Scheduler with no dead-letter queue drops failed invocations into the void — no error, no email, no clue. Add a DLQ (or at least a CloudWatch alarm on TargetErrorCount) so a broken schedule pages you instead of quietly ghosting you for three days.
Two things live in CDK, not the tidy config: the SES IAM grant and the cron schedules. If you're looking for them in agentcore.json, you'll look forever — they're in cdk-stack.ts.

Where to take it next

This is a starting point, and a fun one. Some directions:

Swap Exa for a keyed search provider if you outgrow the free tier.
Build platform-specific tools. Generic web search is a good start, but it can't see everything — plenty of platforms block scraping outright. Wiring up the actual APIs gets you structured, higher-fidelity data instead: the YouTube Data API for video and comment sentiment, the X (Twitter) API v2 for real-time mentions and reply threads, Reddit's API for subreddit- and thread-level tracking. Each is just another Strands tool alongside send_email — but each also brings its own auth, quotas, and rate limits to manage, so budget time for that per platform.
Cross-reference a second data source — the agent happily merges and de-duplicates against, say, an exported social report.
Two-way email — reply to the brief and have the agent research your follow-up. (Amazon SES can receive mail too, but you'll need a custom domain to set that up.)

The pattern underneath — model + tools + prompt, deployed on a schedule, delivering to a person is very general. Daily standup report. Competitive watch. On-call digest. Once you've built one, you'll see them everywhere.

Full source and a step-by-step README in the repo.