Blogger Bear

BloggerBear is an autonomous, multi-domain research-and-publishing platform on AWS serverless. Alexa+ will help me run or query the platform for investigation purposes.

Comment

Blogger Bear: An Autonomous, Multi-Domain Research-and-Publishing Platform on AWS 🐾

Inspiration🐾

As an IT professional currently working within support roles, I have always enjoyed working with AWS resources, but my daily responsibilities rarely give me the freedom to truly build and develop cloud-native applications from scratch. This hackathon presented the ultimate opportunity to bridge that gap. I wanted to launch a real, live, complex project of my own (bloggerbear.com) that serves as a cornerstone portfolio piece for my resume.

Beyond learning the latest architectural patterns, my goal was to discover how to leverage AI effectively while actively building out an advanced AI engineering skill set. I am intentionally working toward transitioning into professional roles in Platform Engineering, SRE, AI Engineering, Architecture, or Technical Project Management. By wearing all the hats for Blogger Bear—from cloud architect to frontend designer—I am actively building the exact operational and engineering skill sets required for that leap.

What it does🐾

Blogger Bear🐻 is an autonomous, unattended, multi-domain research-and-publishing platform deployed on AWS that orchestrates content completely from data change to static page generation. The platform is driven by two independent cadences per configured topic:

Note that topics that would require compliance review such as Financial still need human in the loop and the platform could be extended to support sensitive topics and new data sources quite easily.

  1. The Research Tick (Heartbeat): An EventBridge Scheduler cadence that periodically executes a "diff-first" validation on a data source (e.g., GitHub Trending, Hacker News, Crypto Feeds) using specialized adapters. It only calls an LLM if a material change is detected, summarizing findings into DynamoDB records.

  2. The Daily Authoring Cycle: A routine that aggregates fresh findings, ideates angles, drafts articles via Amazon Bedrock, runs them through algorithmic and LLM compliance reviews, and compiles them directly into static HTML, CSS, and RSS assets.

Because a system running on autopilot needs robust supervision, the entire platform is securely managed by a single operator using two advanced paradigms:

  • A Local Admin CLI: A Python terminal client that signs requests using AWS SigV4 to interact with an IAM-authenticated, IP-allowlisted REST API Gateway, keeping administrative credentials safely off the public web. But also simplifying tasks into more human readable format.

  • An Alexa+ Model Context Protocol (MCP) Operations Assistant:

A conversational assistant utilizing the Model Context Protocol Python SDK (version 2025-11-25) paired with a Strands Agents orchestrator on Bedrock. It provides text, web interface (/ask.html), and simulated voice-driven operational telemetry, allowing me to audit pipeline health, security incidents, and platform spend through simple conversation.

How we built it🐾

BloggerBear is built using modern "Vibe Coding" methodologies—collaborating intensively with advanced AI tools (Claude Code, Copilot, and custom agents) alongside rigorous manual code review, continuous integration, and reality-based testing.

The application architecture is entirely serverless, secure, and infrastructure-as-code driven:

  • Infrastructure as Code: Defined completely in Terraform and deployed continuously via GitHub Actions utilizing secure OIDC role federation to eliminate long-lived AWS access keys.
  • Compute & AI Pipeline: Powered by AWS Lambda executing a Python 3.11 codebase, coordinated via AWS Step Functions for retry state-machine logic and a dead-letter queue (DLQ) layout. AI reasoning hooks use the Amazon Bedrock Converse API to gracefully abstract model routing across provider boundaries.
  • Data & Frontend Edge: Structured data sits in a multi-table Amazon DynamoDB cluster, while raw source snapshots and article bodies reside in private S3 buckets. Published assets are rendered down into vanilla HTML/CSS/JS (no heavy framework bloat) and delivered globally via an Amazon CloudFront + AWS WAF static web distribution utilizing Origin Access Control (OAC).

Challenges we ran into🐾

(More in Friction Log)

Building an autonomous system with AI agents introduced fascinating, complex engineering hurdles that stretched my SRE and platform design skills:

1. The Realities of AI-Driven Coding ("Whack-a-Mole" vs. Reality Testing)

Developing a codebase using AI can lead to subtle surprises where static validation masks runtime exceptions. For example, my initial pytest suite passed perfectly because it executed within my local environment where pip packages were installed. However, the deployed AWS Lambda zip package lacked the third-party requests library, causing silent entry-point failures that no static terraform validate command could catch. I learned quickly that real invocation beats static checks, shifting my testing model to run live against the AWS Bedrock Sandbox and using real aws lambda invoke triggers to establish a true baseline.

2. AWS Regional Constraints & Individual Quotas

Operating as an individual developer meant working within tight default account restrictions. My AWS account carried a default Lambda concurrency cap of 10. When I attempted to set a reserved concurrency of 2 on the operator assistant's Lambda to cap simultaneous Bedrock requests, the Terraform apply failed completely with UnreservedConcurrentExecution errors.

