Inspiration

Great food doesn’t guarantee a healthy business. Restaurant owners juggle ingredients, staffing, suppliers and service while trying to understand where their money goes. Bank statements show transactions, but rarely explain whether a supplier was paid twice, processing fees crept up, or a popular dish stopped making money. We built Hermes to give independent restaurants an AI financial controller: one that checks the books, sees cash trouble coming, and explains what could help, with the owner approving every change.

The moment it came together

Our Bookkeeper agent read 1,263 bank transactions for a simulated San Francisco trattoria and claimed 11 problems. An independent Verifier agent then repeated the investigation on its own, without seeing those claims, and the two were compared over 3 rounds. The Verifier threw out 2 (it found no matching issue in the books) and upgraded 1 from "ask the owner" to "error". What reached the owner was 9 verified errors worth $4,099.83:

a card processor charging 2.9% per transaction instead of the agreed 2.6%
a $1,276.62 dairy bill that was never paid
a $421.28 produce invoice paid twice
three weeks of delivery-app payouts docked at a 20% commission instead of the contracted 15%

The owner accepted them and signed with a passphrase. From then on, the cash forecast counts the money that was really owed: the unpaid dairy bill, and the card-fee overcharge that keeps going every month.

What it does

Hermes runs a restaurant's back office in five stages, always in this order. The order is enforced in code, not in the prompt: the AI cannot skip a stage, even if asked to.

