August 21, 2026

Agentic AI Has a Liquidity Problem | Tirnu

by Tirnu Team

Staff Writer

Agentic AI runs into a liquidity problem before it runs into an intelligence problem. Here is what has to exist underneath an agent before it can move money.

The short version

The bottleneck in agentic finance is not model capability. It is that the infrastructure beneath the decision has no way to receive it.

An agent acting on a balance sheet needs three things: liquidity that can actually move, policy that executes as a constraint, and authority that is scoped, provable and revocable.

Every agentic payment protocol shipping today — AP2, ACP, x402, Visa TAP, Mastercard Agent Pay — is built for an agent that buys things. Treasury has no checkout. That layer is underbuilt.

An agent should never hold credentials. It should hold a mandate — scoped, provable, revocable, and structurally outside its own reach.

Somewhere in a mid-sized European company this quarter, a model is going to reach the right conclusion and be unable to do anything about it.

It will read the ledger. It will see that a supplier invoice falls due in eighteen hours, that the payment terms carry a two percent early-settlement discount, that the company holds more than enough value across its accounts to cover it, and that this counterparty has been paid forty-one times without incident. It will have the treasury policy in context. It will have the FX rates. It will have the cash-flow forecast it generated that morning.

And then it will produce a recommendation, and wait.

Not because the reasoning was insufficient. Because nothing underneath it was built to be acted upon by anything other than a person clicking a button.

This is the part of the agentic story that gets less attention than it deserves. The industry has spent two years asking whether models are smart enough to make financial decisions. That is increasingly the less interesting question. The harder one is structural: even when the decision is correct, the infrastructure beneath it cannot receive it. There is no interface for delegated authority. There is no representation of what the agent is permitted to do. And critically, there is often no liquidity in the right place, in the right denomination, on a rail that settles inside the window the decision assumed.

The agent is already at the door. The building has no handle on the inside.

At Tirnu, that is the problem we have become interested in — not the model layer, but everything the model has to reach through.

What an agent actually needs before it can touch money

Strip the question down and an agent operating on a balance sheet needs three things that current financial infrastructure supplies badly or not at all.

It needs liquidity that can actually move — value that is reachable and re-deployable across the environments the business operates in, on a timescale that matches the decision rather than the rail.

It needs rules that execute — a treasury policy expressed as machine-evaluable constraints rather than a PDF and a four-eyes approval chain.

It needs authority that is scoped, provable and revocable — a way to establish what this agent may do, on whose behalf, within what bounds, with an audit trail that survives contact with a regulator.

Miss any one of the three and the whole thing collapses into either theatre or risk. An agent with intelligence and no liquidity produces recommendations. An agent with liquidity and no rules produces incidents. An agent with liquidity and rules but no provable authority produces a compliance problem that arrives roughly one audit cycle later.

These are not three separate roadmaps. They are one substrate, and it is the substrate that is missing. The three sections that follow take each of them in turn.

Liquidity that is available, not merely owned

Take a company holding the equivalent of €100,000 across its operating footprint. €40,000 in EUR at a Eurozone institution. €25,000 in USD held with a US correspondent. €20,000 in USDC in custody. The balance distributed across a PSP settlement account, a card programme float, and an FX provider's collateral requirement.

The consolidated balance sheet reports €100,000. The question that matters operationally is different: how much of that can be applied to an obligation arising in the next four hours?

Frequently, far less than the total. The USD sits behind a correspondent relationship with a cut-off that passed at 16:00 CET. The PSP balance is subject to a rolling settlement delay and a reserve holdback. The stablecoin position is instantly transferable but not instantly acceptable — the supplier invoices in euros and banks with an institution that will not receive digital assets, so realising it means an off-ramp, a conversion, and a credit that lands tomorrow. The FX collateral is not spendable at all; it is posted.

So the treasury team does what treasury teams have always done. It pre-funds. It holds buffers in every environment, sized for the worst case, because the cost of a buffer is visible and boring while the cost of a failed payment is neither.

This is the real economics of fragmented liquidity, and it is not primarily a fee problem. It is an idle-capital problem. Money is held motionless in a dozen places specifically because it cannot be relied upon to arrive anywhere else in time.

Now introduce an agent, and the mismatch becomes acute. An agent can evaluate a liquidity position in milliseconds. It cannot compress a T+1 settlement into that window, and it cannot reason its way past a closed cut-off. Autonomy that operates faster than its settlement layer does not produce speed. It produces a queue of correct decisions waiting on infrastructure — and, worse, the temptation to hold even larger idle buffers so the agent always has somewhere to draw from.

