RevenueGuard — Agentic Revenue-Leak Auditor

• 

  Revenue Guard

• 

  Example 1

• 

  Example 2

• 

  Example 3

• 

  Example 4

• 

  Example 5

• 

  Example 6

• 

  Example 7

• 

  Example 8

• 

  Example 9

• 

  Reel Report

💸 The problem: you can't fix the leaks you can't see

B2B SaaS companies leak 2–5% of revenue to billing errors they never notice — failed payments that were never retried, expired cards on active subscriptions, usage billed against cancelled plans, renewals that silently never invoiced, and discounts that outlived their expiry.

The cruel irony? Most leak-detection tools audit stale data, so they cry wolf. Finance and RevOps teams stop trusting the alerts — and the real money keeps draining.

🛡️ What it does

RevenueGuard is an autonomous agent that runs a strict verify → audit → report loop and earns trust by checking the pipeline first:

1. Verify before audit (the wedge). Before auditing anything, it uses the Fivetran MCP to confirm the billing connector synced recently and is healthy. If it's paused or stale, the agent stops, reports it, and — with your approval — resumes and re-syncs the connector. No more false alerts from stale data.
2. Audit. Once freshness is confirmed, it runs multi-step leak detection over the landed data in BigQuery across five leak families.
3. Act & report. It returns a ranked report with the dollar exposure, the SQL evidence, and a recommended action for every finding. The human stays in control — it proposes, you approve any write.

In the demo it surfaces a deterministic $18,650/yr in recoverable leaks:

🧱 How I built it

• Gemini 2.5 Pro (Vertex AI) — the reasoning engine driving the audit loop.
• Google Cloud Agent Builder / ADK (google-adk) — a code-first LlmAgent whose instruction enforces the verify→audit→report sequence.
• Fivetran MCP (github.com/fivetran/fivetran-mcp) — launched over stdio via uvx.
• BigQuery — the warehouse holding Fivetran-shaped billing tables; five deterministic SQL queries detect the leak families.

The freshness gate is what makes Fivetran load-bearing — its calls sit on the critical path of every audit:

```python fivetran_toolset = McpToolset( connection_params=StdioConnectionParams( server_params=StdioServerParameters( command="uvx", args=["--from", str(_MCP_DIR), "fivetran-mcp"], env={"FIVETRAN_API_KEY": ..., "FIVETRAN_API_SECRET": ..., "FIVETRAN_ALLOW_WRITES": "true"}, ), timeout=60, ), tool_filter=["list_connections", "get_connection_details", "modify_connection", "sync_connection", "resync_connection"], ) ```

🧗 Challenges I ran into

• Making Fivetran load-bearing, not decorative. The gate had to block the audit. The agent now literally refuses to audit a paused connector and re-syncs it live.
• A flaky live demo. Live MCP calls exceed ADK's ~5s default timeout (raised to 60s), and a re-sync doesn't finish instantly — so the agent triggers the refresh and proceeds rather than dead-ending on a wait.
• Deterministic numbers. The seed plants a fixed set of leaks summing to exactly $18,650/yr, so the report is identical every run.

🎓 What I learned

How to wire a partner MCP server into ADK as a first-class tool surface, how Fivetran's connection lifecycle (pause / resume / sync) maps to real agent actions, and how a single "verify-first" guardrail changes an agent from a plausible-sounding demo into something a finance team could actually trust.

🏆 Accomplishments I'm proud of

A genuinely real Fivetran → BigQuery pipeline with an agent that catches a stale connector, fixes it, and returns a precise, evidence-backed leak report — all while keeping a human in the loop for every write.

🚀 What's next

• Promote the single agent to a FreshnessGate → Auditor two-agent sequence.
• Write-back actions (auto-dunning, back-billing) behind human approval.
• Scheduled audits with Slack/email digests — recovering 2–5% of ARR finance can't see today.

Built With

• bigquery
• cloud-run
• fivetran
• gemini-2.5-pro
• google-adk
• google-cloud-agent-builder
• model-context-protocol
• python
• uv
• vertex-ai