I had to learn how to balance platform safety using API Gateway stage throttling limits rather than strict resource allocations. Furthermore, regional availability forced a multi-region split—hosting the core workload in ap-southeast-2 (Sydney) while mapping CloudFront certificates, WAF web ACLs, and the Bedrock AgentCore web search gateways out of ap-northeast-1 and some other resources in 'us-east-1'.

3. The Lighthouse Performance Trap

During a Google Lighthouse audit, I attempted to optimize layout shifts (CLS) and render-blocking CSS by implementing an asynchronous script to preload styles and swap them at runtime. However, a race condition occurred: cached stylesheets loaded instantly before the JavaScript event listener attached, rendering the production dashboard completely un-styled. This highlighted a major real-world production lesson—never sacrifice architectural correctness and safety loops for a marginal performance score. I immediately rolled it back to deterministic, blocking <link> elements.

It was enjoyable to work on in this project as opposed to a live Enterprise system where it is more Challenging and users are facing errors that I face in my day to day work; While I do enjoy contributing to said scenarios when they happen this one was nice because it was at a far slower pace then these things typically happen.

4. Gated Developer Access & The Alexa+ Simulation

A significant hurdle was that Amazon’s Alexa+ MCP Toolkit (alexa-ai CLI) remains partner-gated and region-restricted. Because my environment could not execute the physical hardware registration, I architected the Alexa+ path to run on Streamable HTTP over the MCP 2025-11-25 spec.

I implemented the underlying OAuth 2.1 + PKCE authentication loops via an API Gateway mock integration pointing to Amazon Cognito, constructed the background asynchronous execution handlers (start_briefing and latest_briefing) to bypass Alexa's strict 500 ms round-trip latency limit, and successfully simulated the entire, voice-enabled voice interaction paradigm directly in an unindexed web console (/ask.html) but unfortunately its not Alexa+ but its still very cool and I'm adding new skills to my MCP!

Accomplishments that we're proud of🐾

  • The Production-Grade Admin CLI:

The terminal client is exceptionally powerful. It uses AWS SigV4 request signing to completely manage runtime application parameters, article overrides, and moderation review loops without ever exposing an unauthenticated endpoint to the public web.

  • Deep Observability Integration - Costs:

I built an end-to-end Cost Explorer poll that aggregates exact daily financial metrics, streaming platform spend (AWS and token lineage counts) right into public-facing dashboard cards on the UI.

  • Autonomous Pipeline Guardrails: Creating a pipeline that mostly reliably critiques its own output is amazing. The platform tracks content metadata so seamlessly that it can automatically identify anomalies—such as an LLM response leaking markdown code fences (e.g., `markdown blocks)—and quarantine the article directly to the manual moderation inbox.

  • Systems Personality ("The Bear's Gear"): I successfully embedded a fun, modular prompt-refinement system into the platform layout. Based on weekly scheduled reflections over anonymous reader feedback, the system generates custom prompt modifications called "Gear" that the bear "wears" to dynamically alter its tone, complete with Easter egg pun jokes embedded across user feedback modules.

What we learned🐾

This project served as an absolute accelerator for my transition toward Platform Engineering. I gained a deep, firsthand understanding of least-privilege IAM scoping, discovering how certain account-wide list calls (like logs:DescribeLogGroups and cloudwatch:ListTagsForResource) cannot be resource-scoped and require explicit NotResourceScopable declarations in Terraform.

I realized the paramount importance of building custom developer tooling (like the Admin CLI) rather than manually driving modifications through the AWS Console. Using automated CloudWatch dashboards to instantly monitor WAF mitigations, API Gateway throttles, and generative token usage taught me how modern SREs maintain high-availability systems. Most importantly, I learned how to effectively manage an AI agent as an engineering accelerator—recognizing that while AI can compress months of full-stack delivery time down into weeks, a green checkmark means nothing unless you audit the code boundaries yourself.

What's next for BloggerBear🐾

  • Prompts-as-Assets & Advanced Evals: I plan to build out formal prompt-performance evaluation frameworks (Evals) using third-party testing integrations to score article writing styles, checking consistency and data citation accuracy deterministically.

  • Self-Healing AI Operations (Closed-Loop SRE): My long-term goal is to extend the Model Context Protocol (MCP) server capabilities so the system can autonomously identify its own production exceptions. If a Lambda log emits a standard error, the Ops Agent should isolate the root cause, package the findings into a structured prompt context, invoke Claude to write a code patch, generate an automated pull request, and wait for my single-character CLI confirmation to merge and deploy.

  • More Hackathons! This process has completely unlocked my love for product delivery on AWS, and I cannot wait to bring this evolved engineering framework into future competitive builds.

Built With

Share this project:

Updates

Submission history