PLATFORM DESIGN

Finance tools and agents.
One programmable stack.

Use the same financial capabilities through a conversational agent or a direct API. Payment services handle the records, approvals, retries, and execution. Models help with the work but do not hold financial authority.

This architecture is under integration. The public collections prototype remains browser-local with synthetic records.

Explore a flow

Platform design

A scoped request reaches the transaction service. Verified receipt evidence is matched and committed to Neon.

Choose a component to inspect its role. Arrows show the selected data path, not live traffic.

SELECTED FLOW

  1. Create a scoped request.
  2. Check the actor and transaction terms.
  3. Verify and normalize the synthetic receipt.
  4. Commit one allocation and its event.
  5. Read the resulting state.

AUTHORITY BOUNDARIES

Keep financial authority outside the model.

Agent

Uses fixed business tools. It cannot mint receipts, reset runs, approve itself, issue SQL, or read signing keys.

Transaction service

Checks ownership, exact terms, policy, budgets, and idempotency. Only this service commits financial state.

Records and history

Every accepted action is recorded with its financial result. Operators and applications can inspect balances, statuses, and exceptions without asking the model.

One financial core.
Multiple ways to use it.

Cloudflare hosts the services. Neon holds the durable records. Hyperdrive query caching stays disabled so reads after a write reflect the committed state.

Collections, banking, and domain-specific applications share a financial tool model but maintain separate account, transfer, invoice, and claims semantics. Model providers and payment rails are replaceable.

Read the product overview