Reporting Agent (Snowflake MCP)
Connects reporting to the warehouse — plain-language questions answered from our own governed data over the Snowflake MCP, so "what's pacing look like" takes a minute, not a dashboard request.
What this agent does
Answers reporting questions from the warehouse, in plain language, with the query attached. Anyone on the team asks "how are signups pacing against the 70K goal" or "which channel moved last week" and gets a governed answer sourced from the marketing tables over the Snowflake MCP — instead of filing a dashboard request, waiting on an analyst, or worse, guessing. The analysts stop being a query queue and start being analysts.
Why this agent
- The data foundations are finally worth querying — the warehouse migration and GA4 sign-off (the Data & Tracking project) exist precisely so numbers are trustworthy end to end; this agent is how that investment reaches everyone daily.
- Coverage — most reporting questions never get asked because asking is expensive. A one-minute answer changes what the team checks weekly, starting with the Exec Dashboard's own pacing rows.
- Latency — the pacing model refreshes in hours; answers about it shouldn't take days of analyst back-and-forth.
- It's the M1 proof of the data stack — the same MCP layer the optimization agents consume in M2; if this agent can't answer safely, the M2 agents can't act safely.
Trigger & inputs
- Trigger — a question, asked in Slack or wherever the team works; scheduled weekly pacing summaries once the answers earn trust.
- Reads — the Snowflake marketing tables through the MCP, read-only; the canonical metric definitions from the analytics reference; the GTM Pipe Model's pacing logic.
- Context — the governed definitions layer: what counts as an MQL, a signup, sourced vs influenced — answers use the house definitions or refuse.
What it produces
- Answers with receipts — the number, the definition it used, and the query it ran, every time.
- Weekly pacing summaries — the scoreboard rows, drafted for the human who owns the weekly fill.
- A question log — what got asked, what was answered, what it refused; the map of what dashboards should exist.
How it works
- Parse the question against the governed definitions; ambiguous terms get clarified, not guessed.
- Query the marketing tables over the MCP, read-only.
- Sanity-check the result against known ranges; out-of-range answers get flagged, not served.
- Return the answer with definition + query attached; log everything.
Guardrails & human-in-the-loop
- Read-only, always — no writes to the warehouse at any autonomy level, ever.
- Governed definitions only — a metric without a house definition gets "that's not defined yet," not an improvised answer.
- Never-do list — never serves numbers to external parties; never answers finance/HR/comp questions; never fabricates a figure when a table is empty (TBD > fake is house law).
- Escalation — schema drift, empty tables, or out-of-range results → stop, flag the Data & Tracking owners, don't answer.
Success metrics
- North star — time from question to governed answer: minutes, not days. Baseline: current analyst turnaround (TBD).
- Quality bar — spot-check agreement with Hex dashboards on the same questions, weekly, by the analytics owners.
- Guardrail metric — zero numbers served outside governed definitions; zero write attempts.
- Hours returned — analyst hours per week returned from ad-hoc pulls, on the program ledger.
Build plan
- V0 · Shadow mode (Sep) — answers questions the analysts also answer; results compared side by side. Exit: agreement rate on a live sample, judged by Keith/Adnan.
- V1 · Assisted (late Sep) — the team asks it directly; answers carry receipts; analysts audit the log weekly. Exit: trusted on pacing + channel questions at volume.
- V2 · Scheduled reporting (Oct) — weekly pacing summaries drafted automatically; anomaly flagging joins with the M2 optimization wave. Read-only stays permanent.
Dependencies & risks
- Warehouse migration + GA4 sign-off — the agent is only as good as the tables; it launches on whatever the Data & Tracking project has certified, and says so about the rest.
- Daily owner TBD — flagged in the program brief as an open risk: assign the ops & reporting owner before V1 or the owner rule breaks. [owner to complete]
- Definition gaps — metrics without governed definitions (influenced pipeline, MQL→SAL) will surface fast as refusals; that's a feature, but someone must close them.
- Trust is the product — one confidently wrong number costs more than a month of right ones; shadow mode exits on evidence, not enthusiasm.
What this agent does
Answers reporting questions from the warehouse, in plain language, with the query attached. Anyone on the team asks "how are signups pacing against the 70K goal" or "which channel moved last week" and gets a governed answer sourced from the marketing tables over the Snowflake MCP — instead of filing a dashboard request, waiting on an analyst, or worse, guessing. The analysts stop being a query queue and start being analysts.
Why this agent
- The data foundations are finally worth querying — the warehouse migration and GA4 sign-off (the Data & Tracking project) exist precisely so numbers are trustworthy end to end; this agent is how that investment reaches everyone daily.
- Coverage — most reporting questions never get asked because asking is expensive. A one-minute answer changes what the team checks weekly, starting with the Exec Dashboard's own pacing rows.
- Latency — the pacing model refreshes in hours; answers about it shouldn't take days of analyst back-and-forth.
- It's the M1 proof of the data stack — the same MCP layer the optimization agents consume in M2; if this agent can't answer safely, the M2 agents can't act safely.
Trigger & inputs
- Trigger — a question, asked in Slack or wherever the team works; scheduled weekly pacing summaries once the answers earn trust.
- Reads — the Snowflake marketing tables through the MCP, read-only; the canonical metric definitions from the analytics reference; the GTM Pipe Model's pacing logic.
- Context — the governed definitions layer: what counts as an MQL, a signup, sourced vs influenced — answers use the house definitions or refuse.
What it produces
- Answers with receipts — the number, the definition it used, and the query it ran, every time.
- Weekly pacing summaries — the scoreboard rows, drafted for the human who owns the weekly fill.
- A question log — what got asked, what was answered, what it refused; the map of what dashboards should exist.
How it works
- Parse the question against the governed definitions; ambiguous terms get clarified, not guessed.
- Query the marketing tables over the MCP, read-only.
- Sanity-check the result against known ranges; out-of-range answers get flagged, not served.
- Return the answer with definition + query attached; log everything.
Guardrails & human-in-the-loop
- Read-only, always — no writes to the warehouse at any autonomy level, ever.
- Governed definitions only — a metric without a house definition gets "that's not defined yet," not an improvised answer.
- Never-do list — never serves numbers to external parties; never answers finance/HR/comp questions; never fabricates a figure when a table is empty (TBD > fake is house law).
- Escalation — schema drift, empty tables, or out-of-range results → stop, flag the Data & Tracking owners, don't answer.
Success metrics
- North star — time from question to governed answer: minutes, not days. Baseline: current analyst turnaround (TBD).
- Quality bar — spot-check agreement with Hex dashboards on the same questions, weekly, by the analytics owners.
- Guardrail metric — zero numbers served outside governed definitions; zero write attempts.
- Hours returned — analyst hours per week returned from ad-hoc pulls, on the program ledger.
Build plan
- V0 · Shadow mode (Sep) — answers questions the analysts also answer; results compared side by side. Exit: agreement rate on a live sample, judged by Keith/Adnan.
- V1 · Assisted (late Sep) — the team asks it directly; answers carry receipts; analysts audit the log weekly. Exit: trusted on pacing + channel questions at volume.
- V2 · Scheduled reporting (Oct) — weekly pacing summaries drafted automatically; anomaly flagging joins with the M2 optimization wave. Read-only stays permanent.
Dependencies & risks
- Warehouse migration + GA4 sign-off — the agent is only as good as the tables; it launches on whatever the Data & Tracking project has certified, and says so about the rest.
- Daily owner TBD — flagged in the program brief as an open risk: assign the ops & reporting owner before V1 or the owner rule breaks.
- Definition gaps — metrics without governed definitions (influenced pipeline, MQL→SAL) will surface fast as refusals; that's a feature, but someone must close them.
- Trust is the product — one confidently wrong number costs more than a month of right ones; shadow mode exits on evidence, not enthusiasm.