Built for the Real World, and the Customer Impact Award
A finance agent with a path to production
The credit desk is a production-minded finance agent for a small wholesaler: a credit analyst agent and a collections clerk agent, with a human controller who signs off on anything large or suspicious. GurtOS is its path to production. Each seat runs as its own Linux user without keys, every action lands in an append-only log, approvals reach a phone, and the box picks up where it was after a power cut.
Proof Scored from the action log against an answer key, the latest live run caught 14 of 14 planted errors with 0 false alarms and decided all 6 credit applications as the key does. A simple rule on the same CRS data approves all six for $153,000, including $20,000 to a fake applicant whose $18,500 rush order would have shipped to a freight forwarder.
What Microsoft asked for
From Microsoft's track description and judging criteria, as copied into the project's track plan (docs/tracks.md).
A production-minded AI agent for finance, productivity, healthcare or similar.
MetFinance: trade credit and collections at Fogline Supply Co., a made-up Oakland wholesaler with 26 employees, about $8.1M revenue and 38 accounts on trade credit. Two agent seats (Droid running Claude) and a human controller.
Customer understanding.
MetA small wholesaler's credit desk is one or two people doing credit checks and collections by hand, where one fake customer or one misapplied payment costs real money. The case is built from those everyday failures: a synthetic identity, a payment applied to the wrong customer, a post-dated check booked as cash, an invoice billed twice, a limit nobody reviewed in 29 months.
Measurable usefulness.
MetEvery run is scored from its log: planted errors caught out of 14, false alarms, and decisions matched on 6 applications, 11 customers and 6 orders. Three live Droid runs caught 13, 13 and 14 of 14 and decided all six applications right. The simple rule is the baseline on the same data.
Path to production.
MetIt runs on GurtOS: each seat is its own Linux user with its own copy of the files, keys stay in a root-only vault, every action is in an append-only log, approvals reach a phone, the box resumes after a power cut, and the OS updates as a whole and rolls itself back. The rules are a file, so the controller changes policy without code.
Responsible design.
MetThe agent cannot approve its own large proposals, clear a fraud flag, or decide before the checks run. It never sees the answer key. Every decision names the rule and the data behind it. It pulls only what trade credit needs (no criminal or eviction searches) and never tells an applicant which check failed.
End-to-end function.
MetApplication in, seven CRS checks, a decision by rule, the controller's approval on a phone, the decision in the log, the run scored. The merge gate runs this path on every merge, live against CRS and Nessie.
Customer Impact Award.
MetThe customer is the controller at a small business: the desk does the checking and the paperwork, stops the one application that would have cost $20,000 of credit, and brings only the decisions that need a person to their phone, with the reason and the data attached.
Screenshots


