Appearance
Unified product framing
~6 min read · section overview · who the user is, what the wedge is, what "working" looks like
TAKE-HOME BRIEF
The brief's product-thinking axis asks: who is the user and what is the job-to-be-done; what is the wedge; what metrics define "this is working" in customer terms; how does the user stay in control when the agent is wrong; and what is the rollout path. This page answers each. The short version: the user is the controller or CFO; the wedge is finance-agent infrastructure on Reap rails; the north-star metric is reversal rate; and the trust surface is the operator queue — one row, one decision, one override path.
What "working" looks like in customer terms
Each of the four skills moves one number a controller or CFO already tracks. Reversal rate is the internal north-star; the cells below are what the customer feels.
Close-day reductionHours saved per month-end on the coding queue; reversal rate measures whether the savings hold.Auto-tagging
$ leakage avertedOut-of-policy spend caught at swipe instead of recovered after the fact (today ~5% of card spend leaks).Policy enforcement
Days-to-pay + discount captureBill cycle from inbox to scheduled payment, plus dollar value of early-pay discounts that would have been missed.Accounts payable
Proactive catch rateCorridor, fraud, and leakage signals surfaced in the morning brief before they become recovery work.Daily pulse
The product I am proposing is not one clever agent. It is a reusable chief-financial-officer-agent control plane: one event substrate, one trust runtime, and multiple finance skills that can graduate through autonomy over time.
The unifying insight
Reap already sits across cards, payouts, expense controls, stablecoin settlement, and embedded finance application programming interfaces. That is why I did not want to build a generic accounting chatbot. The harder and more valuable problem is the governance substrate: how do several finance agents make reviewable decisions without corrupting books or moving money silently?
FactsSame factsCards, bills, payouts, foreign exchange, receipts, vendors, balances, policies, and chart-of-accounts entries become one FinanceEvent substrate.
$Same control modelEvery action is mediated by refusal, autonomy rung, evidence, human approval, and audit history.
ModelSame cognition boundaryLarge language models are tools for bounded classification or narration. Workflow order, money gates, and math remain code.
NOSame honesty cutLedger posting, payment execution, vector retrieval, and natural language policy compilation are explicit seams, not hidden claims.
What is shared
| Layer | Why it is shared |
|---|---|
| Transaction and invoice events | All skills need the same facts: merchant, amount, currency, corridor, vendor, receipt, due date |
| Vendors, chart of accounts, policies, balances | The classification, policy, accounts-payable, and pulse decisions are only credible when they use the same source of truth |
| Refusal contract | "I don't know" must be a typed outcome, not a prompt convention |
| Autonomy ladder | Finance teams need one adoption model: shadow -> suggest -> assisted -> autonomous |
| Decision log | Audit, evals, rollback, and operator learning all come from the same append-style register |
| Override capture | Human corrections become immediate vendor rules and future eval cases |
| Multi-tenant boundary | Tenant identifier is first-class in the database shape and query layer |
The interlock
LedgerAuto-taggingClassifies card, payout, and bill events to general-ledger codes. Feeds close quality and downstream policy analytics.
POLPolicy enforcementEvaluates deterministic rules against spend and bill events. Uses categories and receipts as evidence.
$Accounts PayableSchedules bills, estimates foreign exchange, chooses Reap rail, and enforces dual control. Its paid bills later need coding.
BriefDaily Chief Financial Officer PulseTurns logged decisions, bills, balances, corridor spreads, and leak signals into the morning action brief.
These dependencies are operational, not decorative:
- Policy needs Auto-tagging because many policy questions are category-scoped: entertainment, travel, ads, software, payroll.
- Accounts Payable needs Auto-tagging because every paid bill eventually becomes a ledger entry.
- Accounts Payable needs Policy because payment approvals, new vendor holds, structuring detection, and high-value dual control are policy gates.
- Pulse needs all three because a chief-financial-officer brief without logged decisions, bills, and policy findings is just a dashboard summary.
This is why I kept coming back to the platform. If I built any one skill in isolation, I would end up rebuilding trust mechanics badly each time. If the platform is right once, the next skill becomes mostly a trigger, schema, rule or prompt bundle, eval set, and adapter.
Platform versus skills
Platform, built once
| Component | Responsibility |
|---|---|
| Event ingest | Normalize Reap card transactions, invoices, receipts, payouts, foreign-exchange events, and scheduled pulses to canonical events |
| Skill registry | One event -> one or more registered skill runs |
| Large-language-model tool layer | Provider-agnostic, schema-typed calls through OpenRouter and the Vercel Artificial Intelligence Software Development Kit |
| Decision log | Outcome, evidence, rationale, prompt/model/rules versions, token counts, autonomy rung, idempotency key |
| Refusal contract | autoApply, suggest, refuse, and escalate with structured reason codes |
| Autonomy ladder | Shadow, suggest, assisted, autonomous; configured per tenant and skill |
| Override capture | Operator correction path that feeds vendor rules, retrieval flags, and eval cases |
| Eval harness | Golden sets per skill, model sweep, slices, calibration, replay hooks |
| Operator user interface | Queue, detail, overrides, bills, treasury, forecast, policies, agents, and /brief |
Skills, built per workflow
Each skill defines its trigger, decision target, action space, cognition bundle, eval set, and adapter boundary. The important production decision is that the skill does not own trust mechanics. The platform does.
What is built end to end
Auto-taggingLarge-language-model path, vendor-rule short-circuit, decision policy, overrides, and evals are live.
Policy enforcementTyped rule engine is live. Natural-language compiler and grey-zone model classifier remain designed seams.
Accounts PayableScheduling, foreign-exchange estimate, treasury route, discounts, fraud holds, and dual control are live; payment rails are not.
Daily Chief Financial Officer PulseScheduled pulse, deterministic signals, optional narration, and /brief rendering are live; production monitors are next.
| Skill | Cognition | Large language model? | Outcomes | Where to read |
|---|---|---|---|---|
| Auto-tagging | Vendor-rule short-circuit -> retrieval -> Zod-typed large-language-model call | Yes, gated | autoApply / suggest / refuse | /skills/auto-tagging/ |
| Policy enforcement | Deterministic rule engine over typed policy bundle | No hot-path large language model | autoApply / suggest / refuse | /skills/policy-enforcement |
| Accounts Payable agent | Scheduler + early-pay discount + source picker + foreign-exchange estimate + dual-control gate | No | suggest / escalate / refuse | /skills/accounts-payable |
| Daily Chief Financial Officer Pulse | Scheduled deterministic analysis over cash, corridor, leakage, anomaly, and scenario signals | Optional narration only | suggest / refuse | /skills/daily-pulse |
Why this is Reap-shaped
I do not see this as a generic accounting bot. The decision payloads carry fiat and stablecoin realities: multi-currency card spend, United States Dollar Coin-funded payout corridors, Reap Direct balances, Reap Pay/accounts-payable routing, and Optimize-like treasury choices. That makes the chief-financial-officer-agent control plane feel like a natural extension of Reap's stablecoin-enabled finance stack, not a bolt-on ledger assistant.
Read next
- Reap context — current product and strategic context
- Solution narrative — the full design story
- Cognition flow — how one event becomes one logged decision