Sui's Oct. 28 Agent Note Nails It: Cap the Wallet, Don't Coach the Bot

I've run a Lightning node since 2020. The lesson I keep relearning is that policy does the heavy lifting, not intelligence. Set a max HTLC size on a channel and the node physically can't route something bigger. No judgment call. No vibes. That's the whole trick.

So an October 28 design note from the Sui Foundation, about giving software agents authority without losing control, hit close to home. The argument is simple. Boundaries should live inside the systems an agent touches, not in a prompt the agent is expected to remember.

Which is obvious if you've ever babysat a routing table. And apparently not obvious to the hundreds of teams wiring language models into wallets right now.

An instruction isn't a limit

Here's the distinction that matters, and it's the cleanest part of the whole discussion. Telling software "don't spend more than 500,000 sats" is an instruction. Handing it a credential that can't sign a transaction above 500,000 sats is a permission. The first collapses the moment a model misreads a number or gets nudged by a poisoned merchant page. The second just returns an error.

You want both, honestly. A sane objective and a mechanism that refuses at execution time. But only one of them survives contact with adversarial input.

So why does anyone still treat a well-written system prompt as a security layer? Ask the team that paid a fake invoice how much the prompt helped.

On Lightning, this is baked in at three levels. Macaroons in LND let you bake a credential with custom caveats, scoped so a service can create invoices but never touch channel funds. Channel policy caps HTLC size and count. BOLT 12 offers carry expiry and quantity constraints, and the paying node can still refuse. Nobody calls those guardrails because they aren't. They're the rails.

Lightning isn't coming. It's here. It's been doing delegated authority for years without calling it agentic.

Atomicity isn't correctness

Now the Sui piece I find genuinely useful. Programmable transaction blocks group commands so they commit together or not at all. A purchase and the later move of the acquired asset become one composed operation. If a step fails, you don't end up in that ugly half-state where sats left and the asset never showed.

That's the settlement story. My node routes a payment in about 800 milliseconds, and I've watched it do that tens of thousands of times. Try that with Visa's settlement layer. It's not close.

But atomicity isn't free, and it isn't the same as being right. Failed groups still cost you in fees, so a sloppy agent loop quietly turns into a fee generator. And atomic execution says nothing about whether the price was sane, the counterparty was legit, or the goods exist. It's a card that can't be double-swiped. It's not a card that knows the merchant is a scam.

What's actually on the table, then, is enforced transaction rules plus inspectable records. Two pieces of a bigger machine. The rest is offchain reality, and offchain reality is where payments really break.

Which brings up reconciliation, the least sexy topic in this entire space and the one that decides whether merchants stay. If three businesses touch one workflow through agents, somebody has to answer: which action was authorized, which transaction executed, and who signed off. A shared log answers that cheaply. In my experience reconciliation labor eats more merchant margin than fees ever do. A shop pushing 10,000 invoices a month doesn't lose sleep over a few thousand sats in routing fees. It loses sleep over a bookkeeper burning three days matching them up by hand.

The delegation question is the one I'd watch hardest. If an agent subcontracts part of a task, does the next participant inherit the original budget, purpose, expiry, and counterparty list? Or does scope quietly widen? Sui's note frames this as a design principle rather than a shipped feature, and I respect the honesty. Developers still have to implement it, and mistakes there are expensive.

Who wins here

The winners won't be the chains. They'll be the wallet and policy layers that ship budget caps, purpose tags, expiries, and allowlists as defaults instead of enterprise upsells. If ten lines of configuration can stop a runaway agent, the company selling those ten lines wins. Merchant adoption follows whoever makes that boring.

The losers are the demo-ware crowd. Anyone flogging a "fully autonomous agent" with one master key and a paragraph that says please be careful. And the consultants charging six figures to write instructions a policy engine would enforce for nothing.

Look, I care about routing fees more than price charts because routing fees tell you whether anyone's actually using this stuff. The same logic applies here. Count the transactions that got blocked by a real limit. That number is your safety metric. A workflow that's never been refused probably isn't constrained at all.

What should you do this week? Three things. Put the budget in the credential, not in the instructions. Set an expiry, because authority should rot. And log everything, because when a dispute lands, the record is the argument.

Then widen scope only when the controls and the evidence earn it. Narrow first, wide later. That's not a crypto rule. It's an operating rule, and it's the same one that keeps a Lightning node solvent while you sleep.

Every channel opened is a vote for peer-to-peer money. Every hard spending cap is a vote for letting software touch money without burning the house down. Payments, not speculation. That's the point.