NEVORA AI

Inspiration

Managing a satellite constellation is a brutal scheduling problem — dozens of moving targets, limited battery and solar windows, cloud cover blocking imaging, and ground stations with finite downlink capacity, all changing by the minute. It's a textbook NP-hard combinatorial optimization problem, and real mission planners still lean heavily on manual coordination. We wanted to see what happens when you hand that coordination to a hierarchy of autonomous agents backed by real math, not just an LLM guessing at a schedule.

What it does

NEVORA AI autonomously schedules an entire satellite constellation's imaging and downlink operations. A Mission Commander agent ingests imaging requests and delegates to specialist agents — an Orbit Agent (predicts satellite position, battery, and imaging windows), a Weather Agent (checks cloud cover for imaging viability), and a Ground Station Agent (manages downlink capacity). Their combined constraints feed an Optimization Agent, which formulates the problem as a QUBO (Quadratic Unconstrained Binary Optimization) and solves it for the mathematically optimal satellite-to-task assignment. If a satellite suffers an anomaly — say, a sudden battery failure — the system detects it and autonomously re-plans the entire schedule in seconds, reassigning tasks to healthy satellites.

How we built it

-Google Agent Development Kit (ADK) for the multi-agent architecture — an LlmAgent coordinator (Mission Commander) delegating to four specialist sub-agents, plus a SequentialAgent pipeline that runs deterministically whenever an anomaly is reported, so re-planning isn't left to chance. Gemini (gemini-3.6-flash) powers every agent's reasoning and tool-calling. -Skyfield + real TLE orbital data for genuine satellite position and imaging-window prediction, not synthetic placeholders. -dimod + dwave-neal to build and solve the QUBO via classical simulated annealing — fast enough for a live demo, with an optional literal QAOA path via Qiskit's Aer simulator for anyone who wants to see an actual quantum circuit. -FastAPI backend wrapping the ADK Runner, secured with API-key-to-JWT session exchange, per-endpoint rate limiting, strict Pydantic validation, and locked-down CORS. -A custom "Mission Control" web frontend — live constellation telemetry, a chat console to talk to the Mission Commander, and an anomaly-injection panel to trigger the re-plan pipeline on demand.

Challenges we ran into

-ADK's single-parent constraint: agent instances can only belong to one parent, so we couldn't reuse the same domain agents in both the main workflow and the anomaly re-plan pipeline — we had to build them via factory functions to get genuinely separate instances. -Model churn mid-build: gemini-2.5-pro was deprecated for new users partway through development, and free-tier keys turned out to have zero quota for any Pro-tier model at all, forcing us to re-architect around Flash-tier models. -Free-tier rate limits: a single user request can trigger a dozen-plus internal LLM calls across the agent hierarchy (coordinator → 4 sub-agents → tool calls), which burns through free-tier RPM limits fast — a good reminder that "agentic" systems multiply API load in ways a single chatbot never does. -Formulating satellite scheduling as a QUBO cleanly, balancing the reward term (priority-weighted task coverage) against penalty terms (no double-booking, infeasible battery/window pairs) without over- or under-constraining the solver.

Accomplishments that we're proud of

-A genuinely working hierarchical multi-agent system, not a single LLM pretending to be several agents. Real orbital mechanics (TLE + Skyfield) instead of mocked coordinates. -A working QUBO solver we verified numerically picks the correct optimal, constraint-respecting schedule. A deterministic, reliable disruption-to-recovery demo loop — the part of the project we think best proves autonomous resilience rather than just autonomous chat.

What we learned

That building "agentic AI" is as much a systems-engineering problem as a prompting problem: parent/child constraints, rate limits, and model lifecycle churn all shape the architecture as much as the reasoning does. We also learned to be honest in a hackathon pitch about scope cuts — our QUBO doesn't yet time-slot a single satellite's own overlapping tasks, and we say so directly rather than overclaiming.

What's next for NEVORA AI

-Extend the QUBO to a full time-indexed model so a single satellite can't be double-booked across overlapping windows. -Swap the classical solver for a literal QAOA run against real quantum hardware access, once available, for a genuine quantum-vs-classical comparison. -Deploy persistently on Cloud Run with Secret Manager-backed credentials and real OAuth instead of the hackathon's API-key flow. -Feed in live TLE and weather data continuously rather than per-request, so the constellation state is always current.