Regent is being built to run a business’s back office inside limits you set. It checks every change against rules written in plain words and stops when a person needs to decide. It starts with accounts payable, beside the accounting software you already use.
Regent hasn’t touched a real business’s books yet. Everything on this page comes from a simulator.
A lookalike domain sends “new bank details”. An invoice arrives twice with the number printed differently. A surcharge creeps into a unit price. In a small business, one person often enters the bill, changes the vendor record and releases the payment. Regent is built so that person always gets a second check that cannot be talked out of it.
We tried two common payment scams on a simulated business. Here is what happened, step by step. Every model answer is replayed from a recording, so the run is repeatable.
A bill arrives, matches its order and is paid.
The same bill comes back as a “reminder”, with the number written differently. Regent sees it is the same bill and refuses it.
The email asks for payments to a new account. The clerk falls for it and changes the vendor’s bank details. The new account starts unverified.
Someone pushes an urgent payment to the new account. Regent refuses: money only goes to verified accounts, however urgent the request.
The regular payment run pays the other vendor and leaves Granite out. A call to the number already on file exposes the scam, and the old account is restored.
SCENE 2 a duplicate invoice: the kernel refuses it
Granite Office Supply e-mails invoice GOS-88774, then
again as a 'reminder' with the number printed
differently ('gos88774').
day 9 CaptureVendorInvoice -> COMMITTED
MatchInvoice -> COMMITTED
PostVendorInvoice -> COMMITTED
day 12 CaptureVendorInvoice -> REJECTED DUPLICATE_INVOICE
AP items for Granite : 1 (gross 3545.62, paid)
payments to Granite : 1 (3545.62, settled)
labelled Fault F-DUP-INVOICE: held=True tp=1 fp=0 fn=0
SCENE 3 a vendor bank-detail change: the kernel holds the money
day 14 e-mail: "Updated remittance details - effective
immediately". It asks AP to pay Granite into a new
bank account. The AP clerk falls for it.
ChangePartyBankAccount (AP clerk) -> COMMITTED
new account lands unverified, in cooling-off
RecordVendorPrepayment (urgent) -> REJECTED INV-10
kernel: payee account granite-office-2 of
granite-office is unverified
Payment run PR-0116 (day 16) -> 1 payment(s),
total 1260.14: metro-power; Granite is left out
Callback to the phone on file -> RevertBankAccount
COMMITTED
INV-10 payments only to verified payees: PASS
(paid to unverified: 0)
labelled Fault F-BEC: held=True tp=2 fp=0 fn=0From the simulator demo run, seed 42, lightly condensed. Fictional vendors; no real money or data. Open the full terminal capture (image)
The model is never trusted with the books. Every change is a typed Command that the kernel checks before a person sees it.
Agents read invoices, packing slips and bank feeds and draft typed Commands. An agent cannot write to the books any other way.
The kernel dry-runs every Command and checks policy and ledger rules in the database, not in the model. A Command that fails a check is held, however confident the model was.
What reaches a person is the exact diff the dry run produced. Nothing commits until someone signs off on it.
Any area of the business can sit at its own level, and you can take the controls back at any moment.
Regent drafts the work and stops at every step that pays, sends, posts or changes terms. This is how every area starts, and how the AP pilot runs.
Once an area has earned it, you write a mandate in plain words: what Regent may do, the checks behind it, what it must never do, and how much it may move. Anything outside the limits comes back to you.
The aim is control, not speed. These are five of the 70 labelled fault types our simulator injects and scores. They are the cases the kernel is built to hold for a person before a payment goes out.
The same bill sent twice, or re-keyed with a new number.
A “new account” email that would send a real payment to the wrong place.
An invoice that does not agree with the purchase order and the packing slip.
A unit price or surcharge that jumped from what you agreed.
A payment above the amount a person or role is allowed to release.
Every area starts in shadow, deciding silently while your team works as usual. Authority grows only when the evidence is there, and every change names who made it and who approved it.
Regent is built as one set of books with modules that switch on per business. The simulator already exercises 10 business domains; real books start with accounts payable and widen one area at a time.
Regent is in development. It has not run on a real business’s books yet; our own books go first, in January 2027.
10
Verified to the penny against an independent reference ledger, in simulation.
70
Faults the simulator injects on purpose, each labelled so catches and misses can be scored.
0.875
The scenarios are held back and their seeds stay secret. Not every scenario passes yet; the gap is being investigated.
341
Each is a typed Command the kernel can check. There is no other way in.
Each phase starts only when the one before it has passed its checks. The mark shows how much authority Regent holds at that stage: none in the simulator, shadow on real books, then asking first.
Harden the kernel, add per-person sign-in, and close security findings before any live bank credential is connected.
Regent keeps GDG’s books alongside the current method. Agents propose; nothing is committed on their say-so.
Accounts payable beside the accounting software a business already uses, read-only.
Bank reconciliation and purchasing come next, each only after the one before it holds up.
Keep paying bills the way you do now. Regent watches in shadow mode and shows you what it would have held. The pilot is free.
The demo, the roadmap and the numbers, in one place.
