Weekend Agent Challenge: Kiro Pulse
Kiro Pulse is an always-on agent that keeps you current on the Kiro ecosystem. Every week it wakes up in the cloud, sweeps dev.to, Medium, and the AWS Builder Center for fresh Kiro content, and drafts a clean, readable digest of what the community is building and discussing. This weekend's challenge asked for an agent that runs without you, and Kiro Pulse takes that literally: no laptop to open, no script to remember. It runs on its own schedule and delivers a finished roundup.
Vision and what the agent does
Kiro Pulse wakes up at 07:30 every morning, before I do, and checks three sources for new Kiro content: the dev.to public API, the AWS Builder Center Atom feed, and Medium tag RSS. None of them need an API key, which kept the whole thing simple.
Then it gets picky:
- DynamoDB remembers every URL the agent has ever seen, so only genuinely new posts move forward
- Bedrock Nova 2 Lite reads the new ones, throws out false positives ("kiro" is also restaurants and people), ranks the rest, and writes a short summary plus a "why it matters" note for each
- SES sends me the digest as a small HTML email
And the part I care about most: on a quiet day, it sends nothing. No "your daily report: 0 items" noise. If there's an email, something actually happened.
There's a reason daily beats weekly here, and I learned it the hard way on the old project. The Builder Center feed only holds the ~30 latest posts site-wide. At the site's volume, most of a week rolls off the feed before a weekly scrape ever runs. A daily agent never lets anything fall off the edge. My laptop can't do that. It's asleep when I am.
How I built it
The whole build took one evening, and two decisions did most of the work.
Decision 1: pure Python standard library. The Lambda uses urllib for HTTP, xml.etree for the feeds, and boto3 (already in the runtime) for AWS. No requests, no feedparser, no packaging step, no layers. CDK zips the source folder as-is, so anyone who clones the repo can deploy without building anything.
Decision 2: never trust the model to return clean JSON. My first live triage call came back with a malformed reply and my parser fell over. Classic. The fix has three layers:
- The prompt demands a bare JSON object with short summaries
- The parser tolerates markdown fences and retries once on garbage
- If both attempts fail, the agent sends an untriaged list instead of crashing
A worse email beats no email.
CDK also fought back once. EventBridge Scheduler cron refuses to take both a day-of-month and a day-of-week value, so
30 7 * * ? * needs the ? mapped to undefined before it synthesizes. Twenty minutes of my life, so you don't lose yours.One more thing, because the repo is open source: my email lives in a gitignored
config.local.json, and the committed example ships with a placeholder. Before pushing I grepped the staged content for my address and account ID. Clean.AWS services used and architecture
1
2
3
4
5
6
7
8
9
10
11
EventBridge Scheduler (daily cron, timezone-aware)
|
v
Lambda (Python 3.13) --- fetch: dev.to API + Builder Center Atom + Medium RSS
|
|-- DynamoDB: skip every URL already seen
|-- Bedrock Nova 2 Lite: reject, rank, summarize, write the digest
|-- SES: send the email, only if something new survived triage
|
v
CloudWatch Logs: every run recordedSix services, all inside the Free Tier:
| Service | Role |
|---|---|
| EventBridge Scheduler | The trigger. Fires the agent every morning |
| Lambda | Runs the whole pipeline |
| DynamoDB | The memory (seen URLs, pay-per-request) |
| Bedrock (Nova 2 Lite) | The judgment: triage, ranking, summaries |
| SES | The voice: sends the digest |
| CloudWatch Logs | The receipt that it ran while I slept |
Everything deploys with one
cdk deploy. The only manual step is clicking the SES verification link, since sender and recipient are the same address, sandbox mode is all you need.What I learned
EventBridge Scheduler is nicer than the old CloudWatch Events rules. Timezone-aware cron means 07:30 stays 07:30 after the clocks change, and the console shows the next fire time, which makes "prove it runs alone" trivial.
Small models are enough for triage. Nova 2 Lite surprised me here. In my first test it correctly rejected a spec-driven-development post that only mentioned Kiro in passing, something my old keyword filter would have kept. Each run costs about a tenth of a cent.
Where automation lives matters more than what it does. I had already written most of this logic months ago, and it still wasn't working for me, because it ran on a machine that sleeps. Moving the trigger from "me" to "a schedule in the cloud" turned a tool I use into a thing that works for me. That gap is the whole point of this challenge.
What I'm doing next
The pipeline is topic-agnostic. Change the keywords in the config and the feed list in one file, and it's a daily pulse on anything: your favorite framework, your niche, your competitors. I'm also thinking about a weekly "best of" mode that reuses the DynamoDB history, since the agent already remembers everything it has seen.
Link to the repo
Clone it, put your email in
config.local.json, run cdk deploy, and tomorrow morning your inbox will know something you don't yet.Are you already watching a topic like this by hand, opening the same tabs every morning? What would you point an agent like this at? Share it in the comments.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article