DEV Community: Tim Moreton

Build Your Own AI Chat App in 30 min

Tim Moreton — Mon, 27 Jul 2026 20:50:10 +0000

Every developer's first website was Hello World. Some HTML, maybe a CSS file, deploy it somewhere, and you get that rush of seeing your thing live on the internet.

With AI, the new Hello World is a chat app.

You still start with a basic index.html. But instead of static text, you wire it up to a backend AI and suddenly you've got something that actually talks back. That's what we're building today.

The stack: Strands SDK for the agent, AgentCore to host it on AWS, Bedrock for model selection, and a simple HTML frontend that hits a proxy to talk to the AI. One TypeScript file, a few CLI commands, and an index.html.

By the end, you'll have a working chat interface backed by a model on Amazon Bedrock (we'll use the ultra-cheap Amazon Nova Micro), deployed to a hosted endpoint, costing fractions of a cent per conversation. And it's the foundation for everything that comes next: memory, authentication, document Q&A, guardrails. But today we keep it dead simple.

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

Before we touch code, here's what we're building:

Browser (HTML + JS) → AgentCore Runtime (hosted endpoint) → Strands Agent → Bedrock (Nova Micro)

You write a Strands agent in TypeScript. The AgentCore CLI deploys it as a hosted endpoint. Your frontend sends messages to that endpoint.

No Lambda functions. No API Gateway. No Docker. Just TypeScript and a couple CLI commands.

Step 1: Set up your environment

You'll need an AWS account, Node.js 22+, and npm.

The fast path: If you use a coding agent (Claude Code, Cursor, Kiro, Codex), the Agent Toolkit for AWS handles credentials, CLI tools, and all of the below for you. Just ask your agent to set up AWS access and it'll run through the steps.

# Your coding agent will run something like:
aws configure agent-toolkit

Or, do it manually:

Configure your AWS credentials:

# Install the AWS CLI (if you don't have it)
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip && sudo ./aws/install

# Configure your credentials
aws configure
# (enter your Access Key ID, Secret Access Key, region, output format)

# Verify it works
aws sts get-caller-identity

Once your credentials are set, install the AgentCore CLI and the AWS CDK (AgentCore uses CDK under the hood to deploy your infrastructure):

# The AgentCore CLI
npm install -g @aws/agentcore

# AWS CDK (needed for deployment)
npm install -g aws-cdk

That's your toolchain.

Step 2: Scaffold the project

One command scaffolds the entire project:

agentcore create --name MyAgent --no-agent
cd MyAgent
agentcore add agent \
  --name MyAgent \
  --type create \
  --build CodeZip \
  --language TypeScript \
  --framework Strands \
  --model-provider Bedrock \
  --memory none

What each flag does:

--name – The project/agent name (alphanumeric, starts with a letter, max 36 characters).
--build – The deployment artifact type. CodeZip means direct code deployment (no Docker).
--framework – The agent framework. Supported values: Strands, LangChain_LangGraph, GoogleADK, OpenAIAgents.
--language – The language for generated code. Supported values: TypeScript, Python.
--model-provider – The model provider. Supported values: Bedrock, Anthropic, OpenAI, Gemini.
--memory – Memory configuration. Supported values: none, shortTerm, longAndShortTerm.

Or skip the flags entirely and run agentcore create with no arguments. It launches an interactive wizard that walks you through each option.

You get this structure:

MyAgent/
├── agentcore/
│   ├── agentcore.json        # Project config
│   └── aws-targets.json      # Account + region
└── app/
    └── MyAgent/
        ├── main.ts           # Your agent ← this is the file that matters
        ├── model/load.ts     # Which Bedrock model to use
        ├── package.json      # Dependencies
        └── tsconfig.json

Step 3: Write the agent

The scaffold gives you a working agent out of the box.

// app/MyAgent/main.ts

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

const agent = new Agent({
  model: await loadModel(),
  systemPrompt: 'You are a helpful AI assistant. Be concise and direct.',
});

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

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

That's the whole thing. ~20 lines.

Three pieces:

Create an agent with a model and a system prompt.
Wire it to the server using BedrockAgentCoreApp, which handles the HTTP endpoints the runtime expects.
Stream tokens back by iterating over agent.stream() and yielding each text delta.