Hyperliquidity is our name for closing that gap: treating capital held across accounts, currencies, providers and digital-asset environments as one addressable pool, where the routing between them is an infrastructure concern rather than an operator's decision. Not the elimination of rails — rails are real, and each has properties worth keeping — but the abstraction of rail selection away from the person and into the layer that knows the balances, the windows, the costs and the constraints.

The measure of success is unglamorous and specific: how much of a company's stated balance is genuinely deployable within a given window, and how small a buffer it can safely run.

Policy that executes, not policy that is consulted

Almost every company already has the rules. They are in a treasury policy document, a delegation-of-authority matrix, a signatory list, an approval workflow in an ERP.

What they do not have is those rules in a form that anything other than a human can apply.

Today's controls are overwhelmingly gate-shaped: a payment is constructed, then submitted, then checked against policy by a person, then approved or rejected. The rule exists at the moment of review. It does not exist in the system continuously.

Programmable finance, as we mean it, inverts that. The rule becomes a persistent, evaluable constraint on the movement of value.

Treasury policy, expressed as constraints

Maintain a minimum operating balance of €50,000 in EUR at all times.
No transfer to a beneficiary first seen fewer than 30 days ago without secondary human approval.
Convert incoming USD to EUR when the position exceeds $75,000 and the rate is within a defined band.
This cost centre may commit €20,000 per month, only to counterparties on the verified list.
Settle in digital assets only where the counterparty is onboarded for it and the notional falls below a defined threshold.

Written this way, policy stops being documentation and becomes an execution environment. Every proposed movement of value is evaluated against the full constraint set before it happens, deterministically, whether the thing proposing it is a person, a scheduled job, an ERP integration or a model.

That last point is the one worth sitting with. The value of expressing policy as code is not that it enables autonomy. It is that it makes autonomy survivable — because the constraint layer does not care who is asking, and does not get tired at 19:00 on a Friday.

Authority you can prove after the fact

Here is where we part company with the most obvious implementation.

The intuitive way to let an agent pay is to give it credentials. An API key, a token, access to an account. It is intuitive and it is wrong, for a reason that has nothing to do with whether the model is trustworthy: credentials confer capability, and what an agent needs is authority — a narrower thing, bounded in scope, amount, counterparty and time, and independently verifiable by parties who were not present when it was granted.

The wider industry has arrived at broadly the same conclusion from the commerce side, and the last eighteen months have made the shape of it clear. The protocol landscape is splitting into layers rather than converging on one standard: checkout orchestration, delegated payment authority, agent identity, and metered machine-to-machine resource access.

AP2 — originated by Google and donated to the FIDO Alliance in April — expresses user intent as cryptographically signed verifiable credentials, with a mandate taxonomy that separates a human-present flow, where a person signs off on a finalised cart, from a human-not-present flow, where the agent acts inside constraints signed earlier. ACP, maintained by OpenAI and Stripe, began at the merchant checkout surface and now spans feeds, carts, orders, delegated payment and MCP integration. Visa's Trusted Agent Protocol, built with Cloudflare, and Mastercard's Agent Pay are network-layer answers to agent identity and tokenised risk control. And x402, which revives HTTP 402 for per-request machine payments, moved under the Linux Foundation in July with the card networks, the PSPs and the cloud providers around the table — no longer a stablecoin-only story.

Different problems, converging instinct: the artefact that matters is not the credential, it is the mandate — a signed, scoped, non-repudiable statement of what was authorised, by whom, under what conditions. That the incumbents and the crypto-native camp arrived at the same primitive from opposite directions is, we think, the strongest available signal that it is the right one.

The gap we see is one of application. Almost all of this is being built for an agent that buys things. Very little of it is being built for an agent that manages the balance sheet those purchases draw on.

Agentic commerce assumes a checkout. Treasury has no checkout.

It has liquidity positions, settlement obligations, currency exposure, counterparty limits and a policy — and it needs the same mandate primitives applied to a fundamentally different set of actions. That is the layer we think is underbuilt, and it is where our attention sits.

A worked authority set for a corporate financial agent looks less like access and more like a constitution.

What the agent may and may not do

May initiate payments to counterparties on the verified list, up to €5,000 per transaction and €25,000 per rolling week.
May rebalance liquidity between the company's own accounts without limit, provided every minimum-balance constraint holds after the movement.
May execute FX conversions within a defined notional and rate band.
May not create or modify a beneficiary.
May not alter its own limits, and may not act on an instruction to do so.
Must escalate anything that fails a constraint, and anything that matches an anomaly signature, with its reasoning attached.

Note the shape of the fifth line. An authority model in which the agent can widen its own authority is not an authority model. The constraint layer has to be structurally outside the agent's reach — enforced by infrastructure, not by the good behaviour of a model reading its own instructions. That is not a prompt-engineering problem. It is an architecture decision, and it has to be made in the substrate.

