Grant Test Auto

Researcher request: Dr. Priya's $9,500 Bahamas trip is flagged before it reaches the grant office, and she sees which rules it failed.
Invoice check: A $4,800 invoice on a $4,000 order is held for the grant manager, with the difference side by side.
Grant office requests: The grant manager sees only the exceptions, each flagged by the rule it failed, and every decision needs a reason.
Researcher grants: Researchers see what they can actually spend on each grant, with the money left and a forecast to the end date.
Sources disagree: NIH RePORTER, USAspending and a cancellation list we scrape with Apify disagree, so the agents flag it.
Spending rules: Every rule is enforced in our SpacetimeDB database rather than the AI, so no model can talk past a limit.
Invoice queue: Incoming invoices wait in one queue for the grant manager, sorted by approval, rejected and done.
Real-data eval: On 37 real NIH grants, the fund tracker caught 38 of 38 cases where spending should have been stopped or flagged.
Landing page: Grant Test Auto sits between a research lab and its grant office, so researchers do science and agents do the checking.
Court-restored grant: No payment has arrived since the cut, so spending stays paused until the money is real.

Inspiration

One of our members works at UCSF's Center for Intelligent Imaging, mostly on post-training LLMs (:P but that's beside the point). At our lab meeting last week, our PI talked about how much of his time goes to the bureaucracy of getting and keeping funding instead of the research itself. That, plus the Hyphenate track, got us thinking about how to bridge autonomous finance and research.

We used Apify to scrape what researchers are saying online, along with the public lists of canceled grants, and then traced each claim back to its original source. Three facts stood out:

Researchers lose almost half their time to admin work: 44.3% of federally funded research time, according to a 2018 survey of more than 11,000 principal investigators.
Grant status is a moving target, and the records don't agree. Since 2025, $14.6B in NIH awards has been canceled or frozen, and most of it has since been restored. Meanwhile, about 300 terminated grants showed up in only one of NIH's two official databases.
Mistakes show up years later. 17 of 18 NSF audits of universities found spending that grant rules don't allow.

And every purchase hides a stack of small checks. Is the grant actually paid, or only restored on paper? Does it end within 90 days? Is the item an allowable cost at all? Today, grant managers answer questions like these by hand, for every request.

After we figured out how big this problem was (especially in such a societally important area), the solution kind of fell out naturally.

What it does

Grant Test Auto sits between a university lab's researchers and its grant office. Its agents track every grant's real money and status and check every purchase request and invoice. One human grant manager approves each one, with the reasons right in front of them.

A researcher asks for something in plain words on their own portal. Before a grant is even matched, Claude checks whether a federal grant could pay for that kind of item at all. Then the request goes through our spending rules: is the grant active and not frozen, is it in its last 90 days, is it an allowed category, is it under the card limit (including purchases split up to slip under it), and is there enough money left? "Enough money" doesn't mean the number on the award. It means what's truly available: awarded minus spent minus promised.

Here "promised" is money for orders already approved but not yet paid, and a request passes only if its price is at most what's truly available.

Every request lands in the grant manager's inbox, either ready to approve or flagged, with the failed rule and the real audit case it comes from. When the invoice comes in, the agent matches it to the original order and holds anything that doesn't add up: a duplicate bill, a bill for a canceled order, or a bill dated before its order.

Behind all of this, the fund tracker reads NIH RePORTER, USAspending and the public list of canceled grants. If they disagree, the grant freezes and the grant manager decides which source is right. A court order alone doesn't unfreeze a grant; only money actually arriving does.

How we built it

The backbone is SpacetimeDB, a real-time database that holds both the data and the rules. The spending rules, the money math, the freeze logic and the activity log live in one TypeScript module, so they run the same way every time and no model can talk its way past them. Each agent and each person gets their own database identity with exactly one role, and the database checks that role on every action.

The agents run as a Node worker on an always-on Azure VM. We used Claude Haiku for the item check and Claude for short notes on held invoices, and in both cases Claude only reads and explains, never decides. The web app is React and Vite on Vercel, and every window updates live through database subscriptions. We used Apify for a lot of our market research (scraping researcher complaints on Reddit), and we also built an Apify Actor that pulls the public list of canceled NIH grants (about 5,600 grants) straight into the fund tracker. GitHub Actions publishes the database and redeploys the agents on every push.

Challenges we ran into

The biggest challenge was understanding the project in its totality. A lot of our time went into figuring out scope: what Grant Test Auto should do, and just as importantly, what it shouldn't. We learned that some things simply shouldn't be automated. Letting an AI handle grant purchases on its own is currently a big no-no (which I learned after messaging my PhD mentor at 10 PM), so approvals always have a human in the loop.

Feedback turned out to be incredibly important. Talking to people and being forced to explain our project taught us a lot about what we were actually trying to do and how we were doing it. It also taught us that simplicity is king. After thorough testing (and more feedback), we kept simplifying features as we built: we merged things together, combined menus, closed dropdowns, and cut anything that didn't earn its place.

Accomplishments that we're proud of

We're proud of how thoroughly we scraped and pieced together all the annoying details and complaints that, together, make this such a huge pain point. Understanding a complex problem and all of its nuances was one of the hardest parts of the project, and in our opinion it's the most important.

We read through every complaint we found and built evals from real cases:

Fund tracker, 37 real NIH grants: caught 38 of 38 freezes and flags it should have raised.
Claude's item check, items from real audits: flagged 28 of 28 unallowable items.
Spending rules, real questioned costs from NSF audits: stopped 18 of 24.

Missing a bad purchase is the expensive mistake and a false alarm is the acceptable one, so we tuned for zero misses and accepted a handful of false alarms. We're really proud that the pipeline passes with flying colors.

We're also proud of how smooth and intuitive the whole loop feels: a researcher's request, the grant office's approval, the researcher's invoice, and the grant office's final approval, with checks all the way through on the finances, on whether the request fits the grant, and on whether the invoice is accurate. Understanding and organizing that pipeline in its entirety was really difficult, and it's the part we're proudest of.

What we learned

"Awarded," "restored" and "paid" are three different facts, and most tools treat them as one. A grant's status can't be a single field; it has to be a history of dated events, each with its source. We also learned where AI belongs: Claude is great at reading messy requests, but rules with legal consequences should be code that gives the same answer every time, with a person making the final call.

What's next for Grant Test Auto

My professors didn't reply over the weekend, so the first step is getting their feedback into the project, then testing and deploying it in real settings. Right now, Grant Test Auto works at the interface between the first and second layers of the process: researchers and their grant office. Next, we want to explore automating parts of the next interface, between the grant office and the official institutions that fund it. We'd do that carefully, automating the tedious parts but not everything, and staying clear of anything with legal issues or that's simply off-limits.