We let machines write our code. We let them draft our prose. We let them audit our networks, scan our supply chains, and generate our diagrams.

But money? Money is still managed like it’s 1995.

I reconcile spreadsheets. I check payment dates manually. I estimate whether I can afford something by doing mental arithmetic against a self-created budget document that’s already stale. This is absurd.

The Butler Model

The ultra-wealthy have a person — a family office manager, a private banker, a CFO for their personal finances — who knows their full picture and answers one question in real-time:

“Can we afford this?”

Not a spreadsheet. Not a budget category I defined six months ago. Not a gut feel. A real answer, computed against the current state of everything: income, obligations, upcoming expenses, reserves.

In 2026, that person doesn’t need to be a person. It needs to be an AI with API access to your accounts and a rule engine you control.

What It Does

The interaction looks like this:

Architecture Diagram

Why This Doesn’t Exist for Normal People

The components are all there:

Component Exists Gap
Real-time account data Open banking APIs, Plaid, YNAB Fragmented per country/bank
Rule engines paperclip-clj, Drools, rule engines Not wired to personal finance
AI interfaces ChatGPT, Claude, Gemini No financial context
Payment execution Bank APIs, PayNow, crypto Needs user authorization for every transaction

The missing piece isn’t technical — it’s integration. A butler that knows your accounts, your rules, your patterns, and your risk tolerance. That’s a configuration problem, not a research problem.

The Configuration

The rules are simple. They don’t need machine learning. They need logic:

;; Pseudocode for a financial butler rule engine
(defn can-afford? [purchase-amount]
  (let [balance     (get-current-balance)
        debt        (get-total-monthly-debt)
        expenses    (get-upcoming-expenses 30) ;; next 30 days
        reserve     (* expenses 3)            ;; 3-month emergency fund
        discretionary (- balance debt expenses reserve)]
    (if (>= discretionary purchase-amount)
      {:approved true :headroom discretionary}
      {:approved false :shortfall (- purchase-amount discretionary)})))

Three inputs. One boundary condition. One boolean output.

What It Replaces

You know that feeling when you outsource a task to a tool and immediately forget it existed? That’s what this should feel like. Money management should be a passive background process, not a recurring cognitive event.

Why 2026?

The LLM advances of the last 18 months made this trivially implementable. The reasoning layer is solved. What remains is connecting the reasoning layer to the data layer — account balances, transaction history, recurring obligations — through a permission model you control.

This is not a moonshot. This is a weekend project with the right API keys and a rule engine.

The only reason it doesn’t exist is that the people who could build it (engineers) are busy building fintech products for venture capital, and the people who need it (everyone else) can’t build it themselves.

I’m an engineer who needs it. So I’ll build it.


This is a design doc, not a product announcement. If you’ve built something like this, I’d love to hear about it.