Skip to main content
Breadbox isn’t a dashboard, and it isn’t an agent. It’s infrastructure: a database of your household’s financial data and an surface that hands that data to the AI apps you already trust. The whole system only earns its keep when an agent is doing the boring work for you and pinging you when something needs attention. The two properties that make this worth doing at all:
  • Your agents bring their own context. The Claude or ChatGPT that knows your family, your business, your subscriptions, your Gmail archive can categorize and analyze financial data with an accuracy a pattern-matcher can’t touch.
  • The system compounds. Every ambiguous case an agent resolves can be persisted as a Breadbox rule. Breadbox auto-applies those rules on every subsequent sync, so each review pass starts from an ever-more-accurate baseline. Your rule library becomes a custom, self-improving model of your financial life, maintained by the agents you already use.

​
The basic loop

Across every mature Breadbox setup we’ve seen, the same four pieces keep showing up:
  1. Transactions flow in from Plaid, Teller, or CSV — Breadbox’s sync engine handles this on a schedule and via webhooks. For the full field schema and sync mechanics, see How Breadbox syncs, stores, and exposes transactions.
  2. Rules pre-label what they can. Everything reliably patterned — Amazon → Shopping, PG&E → Utilities, transfers over some threshold → — is auto-categorized or auto-tagged at sync time. The rule library grows as the agents below teach it; see Rules and the Understanding Rules guide.
  3. An agent reviews the batch on a cadence. It looks at what the rules pre-labeled (to verify) plus anything explicitly tagged for follow-up. As it works, it leans on its own context — your subscriptions, your email receipts, the household habits it has picked up — plus Breadbox’s MCP tools (query_transactions, update_transactions, submit_report). When it spots a pattern it sees repeating, it writes a new rule so Breadbox pre-categorizes that case on every future sync.
  4. You look at reports, not transactions. The agent surfaces anomalies (unusual charges, broken subscriptions, new counterparties) in reports or an out-of-band channel (Slack, email). Your role shrinks to resolving the genuinely ambiguous cases.
The first time you run this loop, every transaction gets the agent’s full attention. A month in, most are already pre-categorized by rules the agent itself wrote — so the review pass becomes mostly fast confirmations, and the agent spends its real thought on the outliers. That compounding effect is the point.

​
Pick your review pattern

The three patterns below are ordered by increasing autonomy. Start at the top and move down only when the one above isn’t enough.

One agent, on demand

You open Claude (or another MCP client) when you have a few minutes, ask it to walk the needs-review backlog, and approve its suggestions. Simplest possible setup.

Specialists per tag

You split review across agents — one handles subscriptions, another handles peer-to-peer, another handles general categorization. Good when a single prompt starts feeling overloaded.

Always-on autonomous agent

Openclaw (or similar) runs on a VM, wakes up on a cron, drains the backlog, and pings you via Slack/email when something needs attention. Set-and-forget, with escape valves.

​
Tactical recipes

Pattern-specific guides for narrower jobs that don’t neatly fit into “review everything”:

​
New to the primitives?

If terms like pipeline stage, condition tree, or seeded needs-review tag don’t mean anything yet, detour through these first:

​
Conventions used in these guides

  • Every guide links back to the underlying reference docs — click through to /transactions/*, /mcp/reference/*, or /api/* for the full surface.
  • Examples use real MCP tool names and real API endpoints. Paste them into an agent prompt or adapt to your setup.
  • Amounts follow Plaid convention — positive = money out, negative = money in. Summarize “spending” by summing positive amounts only.
  • Some guides lean on capabilities that aren’t yet stable (third-party MCPs, in-flight features). Those sections carry a draft note — verify before relying on them.
These guides assume Breadbox is installed, at least one bank is connected, and you’ve generated an API key. If any of that is new, start at What is Breadbox?, then Install, then Onboarding.