Reap Chief Financial Officer Agent

~3 min read · landing page

An artificial intelligence controller for finance operations on Reap rails

I built this as the control plane I would want underneath a future artificial intelligence chief financial officer on Reap. Four finance skills share one runtime, every decision is typed, and the model only gets called where it is bounded by schemas and evidence. I treat the LLM as a constrained tool inside a deterministic workflow, not as the orchestrator — every decision is versioned, logged, and reversible.

4finance skills on one runtime

1decision log, idempotent + versioned

4typed outcomes — apply, suggest, refuse, escalate

0money movement without human ratification

How to read this submission

5 min · the argumentRead the thesisThe three self-grade paragraphs on Solution narrative. Code orchestrates, the model is a typed tool, refusal is a first-class outcome.

15 min · recommendedWalk one decision end to endAdd the Live data examples tour and the Auto-tagging page. One real database row becomes one logged decision.

60 min · the full reviewAudit the systemAdd the eval harness in Operations, the Cross-cutting decisions, and one of the remaining skill pages. Every page lists its own reading time at the top.

The four skills

W1 · CognitionAuto-taggingWhere the language model earns its keep — classifying card, payout, and bill events only after vendor rules and tenant evidence have had first say.Read the skill →

W2 · DeterministicPolicy enforcementDeliberately boring. Typed rules evaluate card and bill events, then return a verdict the operator can audit.Read the skill →

W3 · TreasuryAccounts PayablePlans when to pay, which Reap rail to use, and what the FX or discount trade-off looks like. Never moves money on its own.Read the skill →

ProactiveDaily CFO PulseThe proactive layer — a scheduled brief that speaks first, but still points back to deterministic evidence.Read the skill →

If you want the most concrete read, start with Live data examples. I walk through actual local demo rows from the queue and brief: what the user sees, what the backend writes, and why each case matters for Reap.

System at a glance

01EventFinanceEventCard auth, payout, FX, receipt, bill, scheduled pulse — one typed shape.

02RouteSkill registryEach skill is asked whether the event is relevant for the tenant.

03CognitionBounded thinkingDeterministic rules first. Model only invoked behind a typed schema.

04LogDecision logOutcome, evidence, prompt/model/rules versions, idempotency key.

05QueueOperator queueReview, accept, override — every change captured as corrected coding.

06LearnLearning loopOverrides supersede vendor rules and can be promoted to eval cases.

07BriefCFO briefRanked morning actions, each grounded in a row of evidence.

Decision loop

1. Evidence inReap transactions, invoices, receipts, vendors, policies, balances, and corridor signals enter through one event shape.

2. Decision madeOne of four typed outcomes — autoApply, suggest, refuse, or escalate — each with confidence and reason code.

3. Human controlAn autonomy rung gates what the system may execute; money movement never auto-applies.

4. Audit improvesEvery override writes a durable correction; the corrected coding becomes the next vendor rule or eval case.

Operator queue

I think the queue is the trust surface. Every row exposes outcome, confidence, evidence, version stamps, and an override path. The system only gets as much autonomy as the tenant gives it, and there is no setting where money moves without a human.