Zeus | Devpost

Zeus AI
Settings - Zeus AI

Inspiration

A statistic kept showing up in our research: roughly 60% of enterprise AI projects stall on bad data. Not bad models. Bad foundations.

Pipelines silently break. Tables are synced without clear scope. Metrics appear in dashboards with no way to trace them back to a source. Data teams burn weeks babysitting connectors instead of building.

The conventional 2026 answer is a copilot bolted onto a data platform, like Matillion’s “Maia,” that generates pipelines from natural language. But those assistants are closed: they live inside one vendor and mostly talk about your data.

The shift that excited us was quieter but more important: Fivetran exposed its control plane as an open MCP server. That means the data foundation is no longer something only a human operates through a console. It can be operated by an agent over an open protocol.

So we did not build another chatbot. We asked:

Can an agent genuinely be the data engineer?

Can it plan the foundation, provision it, heal it when it breaks, and answer questions with full lineage, all under human oversight?

Zeus is our proof.

What it does

You give Zeus a plain-English goal, such as:

Analyze my sales pipeline against our support tickets. Zeus then operates a live Fivetran account to deliver the answer.

Plans and provisions the data foundation by inspecting the current setup, running connection setup tests, and triggering a sync into BigQuery. Asks before every write with a human-in-the-loop approval gate that shows the exact tool and parameters before anything mutates the data platform. Scopes access for governance by creating dedicated teams/groups and granting least-privilege access instead of opening the entire warehouse. Answers with lineage by querying BigQuery and attaching provenance to every figure: which connection, which tables, and how fresh the data is. Self-heals when a source breaks by detecting the paused connection, diagnosing it, resuming, re-testing, re-syncing, and verifying health. Stays fresh by registering a webhook so Zeus can monitor sync health after the user walks away. A live readiness meter tracks four data-foundation pillars: Freshness, Lineage, Governance, and Interoperability. The meter moves from red to green as the agent completes real work. Representing a fresh foundation with only the MCP architecture in place, and climbs toward green as each real action lands.

How we built it

Zeus runs on the required hackathon stack: Gemini 3 + Google ADK on Vertex AI, driving Fivetran over MCP, with BigQuery as the destination and analytics layer.

Reasoning layer: A Google ADK root agent orchestrates four sub-agents: planner, provisioner, healer, and analyst. The agent is powered by Gemini 3 on Vertex AI, using gemini-3-flash-preview in development and gemini-3.1-pro-preview for the demo. Tooling layer: The official Fivetran MCP server exposes the Fivetran control plane to the agent, with write operations enabled. Data layer: BigQuery serves as both the Fivetran destination and the agent’s query target. Approval gate: ADK’s confirmation flow pauses write tools, surfaces an approval request to the UI, and resumes the same invocation after the operator approves or rejects. Web app: FastAPI runs the agent in-process through an ADK Runner and streams real agent events to the UI over server-sent events. Infrastructure: Cloud Run hosts the web app, agent, and MCP server. Secret Manager stores Fivetran credentials. Everything in the demo is a real API write against a live Fivetran account, gated by approval. It is not a mock.

Challenges we ran into

The first major challenge was per-tool approval gating in ADK. We wanted Zeus to pause on writes, not reads. But McpToolset.require_confirmation receives the tool arguments, not the tool name, and ToolContext does not expose the tool name. That made it impossible to decide whether a tool was a write at that layer.

We moved the gating into before_tool_callback, which does receive tool.name, replicated ADK’s native confirmation flow, and applied it to the root agent and every sub-agent. This mattered because the provisioner performs the real writes and would otherwise bypass the approval gate.

The second challenge was streaming the human approval round-trip over SSE. We had to detect the adk_request_confirmation event, show it as a modal, and resume the same invocation with a FunctionResponse, including cases where multiple confirmations happen in one turn.

The third challenge was a subtle SQL correctness bug: fan-out double counting. The analyst initially joined opportunities to support tickets directly on account_name. Both tables were one-row-per-event, so the join multiplied rows and inflated SUM(amount).

We fixed this by prescribing that query shape in the analyst prompt. The demo’s headline answer, US$497k of open pipeline at risk, is computed live in BigQuery with fan-out-safe SQL.

The final challenge was keeping a powerful model on-script. gemini-3.1-pro-preview sometimes tried to batch parallel tool calls, which collided with the approval-resume flow. We added a “one tool call per turn” discipline so every write surfaces its own clean approval.

Accomplishments that we're proud of

We are proud that Zeus is genuinely agentic. It does not just chat about data pipelines. It plans, calls real write-capable tools, waits for human approval, verifies the result, and continues.

We are also proud of the red-to-green readiness meter because it makes the invisible work of a data foundation visible. Freshness, lineage, governance, and interoperability are usually abstract platform claims. Zeus turns them into a live operational score.

Most importantly, we proved the core thesis:

If a SaaS control plane speaks MCP, an agent can operate it.

For this hackathon, that control plane is Fivetran. But the pattern is bigger than Fivetran. It points toward a future where agents operate infrastructure through open protocols instead of brittle UI automation or closed vendor copilots.

What we learned Inspiration

We learned that exposing a SaaS control plane as MCP genuinely makes it agent-operable. The “open protocol” story is not just narrative. The same agent pattern could drive any MCP-compliant control plane.

We also learned that human-in-the-loop is a feature, not a tax. Approval gates make autonomous operations trustworthy. They also make the agent’s reasoning legible because the user sees exactly what Zeus is about to do.

Finally, we learned that agentic correctness lives in the details. The difference between an impressive demo and a wrong one was one CTE. Reliability came from constraining the model precisely, not simply using a bigger model.

What’s next for Zeus

Next, we want to add column-level lineage and dbt transformation orchestration through run_transformation.

We also want governance scoping through Fivetran teams to become a first-class, automatically managed pillar.

Longer term, Zeus should maintain a freshness SLA autonomously through webhooks, only asking for human help when a decision or approval is truly needed.

You did not hire a data engineer. The agent is the data engineer.

And because the control plane is an open MCP protocol, any agent could drive it.

This is ETL for the AI era.