BR-Budget.
Software for the agent
that manages my finances.
An experiment where I test a hypothesis: what happens when the primary user of a finance application is an AI agent acting on a person’s behalf. I do not know if I am right. I am building to find out.
In May: PLN 1,273 on food, 87% of the monthly limit.19:42

What if the main user
of the application is an AI agent?
Future software will be a set of data and hard domain rules for an LLM agent standing between the human and the system.Hypothesis I am testing · 2026
I call this agentic-first. If an agent can fetch data, understand it and return with a decision, a human does not need to click around for it. The UI stays for control and corrections.
We have a precedent. Mobile-first also sounded provocative twenty years ago. First you designed for desktop and mobile was an add-on. Mobile-first reversed that logic.
Agentic-first is a similar shift, only deeper inside the product. I design data, rules, permissions and decision history so an agent can really work with them.
The human taps, clicks and reads. The app must be beautiful, clear and fast.
The human talks to the agent. The agent reads the API. The product must be machine-readable.
The human tells the agent: “check whether I can afford a new lawn mower”. The agent connects to the API, pulls the balance, categorizes expenses, checks obligations and returns an answer. The human never opens the dashboard.
The LLM does not know where I eat out, what subscriptions I have or how I account for VAT. These are data and rules living in the application. The application must be readable for the agent.
It sounds provocative. I may be wrong. That is why I decided to test it in practice.
Finance apps are great at measuring expenses. Saving is left to the user.
API-first, agent inside.
Why a budget app.
I had used YNAB for years. I paid for it. The thought “why pay for something I can build myself” kept growing. Less than a year ago I tried to build Solon, a personal finance startup. Back then the project hit the real cost of development.
Today, in 2026, I took the same project from zero to production in a few days. That difference changes the calculation for a founder or CTO building internal tools.
Solon
The same idea. It broke on time and cost. Buried.
BR-Budget
An MVP from scratch to production in a few days. Different technology, a different way of working.
The architectural decision that changed everything.
“Why am I building advanced filters and reports if the agent will soon generate them on demand?”
I started classically, UI-first. Screens, transactions, categories, reports. In the middle I stopped and shifted priority. API-first. Agentic-first.
- REST API and MCP for reading data and selected operations
- Per-user API keys connected to Claude Desktop, ChatGPT and Hermes
- Agent keys restricted to the user’s data and granted permissions
- The UI remains for control, correction and building trust
Netflix, Supabase, Lovable, OpenAI and 3 others.
Total: ~PLN 643 / month.21:08
After the purchase, there is still a 4-month fixed-cost reserve.
Yes. But I am adding it to Pause for 2 days.21:09
I really run these queries with my agent through the BR-Budget API.
The agent reads balances, categorizes expenses and suggests decisions without opening the dashboard.
What BR Budget does today.
I want to know what I can spend, what I have already planned and how much I have actually saved.
Spending control connects imported transactions, rule-based budgets and planned purchases. Pay Yourself First helps set aside part of each income, while Pause leaves time to think before a larger purchase. Agents use API and MCP within their key’s permissions.
Pay Yourself First. Before spending the rest.
When income arrives, the app suggests an amount to save. I choose a goal, a savings rate and a destination account. I can see which transfer I still need to make and which has been settled.
I divide savings into a main emergency fund and smaller goals. Progress comes from recorded deposits and withdrawals. The app helps match an actual transfer to a savings task, so declaring that I saved money is backed by a transaction.
Plans reserve money for larger purchases over the coming months. Once an imported payment arrives, I can link it to the plan and avoid counting the expense twice.

Inside: the decisions that matter.
“An experiment I run like a production system.”
Amounts are stored in grosze. A transfer has a shared transferId and outflow/inflow roles. Bootstrap loads snapshot, settings and import coverage in one request. Agent API runs in a separate authorization scope.

Earlier BR Budget dashboard with annotations explaining the mechanisms
Stack chosen for iteration speed
Speed opens new questions.
“AI in the development loop changes build speed by an order of magnitude. What matters is what you do with that speed.”
The MVP was built faster than would have been possible even a year ago. The most interesting question is: what suddenly becomes worth testing when a prototype with a real domain can reach production in a few days?
I cut points and streaks. Specific goals and fewer decisions at each income helped me save.
What the experiment showed.
The first version had points, streaks and rewards for staying on budget. I cut it after the first weeks. It did not work.
I replaced it with the Pause module. Bigger purchase? You enter the item, amount, store link and answer a control question. The system calculates a decision lockout proportional to the amount.
The break lets me return to a purchase after the first impulse has passed.

Large air purifier
The app now also includes Pay Yourself First: income detection, suggested savings, jars and transfer reconciliation. Progress is based on money actually set aside, and reaching a goal earns a trophy.
Next: signals for the agent.
An agent can already analyse data and manage plans through MCP. I am exploring when the system should send it a signal about an event.
Income arrived. A subscription renewed. A category crossed its limit. An expense appeared that looks impulsive.
Then the app speaks up on its own when it has a reason.
Pay Yourself First
- Income and suggested savings
- Savings jars and goals
- Reconciliation with actual transfers
Plans and MCP
- Money reserved for larger purchases
- Matching a payment to a plan
- Agents create and update plans within their permissions
The system contacts the agent
- Choosing events worth surfacing
- Less manual checking
- Control over automatic actions
I am building this project for myself.
It is my manifesto.
I am building BR-Budget because I want to test whether software can be designed as a system of data, rules and decisions that an agent can safely work with.
I may be wrong. I am building to find out.







