-
-
Matchday_Pulse
-
Matchday_Pulse
Inspiration
I work as a Business Analyst. I spend a lot of time looking at dashboards. The problem with dashboards is that they tell you something is wrong. They don't tell you why, and they don't do anything about it.
I wanted to see what happens when you replace the dashboard with an agent that can actually investigate. Not summarize data, but reason through it: form a hypothesis, test it, follow the result somewhere new, and keep going until it finds something concrete.
Fraud on a high-traffic match day felt like the right problem. A lot of transactions, a narrow time window, real consequences if you miss it.
What it does
Matchday Pulse takes a vague signal and runs a full investigation.
The input in the demo is: "Something looks wrong tonight."
From there, the agent establishes a baseline across 5,000 transactions, identifies Zone 3 as the outlier (48.6% decline rate against an 11.8% venue average), narrows the anomaly to ticket resale transactions, finds three device fingerprints behind 214 of 222 declines, reconstructs the attack window (17:30 to 17:59 UTC), calculates $37,159 in attempted fraudulent volume, and generates a blocklist recommendation.
Every step follows from the previous result. The agent picks the next query based on what it just found. Nothing is hardcoded .
How we built it
The agent runs on Google ADK with Gemini 3.5 Flash on Vertex AI. It has access to MongoDB Atlas through a MongoDB MCP server deployed on Cloud Run.
When the agent decides to investigate Zone 3, it doesn't call a pre-written function. It composes a $match / $group aggregation at runtime and sends it to Atlas through the MCP server. The result comes back, the agent reads it ,and decides what to query next.
The frontend is React, also on Cloud Run. It shows the agent's reasoning as a readable investigation report, not a raw API log. Each step in the investigation timeline has a "View Atlas Query" toggle that shows the exact aggregation pipeline used to produce that finding. The full architecture:
React Frontend (Cloud Run) ↓ Google ADK Agent, Gemini 3.5 Flash on Vertex AI ↓ MongoDB MCP Server (Cloud Run) ↓ MongoDB Atlas
Atlas aggregation operators used across a live run: $match, $group, $project, $hour, $sum, $in on fingerprint arrays. All composed dynamically. All visible in the UI.
Challenges we ran into
Vertex AI intermittent errors. The agent occasionally returns MALFORMED_FUNCTION_CALL mid-investigation. We kept retry logic in the frontend and accepted that some runs need a second attempt. This is a real constraint of working with LLM tool use in production.
MCP cold starts. The MongoDB MCP server on Cloud Run takes a few seconds to warm up after inactivity. The first call after a cold start sometimes times out. Fixed with minimum instance configuration.
Showing the work without losing the judge. The hardest design problem wasn't the agent, it was the UI. If a non-technical judge sees raw MongoDB pipelines and JSON in the middle of an investigation report, they tune out. If a MongoDB-track judge sees nothing technical, they can't verify the claims. We solved this by making the business narrative the default view, with the actual Atlas queries one click away.
Accomplishments that we're proud of
The agent finds the fraud pattern reliably. Starting from "something looks wrong tonight," it lands on Zone 3, ticket resale, three specific device fingerprints, and the 17:30 attack window, every time. That's not scripted. The agent reasons its way there through live Atlas queries.
The whole system is deployed and running. Not a local prototype.
What we learned
MongoDB's aggregation framework is expressive enough that an LLM can compose useful analytical queries without custom tooling. $match, $group, $project, and $in cover a lot of ground when combined intelligently.
The hardest part of building an agentic system is not the agent. It's making the agent's reasoning legible to someone who wasn't watching it work.
What's next for Matchday Pulse
Connect to a live payment event stream instead of a static dataset. Extend the investigation across multiple collections: transactions, customer profiles, chargeback history. Let the agent learn from past investigations so it stops re-discovering patterns it has already seen.
Log in or sign up for Devpost to join the conversation.