KiloNOVAScout

Autonomous telescope targeting agent — from cosmic alert to observation plan in under 2 minutes, all without human intervention until the final approval step.

Comment

Inspiration

Multi-messenger astronomy — observing the same cosmic event across gravitational waves, gamma rays, and neutrinos — is one of the most exciting frontiers in science. But it has a practical problem: time.

When LIGO detects a neutron star merger, or IceCube spots a high-energy neutrino, or Fermi catches a gamma-ray burst, observatories have a narrow window to point their telescopes before the signal fades. The current workflow is manual: notice the alert, download the sky map, check telescope visibility, look up galaxy catalogs, verify weather, write an observation plan. That can take hours. By then, the signal is often gone.

We wanted to build an agent that compresses that entire workflow into minutes — not by replacing astronomers, but by handling everything up to the point where a human says "yes, observe this."

What it does

KiloNOVAScout is an autonomous multi-messenger astronomy targeting agent. It:

  • Ingests real alerts from NASA GCN (gravitational waves, gamma-ray bursts, high-energy neutrinos) via Kafka or GraceDB polling
  • Parses sky maps from LIGO/Fermi/IceCube FITS files using HEALPix
  • Cross-matches galaxies by querying the GLADE+ catalog through CDS VizieR TAP
  • Checks real-time weather at your observatory using Open-Meteo
  • Scores targets with a 7-term astrophysical formula including Schechter luminosity weighting and airmass integration
  • Schedules telescope slews using TSP optimization on the alt/az sphere
  • Generates publication-grade reports in Markdown, HTML, and LaTeX with embedded visualizations
  • Analyzes historical events — search real past events from NASA GraceDB by class and year range, then run batch retrospective analysis through the same pipeline

The human approves at the end. Everything before that is autonomous.

How we built it

Backend: Python 3.11 with the Strands Agents SDK as the core framework. The pipeline is a directed acyclic graph (DAG) with 6 stages: ingestion → sky parsing → catalog + weather (parallel) → scoring → scheduling → reporting. Each stage has gated advisors and hook-gated specialists for anomaly detection. LLM reasoning (Gemini with Groq fallback) generates rationale and classifies decisions. Visualization selection is LLM-driven from a pool of 7 plot types.

Frontend: React 18 + Vite with Tailwind CSS. A single-page dashboard with 6 sections — status, live triggers, observatory config, event classes, demo controls, and a real-time agent terminal that streams every step via SSE. Historical analysis lets users search NASA GraceDB by class and year range, tick events, and run batch comparisons.

Deployment: Multi-stage Docker build (Python → Node → Python) on Render Free Tier (512 MB RAM). No paid services required. Boot hardening for environment variable parsing on Render's constrained runtime.

Data sources: NASA GCN Kafka, NASA GraceDB REST API, CDS VizieR TAP (anonymous), Open-Meteo (keyless), bundled GW170817 replay data for offline demos.

Challenges we ran into

512 MB memory budget. Running a Python backend, matplotlib visualizations, HEALPix parsing, and concurrent API calls within Render's free tier limit required careful resource management — deferred visualization generation, capped concurrent connections, and optimized imports.

Real API quirks. VizieR uses ADQL not SQL. GraceDB's anonymous API caps at 60 results per query and returns GPS timestamps (not Unix) — we had to discover and fix the 315,964,800-second epoch offset to get correct trigger dates. Open-Meteo returns hourly forecasts that need airmass-weighted integration, not simple averages.

Multi-event class extension. The original design was gravitational-wave only. Extending to gamma-ray bursts and neutrinos meant building separate ingest gates, scoring profiles, and report sections — each with different data formats, different sky localization methods, and different scientific priorities.

LLM reliability. The agent uses LLM reasoning for rationale generation, but LLMs sometimes return malformed JSON or make overconfident rejections. We implemented 6-field structured output parsing with truncated-JSON recovery, conservative backoff (1s → 4s → 16s), and a class-aware prompt that prevents the LLM from rejecting events based on missing optional fields.

Accomplishments that we're proud of

  • Full autonomous pipeline from alert to observation plan — ingests real NASA alerts, processes them through 6 stages, and generates publication-grade reports without human intervention
  • Three event classes end-to-end — gravitational waves, gamma-ray bursts, and high-energy neutrinos, each with dedicated scoring and reporting
  • Live historical event discovery — queries NASA GraceDB in real time to find and analyze actual past events, not just hardcoded data
  • Runs on $0/month — Render Free Tier, no paid APIs, no paid databases
  • Publication-grade reports — Markdown, print-ready HTML, and LaTeX output with embedded visualizations and full calculation traces
  • 99 automated tests passing across gate logic, LLM parsing, and notifier behavior

What we learned

  • Strands Agents SDK works well for multi-stage pipelines with gated transitions. The tool, hook, and Agent primitives compose cleanly into specialized sub-agents.
  • Real scientific data is messy — FITS files, GPS timestamps, ADQL queries, and magnitude systems all have quirks that aren't documented in tutorials. We spent significant time reverse-engineering API behavior.
  • LLM output is unreliable by default — structured parsing with fallback recovery is essential, not optional. The agent's 6-field JSON schema with truncation-safe fallback has been critical.
  • Free-tier constraints breed creativity — the 512 MB limit forced us to design a leaner architecture than we would have otherwise, and that made the system better.

What's next for KiloNOVAScout

  • AgentCore deployment — migrate to Amazon Bedrock AgentCore for production-grade hosting
  • More event classes — extend to fast radio bursts, supernovae, and X-ray transients
  • Real observatory integration — connect to ASCOM/INDI telescope control systems for automated pointing
  • Multi-observatory coordination — dispatch different targets to different telescopes based on location and capability
  • GCN Circular auto-submission — generate and submit circulars to the astronomy community automatically
  • Public corpus growth — the historical archive grows as GraceDB adds new events, no code changes needed

Built With

Share this project:

Updates

Submission history