Mercury vs Relay: Banking for an AI Automation Agency

Say a client pays $18,000 to build an automated intake and routing workflow, then $2,500 a month once it's live to keep it running, monitored and tuned. Your own underlying model API costs for that client might run a few hundred dollars one month and spike the next if their usage grows. Relay's free multi-account structure handles this cleanly: route the implementation fee into a project account that funds the build, route the retainer into an operating account, and keep a dedicated buffer account sized to your highest realistic monthly compute bill so a usage spike never eats into payroll. Mercury can mirror that structure with its own multiple accounts, and its API lets an agency with any kind of usage-based billing pull real-time balances to check compute spend against revenue without waiting for a monthly statement.

Agencies that land a handful of large implementation fees in the same quarter often end up holding more idle cash than a purely retainer-based business would, at least until that cash gets spent on the next build cycle. The effective federal funds rate sits at 3.63%¹ right now, which is the rough floor for what a short duration Treasury instrument should pay, well above what a standard checking balance earns sitting still. Mercury's Treasury sweep automates capturing that gap on the cash sitting between an implementation fee landing and the payroll or compute bill it's ultimately funding. Relay's savings sub-accounts pay a published rate too, but the sweep into government money market funds specifically is a Mercury feature.

A retainer priced to be comfortably profitable at typical usage can turn thin fast if a client's workflow volume grows and your underlying compute cost scales with it. This is less a banking question than a discipline question, but the account structure you choose either makes it visible or hides it. A dedicated sub-account per client, funded from that client's retainer and drawn down by that client's compute spend, shows you in real time which retainers are still healthy and which ones need a pricing conversation before the next renewal. Treat this the way a SaaS company treats its burn multiple, keeping the ratio of what you spend on a client's compute against what that client pays you under a clear ceiling², rather than discovering the imbalance at tax time.

An agency scaling headcount ahead of signed retainers sometimes needs a credit line to bridge the gap, and that credit is priced off the bank prime rate, currently 6.75%³. Before drawing on a line, run the math on whether the implementation pipeline you're hiring against is signed or just probable, since a rate environment like this one makes carrying debt against a maybe considerably more expensive than it was a few years ago.

Agencies staffed heavily with engineers tend to gravitate toward Mercury simply because someone on the team is comfortable pulling balances and transactions through an API and wiring that into an internal dashboard next to usage and margin data. Agencies that outsource bookkeeping to a part-time contractor or a firm tend to prefer Relay, since its native QuickBooks Online and Xero integrations, plus role-based access for an outside bookkeeper, get the books current without anyone touching code. Both are legitimate answers; the deciding factor is usually whether finance operations already lives inside the product team or sits with a separate, non-technical function.

The banking setup only helps if the retainer itself is priced with enough room to absorb normal usage variation. A common mistake is pricing a retainer against a client's launch-week usage, which is almost always lower than usage six months in once the workflow is fully adopted across their team. Build a buffer into the retainer price for realistic usage growth, not just current usage, and revisit pricing at each renewal using the actual compute cost history your sub-account structure has been quietly collecting for you. An agency that treats retainer pricing as a one-time decision made at signing, rather than something to revisit against real usage data, is the one most likely to discover a client relationship has been unprofitable for months once someone finally reconciles the compute bill against what that client actually paid.

Check these points before you set a retainer price:

• Estimate usage six months in, once the workflow is adopted across the client's team, because launch-week usage is almost always lower.
• Build room into the price for realistic usage growth, not just the volume you see today.
• Fund a dedicated sub-account per client from its retainer and draw compute costs from it, so margin erosion shows up early.
• Size the compute buffer to your highest realistic monthly bill across current clients, and revisit it every quarter.