Open it yourself
- The credit desk's code and README
- Live run 73c47b (14 of 14)The analyst's and clerk's reports, the score and the run's action log.
- The answer key
- Full credit desk write-up for HyphenateThe planted errors one by one, the log of the moment, and how to run your own case.
- Docs: what GurtOS is
- Docs: system updates and rollback
Evidence
Measured: three live runs
| Run | Rules | Planted errors caught | False alarms | Credit decisions | Collection steps | Orders | Time, model cost |
|---|---|---|---|---|---|---|---|
88d75b |
0.1 draft | 13 of 14 | 1 | 6 of 6 | 9 of 11 | 6 of 6 | 9 min, about $1.50 |
6f5c0b |
0.2 (Mana) | 13 of 14 | 1 | 6 of 6 | 9 of 11 | 6 of 6 | 9 min, about $3.54 |
73c47b |
0.2, seats told to record follow-ups | 14 of 14 | 0 | 6 of 6 | 9 of 11 | 5 of 6 | 13 min, about $4.67 |
The baseline: the simple rule in the rules file approves all six applications for $153,000. Following the rules, the desk approves $8,000 itself, sends $83,500 to the controller at reduced limits, and stops $20,000 as fraud.
What the controller saw
In run 73c47b the analyst asked the controller five times. Each question carries the decision, why, and the
figures. The fraud referral, shortened:
Credit desk [APP-1043 fraud hold 0]: fraud referral. Put Pacific Crest Provisions LLC (APP-1043) on fraud hold,
no credit, cash in advance only? The analyst found: Four independent fraud stops: (1) FRD-1, TransUnion identity
returned code 2201 (SSN not associated with name) and code 2202 (DOB mismatch). (2) FRD-2, Fraud Finder risk
score 88. (3) FRD-3, business registered 2026-09-01 (52 days before the case date) but the application claims
4 years in business. (4) FRD-4, six compound signals present (threshold is two) ...
Rules: FRD-1, FRD-2, FRD-3, FRD-4, FRR-1, FRR-2, FRR-3, GEN-1, CHK-1, CHK-3.
Production checks on every merge
The merge gate, ./demo, runs the whole box on a fresh test VM before anything reaches main. The Oct 24 run passed
22 sections and 175 checks with 0 failures, in 102 seconds on the x86 test VM. The parts this agent leans on:
moment 2: the booby-trapped page
ok it could not read the vault: root only
ok no secret anywhere in its environment or files
moment 3: a pause for your OK
ok another task kept running and finished while P waited
ok only one of the two parallel $0.60 payments went through: $0.60 spent, not $1.20 (atomic budget)
moment 4: pull the plug
ok the long job carried on from where it was: no step done twice, none skipped
ok the deploy is still waiting for its OK, live in SpacetimeDB
track credit-desk
ok the fraud referral paused the analyst until the controller answers
ok the analyst cannot approve $40,000 on its own: above its $10,000 authority, nothing is recorded until the controller answers
ok the clerk cannot release a credit hold; that needs the controller
ok no CRS or Nessie key is anywhere in the log
How it works
- YouA credit application arrivesA case folder: the ledger, applications, bank statements.
- TaskThe analyst and the clerk work itDroid running Claude, two Linux users, no keys, no network.
- GurtOS coreTools hold the keys and the rulesCRS and Nessie calls run in the core. A decision must cite rules that exist.
- OutsideCRS and NessieCredit, identity and fraud data; the bank's deposits.
- GurtOS corePause for the controllerAbove $10,000 or on any fraud hold. Other work keeps running.
- YouThe controller says yes or noOn the portal or a phone.
- GurtOS coreLogged and scoredEvery call, decision and approval in an append-only log; each run scored against the answer key.
- Task
- its own Linux user, its own copy of the files, no keys
- GurtOS core
- the GurtOS service on the box, root, the only part that reads the vault
- Outside
- a service outside the box
- You
- a person, on the portal, a phone, Jira or a chat
Why the box is the path to production. A finance agent that runs as a script on someone's laptop has the laptop's keys, can write anywhere, and leaves no record a controller can audit. On GurtOS the same agent:
| Production need | What GurtOS does |
|---|---|
| Least privilege | Each seat is its own Linux user with no sudo, its own copy of the files, and only its job's tools. Segregation of duties is tool access. |
| Secrets | CRS and Nessie keys live in a root-only vault. Tools that need them run in the box's core; the seats get results. |
| Human approval | The tool returns "needs controller"; the box pauses only that task and sends the question to the portal and phone. |
| Audit | One append-only, fsynced action log: every call, result, approval and cost. Decisions carry rule ids and CRS request ids. |
| Reliability | After a power cut the box rebuilds every task from the log and resumes it. Updates install to a second system slot and roll back if unhealthy. |
| Change control | The rules are a YAML file. Swap it per run with {"rules": "/path/to/rules.yaml"}; the tools refuse rule ids it does not have. |
| Regression testing | Every run is scored against an answer key from its log, so a prompt or rules change is measured, not guessed. |
Try it
On a box with CRS_USERNAME, CRS_PASSWORD and NESSIE_API_KEY in its vault:
curl -s -X POST localhost:7700/t/credit-desk/run -d '{"case": "fogline-2026-10"}'
curl -s localhost:7700/approvals
curl -s -X POST localhost:7700/approvals/<id> -d '{"approved": true, "by": "controller"}'
curl -s -X POST localhost:7700/t/credit-desk/score -d '{"run": "<run>"}'
Any case folder that passes check-case.ts runs the same way with {"dir": "/path/to/case"}. The Hyphenate page
has the steps for writing your own.
Live, test and simulated
| Part | State | Details |
|---|---|---|
| Agent seats | Live | Droid running Claude in the scored runs. The merge gate uses scripted seats that call the same real tools. |
| CRS and Nessie | Live | Both sandboxes, called live. CRS's own test identities only. |
| The controller in scored runs | Simulated | A script answered yes so runs can be scored unattended, and the log says so. On a live box a person answers. |
| Business credit file | Simulated | The CRS sandbox has no business credit route; the file is made up and labeled. |
| The company | Simulated | Fogline Supply Co. is fictional. No money moves: the desk decides credit and records collection steps. |
Limits
- The scorer checks decisions field by field, but a finding counts as caught by matching its rows, wording and rule ids, not by checking that its conclusion is right.
- Two collection steps differ from the key in every run: the clerk put two over-limit customers on credit hold (rule COL-3) instead of the aging step the key lists.
- The business credit file is simulated, and the bank is read, not written.
- The controller is one role. Routing approvals by amount to different people is planned for GurtOS Business.