Reap Chief Financial Officer Agent

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. It is not a claim that a fully autonomous chief financial officer is done. It is a working foundation: four finance skills share one runtime, every decision is typed, and the model only gets called where it is bounded by schemas and evidence.

4finance skills on one runtime

1decision log, idempotent + versioned

4typed outcomes — apply, suggest, refuse, escalate

0money movement without human ratification

My north star: the large language model should be a constrained tool inside a deterministic finance workflow, not the orchestrator. Every decision should be versioned, logged, and reversible.

The four skills

• Auto-tagging is where I let the large language model earn its keep: classifying card, payout, and bill events only after vendor rules and tenant evidence have had first say.
• Policy enforcement is deliberately boring. Typed rules evaluate card and bill events, then return a verdict the operator can audit.
• Accounts Payable plans when to pay, which Reap rail to use, and what the foreign-exchange or discount trade-off looks like. It never moves money on its own.
• Daily Chief Financial Officer Pulse is the proactive layer I wanted from the start: a scheduled brief that speaks first, but still points back to deterministic evidence.

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

EventFinanceEventCard authorization, payout, foreign exchange, receipt, bill, scheduled pulse — one typed shape.

→

RouteSkill registryAsks each skill whether this event is relevant for the tenant.

→

CognitionBounded thinkingDeterministic rules first; the model is only invoked behind a typed schema.

→

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

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

LearnLearning loopOverrides supersede vendor rules and can be promoted to an eval case.

BriefChief financial officer briefRanked actions for the morning, 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.