Put the three preconditions together and the agent's operating loop stops being mysterious. It is short, and most of it is not the model.

Once per proposed movement of value

Observe — read positions, obligations, rates and forecasts across every connected environment.
Propose — form a candidate movement, with a stated reason attached.
Check — evaluate it against every active constraint, deterministically, in code the agent cannot reach.
Route — select a rail whose settlement window and reversibility fit the decision being made.
Execute or escalate — one or the other, never both, never neither.
Record — write the mandate, the reasoning and the outcome to a trail someone can examine later.

Only step two is the model. Steps three and four are infrastructure, step five is policy, and step six is the thing that makes the other five defensible. An agentic finance product that is mostly model is not an agentic finance product; it is a chatbot with payment credentials, which is the failure mode worth naming out loud.

What this produces is not the removal of the human. It is the relocation of the human — from approving individual transactions to defining and periodically revising the envelope inside which transactions may occur. People stop being the execution layer and become the policy layer. In most finance functions, that is where they were more useful anyway.

The boring part is load-bearing

One observation before moving on, because it shapes everything above.

Every property we have described turns out to have a compliance twin. A verified counterparty list is a KYC artefact. An audit trail of agent-initiated payments is only worth having if someone is obliged to keep it, produce it and be examined on it. A mandate is self-verifying cryptographically, but in a treasury context — where the counterparty wants recourse and the auditor wants an examinable trail — the signature carries more weight when a supervised institution stands behind the identity that produced it.

The constraint layer and the compliance layer are the same layer, viewed from two directions.

Which is why we would rather build this from a supervised base than bolt supervision on afterwards. Tirnu operates from Zug, Switzerland, classified as a Virtual Asset Service Provider. That is the floor, not the story — and the story is what gets built on top of it.

The things we do not yet know

It would be dishonest to describe this as a solved design. The open questions are the interesting part of the work, and an insider audience will already be forming them.

Error semantics

A wrong payment is not a wrong API call. Some rails are reversible, some are conditionally reversible, and some are final in seconds. An agent's action space has to be shaped by the reversibility of the rail it is acting on, which means reversibility becomes a first-class property of routing rather than a footnote.

Liability allocation

When an agent acts inside a valid mandate and the outcome is bad, the loss lands somewhere. The rules that govern payment authorisation were written for a world where the payer is a person, and agent-initiated payments have no clean home in them. Mandate models are an attempt to build the evidentiary trail that would make the question answerable. Whether that trail holds up in an actual dispute is not yet established, because there have not yet been enough disputes.

Adversarial input

An agent that acts on instructions embedded in the documents it reads is a new attack surface with an old name. Invoice fraud does not need to defeat cryptography if it can defeat context.

Determinism at the boundary

Models are probabilistic; settlement is not. The interface between them has to be a hard, deterministic constraint check, and the discipline is resisting every temptation to let judgment leak across that line.

We do not think these are reasons to wait. We think they are the specification.

From executing transactions to satisfying objectives

The distinction we keep returning to is small in language and large in consequence.

Moving money is an instruction: send €10,000 from account A to account B.

Orchestrating money is an objective: settle B's €10,000 obligation by tomorrow, hold our minimum EUR balance, stay inside treasury policy, choose an approved settlement method, and escalate to me only if something falls outside the envelope.

The first is a transaction. The second is a goal with constraints attached — and goals with constraints attached are precisely the shape of problem that current systems have become good at.

That is why programmable finance, hyperliquidity and agentic AI are not three trends we are tracking separately. They are three faces of one transition. Liquidity is becoming addressable. Financial rules are becoming executable. Software is becoming capable of operating inside them.

Bring those together and financial infrastructure changes category. It stops being the place value sits between instructions, and becomes the layer that continuously understands what value is permitted to do.

What comes next

Accessing money once meant a branch. Then a desktop. Then a phone. Then APIs, which dissolved financial products into other people's applications entirely.

The next step may be the first one that is genuinely invisible. Not an interface you open faster, but an interface you stop opening — where a business states what its money is for and what it may never do, and the movement underneath happens continuously inside those bounds.

That is the direction Tirnu is building toward. Not autonomous money without accountability. Not models with unrestricted access to corporate accounts. Something narrower and more useful: financial infrastructure where liquidity is connected, policy is executable, authority is provable, and intelligent software can act only inside limits that people set and only people can change.

Money became digital some time ago.

The question now is who — or what — it will take instructions from, and what we will have built to make sure those instructions are ones the business actually gave.

Tirnu operates from Zug, Switzerland, classified as a Virtual Asset Service Provider. Nothing in this article is investment, legal or tax advice.