Revenue_Guardian

Revenue Guardian: Autonomous Multi-Agent Revenue Operations Platform

Comment

Inspiration

Small businesses lose time and cash chasing overdue invoices. Reminders are manual, easy to forget and awkward to write. An AI agent could do the chasing, but letting it message customers or touch money without oversight is risky. We wanted an agent that does the tedious work and still keeps a human in control.

What it does

Revenue Guardian is an AI agent that chases late payments using PayPal.

  1. It syncs invoices created in the PayPal sandbox.
  2. An overdue sweep finds invoices past their due date.
  3. Gemini drafts a friendly reminder for each one. If the model is unavailable, a template takes over automatically.
  4. Nothing is acted on until a human approves it. Role-based access control decides who is allowed to approve.
  5. When the buyer pays, PayPal sends a signed webhook. We verify the signature, mark the invoice paid and update the KPIs.
  6. Every login, approval and payment goes into a hash-chained audit log, and a Verify button checks that nothing was altered.

How we built it

  • Backend: FastAPI on Render, with JWT login and role-based permissions on every route except health and login.
  • Payments: PayPal sandbox APIs for invoices and payments, plus webhook signature verification.
  • AI: Gemini drafts the reminders, with a deterministic template fallback so the flow never stops.
  • UI: a Streamlit app with tabs for invoices, the overdue sweep, approvals, KPIs and audit verification.
  • Audit: each log entry stores a hash that covers the previous entry's hash:

$$h_i = \mathrm{SHA256}(h_{i-1} \,|\, e_i)$$

Changing any past event breaks every hash after it, so tampering is detectable.

Challenges we ran into

  • Getting the Gemini model name right. A wrong name returned a 404, so we checked the model list for our key and made the fallback robust.
  • Authentication across two hosts. The Streamlit UI and the API run separately, so tokens, secrets and passwords had to line up between them.
  • Free-tier hosting. Render sleeps when idle and our demo data resets on redeploy, so we added a keep-alive monitor and a repeatable way to create fresh invoices.
  • Deploying the multi-page Streamlit app, including a malformed secrets file that was breaking configuration.
  • Deciding where the AI stops. We designed the system so the model can only propose, and a person decides.

Accomplishments that we're proud of

  • A full loop on real PayPal sandbox objects: invoice, overdue detection, AI draft, human approval, payment, signed webhook, KPI update.
  • Safety built in from the start: approval gate, RBAC, webhook signature checks and a verifiable audit chain.
  • A graceful fallback, so the demo and the product still work when the AI is down.
  • Being clear about what is real and what is simulated.

What we learned

  • Trust features (approvals, permissions, audit trails) matter more than the AI itself when an agent is near money.
  • An LLM works best as a drafting tool behind a deterministic safety layer, not as the decision maker.
  • Webhooks and idempotent handling are essential for payment state you can rely on.
  • Deploying early surfaces problems (secrets, tokens, cold starts) that never show up on localhost.

What's next for Revenue_Guardian

  • Live reminder sending through email, with the same human approval step.
  • Production PayPal instead of the sandbox.
  • More channels such as SMS and chat, and per-customer reminder tone and timing.
  • Replacing the demo CRM data with real customer data sources.

Real vs simulated

Real: PayPal sandbox invoices and payments, signed webhook verification, approval gate with RBAC, hash-chained audit log, Gemini drafting with template fallback. Simulated or mock: the "simulate payment" shortcut, the demo CRM data, mock Gmail and Calendar. No reminder email is actually sent.

Built With

Share this project:

Updates

Submission history