RevPilot

RevPilot Architecture Diagram
RevPilot Revenue Recovery Dashboard Live

RevPilot — Project Story Inspiration

I've spent over a decade owning digital channels — web, app, e-commerce, chatbot — and the moment that never gets easier is the one where revenue drops and nobody knows why yet. The dashboards tell you that something is wrong in minutes. Figuring out why — is it traffic, is it checkout, is it a payment gateway, is it a bad config push — takes a human hours of manually cross-referencing systems that were never built to talk to each other. By the time the root cause is found and someone with the right access fixes it, real revenue is already gone.

Every "monitoring" tool I've used treats that investigation as someone else's job. It alerts; it doesn't act. I wanted to see if an agent could actually close that loop — not just detect the drop, but reason through the funnel the way an experienced ops person would, find the actual cause, and take the safe corrective action itself, in the time it takes to notice the alert. RevPilot is that idea built out: an agent that investigates, decides, acts, and proves the recovery — autonomously.

What it does

RevPilot watches revenue in real time. When it detects a drop, it walks the funnel step by step — traffic, checkout conversion, payment failures, payment-method breakdown, recent configuration changes — narrowing down to a specific, defensible root cause instead of a vague anomaly. Once it's confident, it takes the safest available corrective action (for example, pausing the affected campaign or switching the payment route), then verifies that conversion actually recovers before declaring the incident resolved. The dashboard shows the whole arc live: Revenue at risk → Action taken → Recovered, with a full incident report generated automatically for the humans who'll want the paper trail afterward.

How I built it

The core is a diagnostic agent built on Gemini 3.5 Flash, using function-calling to walk the funnel as a sequence of discrete, inspectable tools rather than one opaque reasoning blob — each funnel-check (traffic, conversion, payment failures, config-change correlation) is its own tool, so the reasoning path is traceable and the architecture stays decoupled. A synthetic e-commerce dataset with a deliberately seeded anomaly stands in for real production telemetry, so the demo is fully reproducible without touching any real business systems. Remediation actions are implemented as clearly labeled simulated integrations against a mock internal API — the agent genuinely decides and executes a corrective action, it just isn't touching a live ad platform or payment processor. State and incident history live in Firestore, the whole thing runs on Cloud Run, and the dashboard renders the live sequence of risk, action, and recovery as it happens rather than as a static end-of-run summary.

Challenges I ran into

The hardest part wasn't the agent reasoning — it was scope discipline. It's tempting to keep adding funnel-check steps, more remediation options, more edge cases, and burn the whole build window on breadth instead of depth. I forced myself to a fixed four-step diagnostic path and one clean remediation action, and put the saved time into the dashboard instead, since a live, visibly-updating "recovered $X" moment sells the idea far better than a longer feature list. Designing a synthetic dataset that produces a believable root cause — not an obviously scripted one — took more iteration than I expected; it's easy to build a funnel where the answer is too obvious to demonstrate real diagnostic reasoning. Getting the agents to hand off cleanly — each step's output feeding the next as structured data rather than free text — also took real tuning to keep the architecture legible rather than a single tangled prompt.

What I learned

I came into this comfortable with the business side of revenue incidents but not with orchestrating multi-step agent reasoning against live tool calls — this was my first hands-on build with Gemini's function-calling for a genuinely sequential diagnostic workflow, rather than a single-turn Q&A pattern. I also learned, practically, how much of an agent's perceived intelligence comes from tool design and state management rather than the model call itself — the funnel-walking logic only became trustworthy once each tool had a narrow, well-defined contract.

What's next for RevPilot

The natural next step is real integrations — actual payment-gateway and ad-platform APIs behind the same decision logic, with proper guardrails and human-approval gates for higher-risk actions. I'd also like to generalize the diagnostic framework beyond e-commerce revenue drops to other operational metrics where the same "detect → investigate → decide → act → verify" loop applies — support ticket spikes, churn signals, app-store rating drops — anywhere the gap between noticing a problem and fixing it is currently filled by a person doing manual detective work under time pressure.