MoneyFinder

Inspiration

Small businesses leave real money on the table. Tax credits, state rebates, and agency programs exist, but finding them means digging through agency sites, working out whether you qualify, filling out PDFs, and then chasing each claim for months. Most owners never do it, and the accountant only sees the result at tax time.

We wanted to build a claims desk for a business's back office. It learns the business from its inbox, checks public-agency eligibility with citations, fills the paperwork, and tracks every application until the deposit clears. The principle we set from day one was that an estimate is never money received.

What it does

MoneyFinder Claims Desk walks a fictional business, Gowanus Kettle Brewing Co. LLC, through the whole flow:

Onboarding: Google SSO, a Gmail permission screen, an inbox crawl, and a profile builder. Every fact carries a source quote, and conflicts are shown rather than hidden.
Eligibility: 7 programs with verdicts, official-page citations, and as_of dates. Lapsed programs such as WOTC are flagged as expired and blocked.
Claims pipeline: a four-column desk (Found, In process, Approved, Paid) with a status machine, evidence, and an event log per application.
Real PDF fill: official forms are filled with provenance using PDF.js and pypdf.
Books: a 39-transaction ledger with exceptions (missing receipts, duplicates) and a downloadable accountant packet in Markdown, CSV, and XLSX.
Run history: each analysis is a 12-step run, traced in PRISM, comparing local runs with PRISM-traced runs.

How we built it

The app is Flask with Jinja pages and a JSON API. Services are split by responsibility: evidence (inbox to facts and conflicts), eligibility, applications (status machine), ledger and packet, orchestrator, nicrron, and prism.

Nicrron provides the model calls through an OpenAI-compatible client.
PRISM provides observability. One run is one session, with one trace per tool step.
Fixtures back everything, so the demo works with no network, no model key, and no PRISM key. With keys, the same run makes real Nicrron calls and emits real PRISM traces.

Money math is code, not prose. All amounts are stored as integer cents, and the pipeline enforces the ordering

$$ \text{Paid} \;\le\; \text{Approved} \;\le\; \text{Identified} $$

so a dollar can only move to "Paid" after a matched deposit. PAYMENT_ISSUED and PAYMENT_CONFIRMED are separate events. Twelve tests cover pages, API, the status machine, the deposit gate, ledger math, the packet, and reset.

Challenges we ran into

Honest money semantics. It's tempting to show one big "you've found $45,737" number. We had to keep identified, in-process, approved, and paid separate in the data model, the UI, and the demo script.
No source, no fact. When two emails disagree about a detail, the system preserves both and asks the user, instead of silently picking one.
Not faking integrations. Gmail OAuth needs a Google client and callback routes, so we shipped a synthetic inbox and said so. Likewise, Run History only shows a PRISM link after the trace is verified, and a Nicrron failure is explicit rather than quietly falling back to fixtures.
Eligibility goes stale. Programs lapse, as WOTC did, so every verdict carries a citation and an as_of date, and expired programs are blocked.
Three people, three branches. We wrote a shared API contract early so UI, ledger/agent, and observability work could move in parallel.

What we learned

Trust in financial tooling comes from restraint: citing sources, showing conflicts, and refusing to overstate.
Observability changes how you debug agents. Clustering failed runs by root cause in PRISM was far more useful than reading logs.
Making the demo run from fixtures first, then layering live integrations on top, kept us unblocked and the demo reliable.