AI agent & automation · internal build
If you own the business, the money is tangled. An owner draw looks like a purchase. A card payment looks like spending. Income arrives in lumps on somebody else's schedule, and business costs quietly end up on a personal card. Personal finance apps assume a salary. Accounting software assumes a bookkeeper. Neither one watches both sides and tells you when something is going wrong.
So we built the thing we wanted. Budget Bot reads our connected bank, card and business accounts, works out what is actually spending, and sends a short message twice a week when a budget is over or heading that way. Between those messages it answers questions, builds reports on request, and flags costs that should have stopped. It runs on our own live financial data, which sets the standard for how carefully it has to behave.
What it does
It keeps one clean picture of money that sits in several places at once. Every transaction is sorted into one of a fixed set of categories, with transfers between our own accounts, loan and card payments, income and investment moves identified as what they are, so they never get counted as spending.
Twice a week it sends a short message: each budget with what has been spent against its limit, whether it is over or merely on pace to be, and a line of plain comment. If nothing needs attention it sends nothing at all. On the first message of the week it adds the position ahead, including whether the month's largest fixed payment is covered before it lands.
Between those messages it is a thing you talk to. Ask what you spent on anything, over any period. Ask for a report on a slice of it and it builds one from the actual data. Change a budget by saying so. Ask for the full position, balances included, and it answers on request rather than pushing that into a notification.
It also watches for money that should have stopped going out: a subscription that was cancelled and reappears, a business cost that was moved to the company card and turns up on a personal one again.
And when we want it to do something new, we ask for it from a phone, in the same chat. The agent prepares the change and waits for one of us to approve it before anything takes effect.
The build
Why this is harder than it sounds
The difficult part isn't fetching transactions. It's deciding what counts as spending. A bank feed is a flat list of amounts and descriptions, and in that list, money moving from a business account to a personal one, a partner's share of the rent arriving, a credit card being paid off, and a transfer into savings all look exactly like buying groceries. Count any of them as spending and every budget becomes meaningless.
So those cases are settled by explicit rules before any judgment is applied: the classification is deterministic and gives the same answer every time, rather than depending on what a model decides on the day. Only genuinely ambiguous purchases get passed to a model, and even then the answer is constrained to a fixed list, with anything unrecognised dropped into a safe default rather than guessed at.
The second problem is drift. Transactions arrive two ways: when the agent refreshes on its schedule, and when a bank pushes an update by itself. Two code paths labelling the same transaction differently would quietly corrupt every historical figure, so both go through one shared routine, and each write is keyed to the bank's own transaction identifier so a repeated refresh updates a record instead of duplicating it.
What it demonstrates
It runs on our own accounts, on real money, which is the only honest way to build something like this. An agent that talks about finances has to be right, and the fastest way to find out whether it is depends on being the one it talks to.
The part that transfers to client work is the shape: an agent that reads live data, applies rules that belong to the business rather than to a product, decides what matters, speaks up on its own, and can be extended by asking it. The boundaries are drawn so that being wrong is cheap and being silent is normal.
What it replaced
Questions we get
Yes, and the shape usually changes. The pattern here is an agent that watches a live data source, applies your rules, and tells someone when something needs attention. The data can be bank accounts, a job system, an inventory feed or a spreadsheet nobody has time to check.
The recurring messages are written by ordinary code, with no model involved in producing the figures. Where a model is used, its answer is constrained to a fixed set of options, and anything outside that set falls back to a safe default. When data can't be refreshed, the message says so rather than presenting stale figures as current.
It depends entirely on how it's built, and it's the question to ask any vendor. In this build: one deployment per person with nothing commingled, bank access stays on the server and never reaches the browser, automatic messages carry no balances, messages can only reach one recipient, and the scheduled job rejects anyone who calls it without the right credentials. We'd design the same boundaries for a client, sized to their situation.
You ask for it in one line, from your phone. The agent prepares the change, and a person approves it before it takes effect. That keeps the speed of simply asking for something without losing the review step, which is the part you want in place when the system touches money.
Because a message that arrives every day stops being read. Twice a week is frequent enough to change a decision while the month can still be changed, and rare enough that the message still gets opened. A quiet week produces nothing at all.
Numbers that only get checked once something has already gone wrong are usually a good candidate for an agent like this one. BlueSail builds them around your rules, not a product's idea of them.
