The short answer
Yes, and these are the payments an agent is best at. They're frequent, structured, repetitive and boring — the opposite of "book me a flight". Nobody wants to approve an electricity bill every month or type twelve affiliate payments by hand on the first. An agent with a bank account does exactly that, inside a budget and a threshold you wrote once, and holds anything unusual for you.
The condition is an account of its own. An assistant that only reads your bank can remind you an invoice is due. An agent that holds an account with an IBAN can pay it.
Why bills are the best first job for an agent
Three properties make bill payment the strongest thing an agent can do with money today.
It works now. A bank transfer from an account the agent holds doesn't hit a CAPTCHA, doesn't trigger 3-D Secure, doesn't re-price. The rails — ACH, SEPA, Faster Payments — are older than the agent and don't care who typed the instruction.
It has a natural checkpoint. A new payee, or an amount above a threshold, is an obvious place to ask a human. That's how a good finance team already works; the agent just applies it to your life.
It's high-frequency. Utilities, rent, software, a supplier a month. The agent earns its place by the tenth bill, not by a single spectacular purchase.
Invoice in, payment out
The flow, step by step, with the rule that governs each step.
- Drop the invoice in the chat. PDF, photo, forwarded email. The agent reads payee, IBAN, amount, due date and reference.
- Check it against your rules. Is the payee on your allowlist? Is the amount under your approve-above threshold? Under your per-payee ceiling? Inside this month's budget?
- Pay, or hold. Inside the rules: paid by SEPA on the due date, receipt posted. Outside them: prepared and held, with the reason stated — "new payee, above €250".
- You tap. Approve or decline. On approval the payee joins your list; next month's invoice from them runs without asking.
A standing version does the same for recurring bills: "pay the Iberdrola bill when it arrives each month, up to €120" becomes an allowlist entry with a ceiling. The agent pays inside it and holds anything over.
Subscriptions: the difference between finding and stopping
Every money app promises to find the subscriptions you don't use. Most can. What they can't do is stop them — because they didn't issue the card that pays.
An agent that holds its own card can. Move your subscriptions onto the agent's own debit card — a normal card, issued by Navoka, on which every renewal is checked against your rules. Now:
- Paying is automatic and inside the budget; no 3-D Secure after the first authorization, because the merchant holds a card-on-file credential.
- Watching is trivial: the agent sees every recurring charge on its own card.
- Stopping is a card-level action. Say "cancel it" and the agent blocks that merchant at the card. The next charge is declined at authorization — regardless of what the merchant's cancellation page does, or doesn't do.
That asymmetry — advise versus enforce — is the single clearest way to tell an agent with its own account from a bot over your bank.
Payroll from a spreadsheet
The same machinery scales from one invoice to a list. Contractors on the 28th, affiliates on the 1st, creators when their invoice arrives.
- Input: a CSV, a list in the chat, or a pile of invoices. The agent reads payee, amount, currency and rail per line.
- Rules: a per-invoice ceiling, a monthly cap for the batch, a payee list. A payee it hasn't seen before is held; a batch above the threshold is held for one tap.
- Approval: one for the whole batch, not one per line.
- Output: a receipt per line, in the ledger, matched to the sheet row.
Rails follow the payee: ACH for a US contractor, Faster Payments for a UK one, SEPA for a European one, SWIFT or a stablecoin transfer — USDC, EURC — for a creator abroad who'd rather not wait two days or pay a correspondent fee. The rule and the receipt are the same whichever rail runs.
The agent's books
Here's what an agent that pays has that a budgeting app never will: the reason, at the moment of payment.
When the agent pays the Studio Marr invoice, it records four things on the ledger row as it does so — what (Studio Marr, €1,250), the rule it ran under (new payee, above threshold), who approved it (you, 09:41), and why (your instruction, verbatim). Nothing is inferred afterwards. Nothing is categorized by guessing at a merchant string.
That does three jobs at once. Reconciliation is correct by construction — every payment already matches an invoice or a sheet row. Your accountant gets a statement per agent with the reason on every line. And if a payment is ever disputed, one tap bundles the instruction, the rule, the approval and the receipt into a pack for the merchant or the card scheme.
What still needs you
Honest boundaries. A new payee always waits for you, however small the amount. Anything above the threshold waits. Sending from your other bank accounts — the ones the agent doesn't hold — is coming soon; today the agent pays from its own. And the rules are yours to change, not the agent's: no instruction you give it in the chat can raise its own budget without a confirmation bound to you.