Track: The Taskmaster. An autonomous data-ops analyst whose answer is a pull request.
Inspiration
Dashboards are passive. Someone still has to notice a number moved, then spend hours digging for why, usually the most senior person on the team, and usually after the damage is done. Then someone else has to go and fix it. We wanted to collapse that whole loop, notice, diagnose, decide, act, confirm, into something that runs on its own. Not a chatbot you ask questions, an analyst and operator that closes the loop while nobody is watching. So we built Atlas.
What it does
Atlas watches a BigQuery warehouse and runs a full closed-loop incident cycle, deployed live on Cloud Run:
- Predict. A BigQuery ML ARIMA_PLUS forecast, running natively in the warehouse, projects a revenue miss before the threshold is even breached.
- Detect. The next cycle confirms the drop, about 5% below the expected line in the live run.
- Diagnose. The Investigator writes its own SQL and joins a change_events table against the anomaly, so instead of "a provider is failing" it names the cause to the minute: a 14:00 Adyen EMEA configuration change.
- Quantify. It puts a dollar figure on it: about $10,054 lost so far and about $36,400 projected over seven days if nothing changes.
- Remediate. The fix is a pull request, not a hidden side effect. Atlas opens a small, reviewable change that fails EMEA payments over to a healthy provider, behind a guardrail and approval gate. With auto-remediate on it acts unattended; with it off a human clicks Approve. It also opens a ticket and posts the cause and dollar impact to the ops channel.
- Verify. The next cycle re-checks the metric, sees it recovering, and marks the incident resolved, closing the loop.
A human is in the loop only when the guardrail deliberately asks for one.
How we built it
A Google ADK multi-agent system: a Supervisor delegates to specialist sub-agents composed as named, reusable skills, Forecaster, Watcher, Investigator, Correlator, Actor and Verifier, with the Actor handing the fix to a dedicated Remediation sub-agent (wired A2A-ready so it can become a standalone service).
Everything runs on Google Cloud. Gemini on Vertex AI drives every agent, flash-first for cost. BigQuery and BigQuery ML (ARIMA_PLUS) are the watched warehouse, with a change_events second signal. Firestore holds durable state and the incident lifecycle, open to remediated to resolved, which is what lets a later cycle recognise the same incident and confirm it. Cloud Run is the deployed runtime. Tools are served over the Model Context Protocol so capabilities are swappable and inspectable. A Gemma triage cascade and a Veo and Imagen incident card are in the code and available. A dedicated guardrails layer keeps the autonomy safe: diagnostic SQL is read-only, parameterised and byte-capped, and every action passes a dry-run and approval gate with rate and spend caps and a recorded decision trail. The whole loop is covered by 272 tests, and an offline make demo reproduces it with no cloud project and no network.
Challenges we ran into
- Making autonomous action safe, not just autonomous queries. Letting an agent execute a payment failover is only acceptable behind hard rails: the approval gate, a confidence floor, rate and spend caps, an on and off auto-remediate flag with a human Approve path, and a recorded trail.
- Multi-signal root cause. Attributing a drop to a specific config change, not just "provider X is failing," meant the Investigator had to write the join against the change stream itself.
- Closing the loop. Verify required an incident lifecycle in Firestore so a later cycle could recognise the same incident and confirm resolution.
- Keeping a live, two-cycle demo predictable. Flash-first models, tight per-stage jobs, and a strictly ordered workflow keep it stable and cheap under trial credits.
Accomplishments that we're proud of
- A complete closed loop on real Google Cloud data: predict, detect, diagnose, quantify, open the fix, verify resolved.
- The Investigator writes its own multi-signal SQL and names the cause to the minute.
- The remediation is a real, reviewable pull request behind an auditable guardrail, not just an alert.
- Business impact stated in dollars, so the output is decision-ready.
- Production-shaped architecture: ADK skills, MCP tools, an A2A-ready remediation agent, BigQuery ML forecasting, durable Firestore memory, a guardrail layer, and Cloud Trace and Logging, deployed on Cloud Run.
What we learned
- The gap between a demo agent and a deployable operator is almost entirely guardrails, memory, and a verify step, not the model.
- Autonomy is most valuable where the work is hardest: writing the SQL, naming the config change, and safely opening the fix, not the threshold anyone can alert on.
- A verify step changes everything. Once the agent confirms its own fix, it owns the incident end to end instead of just advising.
What's next for Atlas
- More metrics and multi-warehouse coverage.
- A richer remediation catalogue behind the same guardrail.
- Promoting the in-process Remediation agent to a standalone A2A service.
- Turning on the Gemma triage cascade and the Veo and Imagen incident cards in production.
Built with
google-adk, vertex-ai, gemini, bigquery, bigquery-ml (arima-plus), firestore, cloud-run, model-context-protocol, a2a, gemma, veo, imagen, python
Log in or sign up for Devpost to join the conversation.