How we built Atlas, an autonomous data-ops agent, for the All Things Agentic Hackathon

We built Atlas for the All Things Agentic Hackathon, a $180,000 Devpost event whose whole thesis is that an agent should do the job, not just talk about it. So we built one that does a job we know cold: keeping a data warehouse healthy. Atlas is an autonomous data-ops agent. Point it at a BigQuery dataset and it runs a closed operating loop on its own schedule, deciding what to look at, what is wrong, and what to do about it.

This is a writeup of how Atlas works and what we learned building it. To be clear about who “we” are: doom2quake is a human builder collective. Atlas is the autonomous agent. We are the people who designed, built, and shipped it.

The one-line pitch

Atlas watches your data pipelines the way an on-call engineer would. It predicts where things will break, catches the break, works out why, prices the business impact, fixes what it safely can, and proves the fix held.

The operating loop

The core of Atlas is a six-stage loop. Each stage is an ADK agent (or a tool-using sub-agent) with a narrow job, and the orchestrator decides when to advance, when to loop back, and when to escalate to a human.

1. Predict. Atlas forecasts the expected shape of each table’s next load: row counts, null rates, freshness windows, key distributions. It learns these from history in BigQuery, so “normal” is data-driven rather than a hand-written threshold.
2. Detect. When a load lands, Atlas compares reality against the forecast. A drop from 4M rows to 3.1M, a null rate that triples, a partition that never arrived. Each is an anomaly with a severity score.
3. Diagnose. Atlas reasons about why. It pulls the query lineage, recent schema changes, upstream job logs, and correlated anomalies, then asks Gemini to produce a ranked set of candidate root causes with the evidence for each.
4. Quantify. Not every anomaly matters equally. Atlas estimates business impact: which dashboards, models, and downstream tables consume the affected data, and roughly what is at stake if it is wrong. This is what turns a wall of alerts into a priority order.
5. Remediate. For a bounded set of safe, reversible actions (backfilling a partition, re-running an idempotent job, quarantining a bad batch, opening a ticket with the diagnosis attached), Atlas acts. Anything risky is proposed, not executed, with a one-click approval for a human.
6. Verify. After acting, Atlas re-runs Detect on the affected slice to confirm the anomaly is gone and nothing new broke. If it did not hold, it loops back to Diagnose with the new evidence rather than declaring victory.

The loop is the product. Any single stage is a script. The value is that Atlas closes it, and knows when to stop and ask.

The stack, and why

• Google ADK (Agent Development Kit) gave us the agent, orchestrator, and tool structure out of the box. We modeled each loop stage as an agent with typed tools, and let the ADK runtime handle turn-taking, tool routing, and session state. That let us spend our time on the judgement in each stage instead of the plumbing.
• Gemini is the reasoning engine for Diagnose and Quantify, the two stages that are genuinely open-ended. We kept Predict and Detect mostly numerical (cheaper, deterministic, testable) and reserved the model for the “why” and the “so what.”
• BigQuery is both the subject and the memory. Atlas queries it to learn baselines and detect anomalies, and writes its own run history back into it, so its forecasts get better and its diagnoses cite prior incidents.

What we learned

Give the model evidence, not the raw problem. Our first Diagnose prompt handed Gemini the anomaly and said “why did this happen?” It hallucinated plausible-sounding causes. The fix was to make Diagnose a retrieval problem first: gather lineage, schema diffs, and job logs deterministically, then ask the model to rank causes strictly from the evidence provided. Grounding beat cleverness.

Quantify is the stage judges feel. A demo that says “found 12 anomalies” is noise. A demo that says “this one anomaly feeds the revenue dashboard the CFO opens at 8am, here is the blast radius” lands. Impact-scoring was the difference between a monitoring toy and something that looks like an operator.

Make the autonomy legible. The scariest thing about an agent that acts on a warehouse is not knowing what it will do. We split every action into safe/auto versus risky/proposed, logged every decision with its reasoning, and made Verify mandatory. A judge could watch Atlas act and always see why. Constrained autonomy demoed better than unconstrained autonomy, and it is the honest design anyway.

Match the build to the rubric. All Things Agentic rewards agents that are genuinely agentic (autonomous, tool-using, closing a real loop) over chat wrappers. We read that intent early and let it shape scope: one deep, working loop beat five shallow features. That instinct is a whole discipline for us. See how we read a hackathon like a sponsor’s showcase.

Where Atlas goes next

The loop generalizes past data-ops. Any domain with a measurable “normal”, a cost to being wrong, and a set of safe corrective actions fits the same skeleton. For the hackathon we kept it to BigQuery data health because it is a job we can demo end-to-end and defend under questions. That focus was the point.

If you are building for All Things Agentic or any agent-first event this season, our short take is in what we’re building this season. And if a term here is new (ADK, MCP, agentic AI), the glossary defines them.