I want an AI agent that works for me. I want it to search up the latest news, and I want it to deliver it to me in a daily message. I want to chat ...
For further actions, you may consider blocking this person and/or reporting abuse
Your pursuit of a 'controlled' AI agent is key. While Bedrock AgentCore shines for general tasks, true agent mastery in specialized domains demands granular control beyond typical managed services.\n\nConsider a drug interaction agent for India.
The Reddit RSS detail is the actual lesson. Half of building agents is figuring out which sites will let you in and which will 403 you forever. Nobody writes the tutorial about that part.
Yes that happens a lot! You have to be able to get around it. Websites are actively blocking agents, making this much harder.
Let me know what you think?
Great post!
Thanks!
The EventBridge + memory pattern feels like the right baseline for this.
One thing I'd separate early is "scheduled digest" vs "watch for changes". A daily news summary makes sense on a timer, but a lot of butler-style tasks are better as registered watches: define the source/event/filter once, keep the cursor/checkpoint outside the agent, and only wake the agent when something matches.
That also makes the annoying production questions cleaner: what did it already process, did this run retry, did the scraper fail, and why did the agent wake up at all?
Scheduled agents are great until the cloud bill arrives. Running a lightweight local agent on Apple Silicon for routine tasks (file organization, GUI automation, periodic checks) costs exactly $0 in inference after initial setup. The "butler" metaphor works even better when the butler lives in your house, not in someone else's data center. For tasks that need reasoning power, routing to a cloud model on-demand keeps costs predictable.
Great walkthrough of the AgentCore harness approach. The "define in config + system prompt, then deploy" model is a really clean abstraction for scheduled agents.
One thing I have been thinking about with scheduled agents is the cold-start problem — the agent loses conversational context between runs, so the first message of each run needs to re-establish enough state to be useful. Your use of AgentCore Memory for persisting context across runs is the right approach. I have been using a similar pattern where each run writes a structured "session summary" to a persistent store, and the next run loads it as context. The key is keeping those summaries compact — if they grow unbounded, you eventually hit context window limits.
Curious how you handle failures in the web scraping layer. HN and Reddit pages can change structure unexpectedly — do you have retry logic or fallback data sources, or does the agent just report the failure in its digest?
Persistent autonomy is where agents get actually useful beyond the chat window. The scheduling pattern is solid, but the harder engineering problem is state management between runs — how does the agent remember what it already processed yesterday vs. what's new? A lightweight checkpoint/journal approach (append-only log + periodic compaction) scales better than dumping full state into the LLM context every run.
Nice walkthrough. The part I liked most was the practical explanation of why a harness beats a plain Lambda for this kind of job: real browser control, persistent state in /mnt/data, and enough runtime to do multi-step summarization without awkward glue code. That tradeoff gets missed a lot in agent demos. Also appreciated that you showed the scheduler + memory pattern instead of stopping at a toy chat loop — it feels much closer to how useful AI assistants will actually run in production.
This is a great breakdown. I particularly appreciated the sections on scraping because I find it's the messiest part of building autonomous agents sometimes. Your approach to handling dynamic content was very helpful. I also found the insight around cost management and leveraging EventBridge a good tip. Is there anything else since that you've learned to enable scaling this more? Thanks!
Scheduled agents are one of those patterns that look clean in the demo and bite you in production. The two things that always surface: idempotency when a run fires twice from a transient retry, and visibility into what the agent actually did between runs. Worth wiring CloudWatch alarms on action counts and tool-call diffs before you trust it unattended.