About BloggerBear

BloggerBear is a personal portfolio project: an autonomous, multi-domain research-and-publishing platform. Admins configure "topics" — a data source plus an adapter — and each topic runs unattended, forever, on two cadences: a research check every few hours for anything new worth writing about, and a daily cycle that turns fresh findings into a fact-checked, reviewed article. No one drafts these articles by hand. A person only gets involved when an article needs a decision: every financial-topic article, and anything the automated reviews hold back.

It's live today with four topics — trending GitHub projects, crypto, tech market news and World of Warcraft — plus a daily Trending Everywhere digest that draws on all of them.

The idea

Most "AI writes a blog" demos stop at "call an LLM, publish whatever comes back." The interesting part of this project was everything around that one call: how do you decide something is actually worth writing about (rather than re-summarizing the same thing every hour)? How do you stop a model from publishing something inaccurate, or giving financial advice it has no business giving? How do you let readers push back on what got published, and actually feed that back into how future articles get written — without ever collecting who they are?

How it works

• Research tick: every few hours (each topic on its own schedule, staggered so they don't all start at once), a topic's adapter fetches its source's current state and diffs it against the last snapshot. No material change, no Bedrock call — cost and noise stay down, and nothing gets written about a source that hasn't actually moved.
• Web search with a fallback: topics that watch the news search GDELT first. When it's slow or refuses, the same search goes to Amazon Bedrock AgentCore's web search instead, so one flaky free service can't leave a topic with nothing to write about.
• Daily authoring cycle: on a material-change day, the pipeline asks Claude (via Amazon Bedrock) for a few candidate angles and drafts a full article for the strongest one. Before anything goes live, a fact-check re-reads current data and flags claims that have gone stale, then a separate compliance review checks the draft against the research it was written from.
• Compliance is a hard gate, not a suggestion: financial/investment-adjacent topics are routed to manual moderation unconditionally — that's a deterministic rule, not something an LLM call could talk its way around — and carry a standing "not financial advice" disclaimer appended to the draft itself, not just requested of the model.
• A held article can be sent back for a rewrite: the operator can ask a chosen model to fix exactly what a review flagged. The rewrite is checked in plain code (it may not introduce a figure or link that isn't in the sources), reviewed again, and always comes back to a person. It never publishes on its own.
• Anonymous feedback loop: readers can upvote/downvote and leave an optional comment, with no identity attached at all. A weekly job reads a week of that feedback and proposes prompt refinements — which an admin has to approve before they ever affect a future draft.
• New sources are adapters, not new pipeline code: the difference between the first data source and the third was exactly one new file plus one registry line — nothing about the core research/authoring flow itself changed to support them.
• Every cost is on show: each article records which models wrote it, how many tokens that took, and what it cost. The public Stats page adds up everything else too — research, web searches (estimated, and the actual figure from the AWS bill) and the rest of the AI spend.

Architecture at a glance

Every piece of this runs on AWS, defined entirely in Terraform:

• Compute: a handful of Python AWS Lambda functions — one per pipeline stage, each doing one job.
• AI: Amazon Bedrock (Claude) for research summarization, drafting, fact-checking, compliance review, rewrites, and feedback screening, with models chosen at runtime from a registry rather than fixed in code. Amazon Bedrock AgentCore provides web search as the fallback to GDELT.
• Storage: DynamoDB for structured data (topics, findings, articles, feedback, moderation, weekly stats), S3 for article bodies and raw source snapshots.
• Orchestration: EventBridge Scheduler for per-topic cadences, Step Functions for retries and a dead-letter queue on the daily cycle.
• Edge/frontend: S3 + CloudFront serving this static site, fronted by a WAF Web ACL with security response headers (CSP, HSTS, and friends) attached at the CDN layer.
• Admin surface: a separate, IAM-authenticated, IP-allowlisted API driven by a local CLI — deliberately not a public web app, since there's exactly one operator.
• CI/CD: GitHub Actions, OIDC role federation (no long-lived AWS keys anywhere in the repo), a two-environment branch/release model — free-to-break dev, and a production that only changes when a release is published.

Data sources

The research behind each article comes from these sources. Every article and topic page credits the ones it draws on, just under its title.

• Powered by CoinGecko API — crypto prices, market data and price history.
• Data sourced from GitHub Trending — the repositories trending on GitHub.
• Data sourced from Hacker News — top stories, through the official Hacker News API.
• News search by the GDELT Project — news headlines for web-search topics and for the crypto topic's news.
• Contains modified Copernicus Sentinel data — Sentinel-2 satellite imagery for satellite-vision and rail-access topics, processed by BloggerBear (counted, mapped and annotated with OpenCV). Figures are labelled as processed imagery and carry the year they were captured.
• Sentinel-2 Cloud-Optimized GeoTIFFs accessed from the Registry of Open Data on AWS — where that imagery is read from.
• Map data © OpenStreetMap contributors, available under the Open Database Licence — the rail lines, stations and interchanges that rail-access topics read the imagery against, through the Overpass API.

BloggerBear is not endorsed by, partnered with or affiliated with any of them. Each article also lists the individual pages it drew on under "Sources".

Why this project

It was a chance to design and build a real, multi-service AWS system end to end — not a tutorial project — and make deliberate, defensible calls at each layer: when to gate on cost versus correctness, where a rule has to be deterministic rather than "the model probably won't," how to keep a public feedback feature genuinely anonymous rather than anonymous-in-name-only, and how to keep infrastructure changes reviewable and reversible instead of applied by hand. It's also, deliberately, a disposable one: this is a personal project, not a production service, and the Terms of Service say so plainly — it can be reset or taken down at any time.

← Back to the homepage