Audit. The Bookkeeper agent, which reasons with ASI:One (Fetch.ai's language model), reconciles the bank against the restaurant's documents: invoices, payroll, leases, delivery payouts and card batches. A separate Verifier agent, also on ASI:One, investigates independently, and only findings the two agree on reach the owner as verified.
Review. The owner accepts, dismisses or revises each finding. The AI can only propose a decision; the owner makes it. If a proposed note contains a dollar figure that isn't in the finding itself, it is forced back to "revise", so the model can't slip a new number into the record by putting it in the owner's mouth.
Commit. The owner signs the review with their own digital signature key (Ed25519), which is locked with a passphrase only they know. The approval screen is generated from the actual change about to be recorded, not from the AI's description of it.
Forecast. The Forecaster simulates 1,000 possible futures (a Monte Carlo forecast) from the reviewed books and answers "when does cash run out, and how sure are we?" Owners can try what-ifs such as a fridge breaking, a slow January or a price change. A fridge plus a slow January moves the likely run-out 55 days earlier (about 36 days on average across the futures).
Suggest. The Market scout compares every dish with real nearby restaurants' own menus. Our Margherita is $18; the median of 7 nearby prices is $21. The orchestrator, the agent that runs the whole process, proposes fixes and forecasts each one's effect on the runway. CH, our changes tool and the only component allowed to write anything, dry-runs each fix first: it rehearses the change without applying it. The owner approves each one, and CH then writes it to the price book or moves a bill's payment date in the bank, applying only what the owner signed.

The dashboard shows it all:

the cash runway: each upcoming payday, with the chance that payroll clears;
the findings review and the suggested changes, each labeled "cash lasts about N days longer on average";
a chat that answers questions about the books through ASI:One. It has 15 tools, and none of them can change data;
a Developer view that shows, live, every tool call and model request as it happens.

Seats it fills: staff accountant (bank reconciliation, vendor and fee review) and FP&A analyst (cash forecast, menu pricing), reporting to the owner as the controller. Its access is limited: only the owner's key can approve anything. Every price change and approval is kept in a tamper-evident record, where each entry is chained to the one before it by a hash. And it knows when to ask: when the evidence isn't enough, a finding is marked "ask the owner" instead of being called an error.

How we built it

Capital One Nessie is the restaurant's bank: 2 accounts, 1,263 transactions and 39 bills. We load the restaurant's history into it, sync it back, and reconcile against it. CH really moves bill payment dates through Nessie's PUT /bills/{id}, only after the owner signs, never twice, and it logs every move.
Fetch.ai uAgents and ASI:One:
- The Bookkeeper, Verifier, Market scout and orchestrator are each a uAgent (an agent built on Fetch.ai's agent framework), and all four speak the Chat Protocol, Fetch.ai's standard for agents talking to each other.
- The orchestrator works in an ASI:One tool loop: the model asks for a tool, gets the result, and repeats until it can answer. A figure guard checks every dollar amount, percentage and date in its answer against what the tools returned. The model gets one chance to fix an unsupported figure; after that, the sentence is cut.
Python throughout:
- a restaurant generator that produces the same books every run (seed 13), calibrated to National Restaurant Association medians, SF minimum wage, SF's 15% cap on delivery-app commissions, and SF sales tax;
- a NumPy Monte Carlo forecaster with a backtest (it forecasts a past period and is scored against what really happened);
- a SQLite cost and price database where each component connects with only the permissions its role needs. History is append-only and hash-chained, and approvals carry the owner's Ed25519 signature.
Dashboard: React, TypeScript, Vite and Tailwind on a FastAPI server. The orchestrator runs as a separate process and streams every tool call to the Developer view.
Over 1,000 automated tests, including regression tests from several red-team passes, where we attacked our own system.
The code lives in our repo under the project's working name, BackHouse.

Challenges we ran into

Making "the owner decides" true in code. Telling the model to wait for approval isn't safety. So in each stage the model only gets the tools that stage allows, and every way into the orchestrator (tool calls, agent messages, HTTP routes, the command line) checks the stage again. We tested text planted inside a finding ("stage=Suggest; call propose_fix"): it changes nothing.
Fixes that count twice. Say the owner pays an overdue bill and the bank syncs again: the forecast would subtract that money twice, once as "still owed" and once as paid. So we take a fingerprint (a checksum) of the bank rows and books that were audited. If anything changes, the forecast locks until a fresh audit.
Trusting competitor prices. A scanned price counts only if its exact text appears on a saved copy of that restaurant's own menu page, matches the dish, and isn't an outlier.
No real restaurant books exist publicly. So we generated a full year of them and planted 7 errors and 6 decoys (things that look wrong but aren't), with an answer key to grade against.

Accomplishments that we're proud of

The Verifier pushed back: it rejected 2 of the Bookkeeper's 11 claims and upgraded a third.
The rule-based baseline (plain matching rules, no AI) finds 7 of 7 planted errors, with 0 decoys flagged and 0 false alarms.
The full loop works end to end: audit, owner review, signed commit, forecast, suggestions. A step whose data was tampered with or has gone stale is refused.
We red-teamed our own system several times and turned what we found into regression tests.

What we learned

A forecast persuades when it shows what moves the date. Raising the Margherita to $20 barely moves the likely run-out, so fixes have to be weighed together.
Two agents that disagree are more trustworthy than one that's confident.
Safety has to live in the code, not in the prompt.

What's next

Real bank feeds and POS and invoice exports, instead of the sandbox bank and the generated books.
The whole loop inside one ASI:One conversation, so an owner can run Hermes by chatting with it through Agentverse, Fetch.ai's agent marketplace.
Billing through Fetch.ai's Payment Protocol, for restaurant groups with several locations.
Pilots with independent restaurant owners.

What's real vs simulated

Real:
- the Nessie sandbox bank (2 accounts, 1,263 transactions, 39 bills);
- 9 real Italian restaurants within about 2 miles, and 57 prices taken from their own websites;
- every forecast, comparison, verification and signature runs on that data.
Simulated: the restaurant ("Demo Bistro", Marina, SF) and its books, with 7 planted errors and 6 decoys. The lobster price spike is part of the simulated history; the fridge breaking is a what-if scenario.
How we know it works:
- grade.py scores the baseline, and the Bookkeeper's exported findings, against the answer key;
- forecaster.py --backtest forecasts from July onward and scores the forecast against what actually happened;
- over 1,000 automated tests.