The Big Picture
This is a largely autonomous system. It discovers events, monitors its own health, and fixes many of its own bugs — every day, with minimal human intervention. The Observatory exists to give transparency into this process so people can see how an autonomous AI system actually works. This isn't a black box.
How It Works
The whole system, end to end — it runs largely on its own, with a human reviewing only the riskiest changes.
Discovery Pipeline
— runs nightlyOpus reviews recent results and decides what to scrape and search today
Scans a dozen curated sources and the web for Austin AI events
Catches the same event listed on different platforms
AI confirms: real event? In Austin? AI-related?
Tags audience, skill level, and free/paid
Approved events appear on the calendar
Self-Monitoring
— evaluates every runCollects data on scraper health, error rates, source performance, and calendar coverage
The most powerful Claude model reviews everything, assigns a health grade, and identifies issues
Creates search queries, manages sources, and escalates code issues for the repair agent
Self-Healing
— runs daily, 2 hours after discoveryPicks up the highest-priority action item from the monitor
Diagnoses the root cause — fetching the live web page through a supervised relay, since the agent deliberately has no direct internet access
Reads the codebase, understands the bug, and writes a fix
Runs the full test suite, then tests the fix on a draft branch against the real live page — a fix that fails the rehearsal never touches production
Ships proven low-risk fixes to production automatically; flags riskier changes for a human to review first
The Independent Watchdog
A separate watchdog— its own program, running outside this system on its own schedule — independently counts how many Austin AI events exist and compares that to how many the calendar has captured. Because it lives outside the agent, the system can't grade its own homework: if coverage quietly slips, the watchdog is the thing that catches it.
Multi-Model Architecture
Three Claude AI models split the work based on what each task needs — like having a junior analyst, a senior reviewer, and a strategic director on the same team.
Handles 80% of decisions — validation, classification, dedup
Evaluates new sources and extracts event details
The system brain — plans each run and monitors system health
Community Input
Anyone can submit an event the system missed using the “Missing an event?” button on the calendar. The agent scrapes the submitted URL, validates it, and adds it to the calendar — all in the same daily run. It also learns from each submission, adding new sources and search strategies to find similar events in the future.
Where It Goes
Each morning, Claude summarizes the overnight run — what it found, what broke, and what it cost — and emails it to the operator. It's how a human keeps an eye on the system without having to run it.
Every Sunday evening, anyone who's subscribed gets the week ahead in Austin AI events delivered straight to their inbox.
Agent Performance
What the agent is doing autonomously
Events Added (Last 30 Days)
Recent Activity
Under the Hood
How the agent thinks, decides, and sometimes fails
Health Report
Automated self-evaluation of system effectiveness
| Grade | Scraper Health | Sources | Error Rate | Activity |
|---|---|---|---|---|
| A | 80%+ | 4+ contributing | <5% | Events added in last 7d |
| B | 60-79% | 3+ contributing | <10% | Active discovery |
| C | 40-59% | 2-3 contributing | >10% | Some source issues |
| D | <40% | <2 contributing | High | Multiple broken scrapers |
| F | — | — | — | System not running |
Updated 2026-03-29: Grades now measure infrastructure health (what the agent controls), not event count or empty days (which reflect community activity). The agent still actively maximizes calendar coverage as a separate mission.
Human Stewardship
How humans guide the agent's growth
Human Stewardship
How humans guide the agent's growth using Claude Code
The weekly digest was built to send at 6 PM Sunday by waiting for an hourly scheduler to fire inside a two-hour window — and that scheduler (GitHub Actions cron, a shared best-effort service) is allowed to skip hours entirely under load. On August 30 it fired only three of twelve slots, the two that mattered were both among the dropped, and 22 subscribers silently got no email. Worse, every run that did fire exited green ("not 6 PM yet, skipping"), so the failure produced no signal anywhere: the miss was pure absence — the same shape as the watchdog that once lay dead for 27 days.
The operator caught the miss the same evening (a manual rescue send went out about three hours late) and pressed the real question: why can't it just deliver at the same time every week? The redesign separates the two jobs the old design had fused. The agent now renders the email any time Sunday afternoon — any one of eight hourly fires will do — and hands it to the email provider with delivery scheduled for exactly 6 PM local, so the provider's clock, whose entire business is delivering mail on time, owns the moment subscribers see. And because absence must never again render as benign, a deterministic Monday check now verifies the week's send receipts actually exist, raising a critical alarm and a GitHub issue when they don't.
Delivery is pinned to 6 PM Sunday regardless of scheduler mood: GitHub would have to drop eight consecutive hours to cause a miss, a late fire falls back to sending immediately, and a total miss becomes a loud Monday-morning alarm instead of silence. The deeper lesson, learned now for the third time: a signal that only exists when things work cannot tell you when they don't.
This agent is developed iteratively with Claude Code. The collaboration is part of the project's identity.