loadModel() points at Amazon Nova Micro by default (Bedrock's cheapest text model, fractions of a cent per conversation). Swap the model ID in model/load.ts if you want Claude Sonnet or something heavier. The full version in the repo adds per-session caching so each conversation keeps its own history, but this is all you need to get a response streaming.

Step 4: Test locally

Before deploying anywhere, run it on your machine:

agentcore dev

In a separate terminal:

agentcore dev "What is the capital of France?"

This installs dependencies, compiles TypeScript, and starts a local server on port 8080. It also opens a browser-based inspector where you can chat with your agent. You should see the response stream back in the second terminal. If that works, your agent runs.

First run takes a moment while it pulls packages and compiles. After that it's near-instant with hot reload.

Step 5: Deploy to AWS

One command:

agentcore deploy

The CLI:

Compiles TypeScript and packages it as a CodeZip archive
Uses CDK to synthesize and deploy CloudFormation (Infrastructure as Code) resources
Creates IAM roles and an AgentCore Runtime endpoint
Configures CloudWatch logging

First deploy takes a few minutes while CDK bootstraps your account. Subsequent deploys are faster. You can run agentcore deploy --dry-run to preview changes without deploying.

Test your deployed agent:

agentcore invoke "Hello! What can you help me with?"

Stream the response in real time:

agentcore invoke "Tell me a joke" --stream

If you see a response, your agent is live on AWS.

Step 6: The frontend

One HTML file. No build step. No npm install.

During local development, this frontend talks to your dev server (agentcore dev on port 8080). For production, the repo includes a Lambda proxy that handles SigV4 signing so browsers can reach the deployed agent. Step 7 covers that.

The core of the frontend is one function:

// Call your agent and stream the response
async function send(text, onToken) {
  const res = await fetch("http://localhost:8080/invocations", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "Accept": "text/event-stream", // required: the agent streams SSE
      "X-Amzn-Bedrock-AgentCore-Runtime-Session-Id": sessionId, // keeps chat history
    },
    body: JSON.stringify({ prompt: text }),
  });

  // The response is a Server-Sent Events stream: `data: "token"` frames.
  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 events = buffer.split("\n\n");
    buffer = events.pop(); // keep any partial frame for the next read
    for (const evt of events) {
      const line = evt.split("\n").find((l) => l.startsWith("data:"));
      if (line) onToken(JSON.parse(line.slice(5).trim()));
    }
  }
}

Two things bit me here, so they're worth calling out. The server requires the Accept: text/event-stream header. Without it, you get a JSON error object instead of a stream. And the response isn't a single JSON blob. It's an SSE stream of JSON-encoded token strings. In exchange, you get ChatGPT-style token-by-token rendering for free.

The rest is just HTML and CSS to make it look like a chat window. The full index.html (dark theme, chat bubbles, enter-to-send) is in the repo. Clone it, run agentcore dev, open the file in your browser. That's your ChatGPT.

# Grab the frontend
git clone https://github.com/tmoreton/tutorials
open tutorials/index.html

Step 7: Deploy the frontend with GitHub Pages

Push your repo to GitHub:

git init
git add .
git commit -m "initial commit"
git remote add origin git@github.com:YOUR_USERNAME/my-ai-chat.git
git push -u origin main

Then go to your repo on GitHub, click Settings > Pages, set the source to "Deploy from a branch", pick main and / (root), and hit Save:

Give it a minute and your app is live at https://YOUR_USERNAME.github.io/my-ai-chat. HTTPS, free hosting, auto-deploys on every push.

The repo includes a small streaming Lambda proxy behind CloudFront (proxy/) that signs requests to the AgentCore Runtime on behalf of the browser. The hosted frontend talks to this proxy instead of localhost. Deploy it with cd proxy && cdk deploy and update the ENDPOINT constant in index.html to your CloudFront URL.

The CloudFront OAC setup has a couple wrinkles: the x-amz-content-sha256 header and the double invoke permission. The proxy README walks through both. That cost me an afternoon so you don't repeat it.

A few things to keep in mind

The response is a stream, not JSON. The agent server speaks Server-Sent Events and requires the Accept: text/event-stream header. If your frontend tries res.json() expecting a neat {result: "..."} object, you'll get an error back instead. You need to read the stream (see Step 6).

The deployed endpoint is only reachable through the proxy. AgentCore requires SigV4-signed requests, which browsers can't do natively. That's what the Lambda proxy in proxy/ handles for you. Don't try to sign from client-side JS. You'd be shipping AWS credentials in page source.

Limit concurrent calls. This endpoint is unauthenticated, which means anyone with the URL can hit it. Set a concurrency limit on the Lambda proxy or add throttling in CloudFront so you don't wake up to a surprise bill.

The full picture

Layer	What	How
Model	Amazon Nova Micro (swappable)	Amazon Bedrock
Agent	~40 lines of TypeScript	Strands Agents SDK + AgentCore app server
Backend hosting	`agentcore deploy`	AgentCore Runtime
Frontend hosting	Push to GitHub	GitHub Pages + CloudFront proxy

Right now conversation history lives in memory, so it disappears if the process restarts. Next post, we'll add AgentCore Memory for durable persistence across sessions and restarts.

Clean up

If you want to tear down the AWS resources when you're done:

agentcore remove all
agentcore deploy

The first command resets your config. The second deploys the empty state, which tears down the CloudFormation stack.

Source

The complete code for this tutorial is on GitHub →

If this was useful, follow along. The next post drops next week.

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.