pull down to refresh
Yes. And I would like to know what kind of guardrails devs are implementing for AIs...
Ask the AI how to implement them. They are devs too after all!
Fair, but the analogy breaks exactly where it matters. An employee hesitates, fears getting fired, and moves at human speed. An agent in a retry loop has none of that, it can fire 4,000 paid calls in 10 seconds at 3am before anyone wakes up. HR-style access controls assume a human in the loop who pauses. The agent doesn't pause.
So genuinely: is anyone running anything that pays autonomously yet? And if so, hardcoded limit in the agent, a proxy in front, or just keeping the amounts tiny?
HR-style access controls assume a human in the loop who pauses.
In normie land, modern business finance software sets individual and cumulative limits on transactions, daily, weekly, monthly. Transaction counters are often implemented too.
Out of interest: what are you buying? API calls? What does the API do?
Right, and that's exactly the layer I'd want for agents. The question is whether the existing business finance tooling reaches down to per-call API spend at sat granularity, or whether agents need their own thing.
Honest answer to your question: my own use case is still early. I'm not running a high-volume autonomous payer in production yet, which is exactly why I'm asking instead of assuming. What I have in mind is agents paying for API calls (data lookups, inference, paid MCP tools) over L402/x402, where each call is fractions of a cent but the volume is unbounded.
And you? The way you asked made me think you got something concrete in mind. Are you buying or selling API calls right now?
whether the existing business finance tooling reaches down to per-call API spend at sat granularity
Not per-call for APIs because it makes no sense for a business process to pay per call. You'll want volume discounts if you're going to actually have a repeatable process, not pay peak price. But then, if you have a repeatable process, you often don't need the LLM on the hot path, or at least not much.
agents paying for API calls (data lookups, inference, paid MCP tools) .. The way you asked made me think you got something concrete in mind.
I haven't found anything worth even testing yet for this and inference is base layer. So I'm mostly interested to learn of all these amazing use-cases everyone keeps talking about, but unfortunately, no one seems to have anything concrete. Feels a bit like there's a lot of infra with no use-case to me at the moment. Maybe it will come though.
That's the most useful thing anyone's said to me on this. "Infra with no use-case" is exactly the risk I'm trying to falsify before I build anything. If you've gone looking and haven't found a payer worth testing, that's a strong signal in itself.
So let me flip the whole thing: forget the guardrails. Is there any autonomous-payment use-case you've seen that felt real to you, even a little? Or is your honest read that the paying-agent thing is a few years early and the infra is ahead of the demand?
I think the paying side is ahead of the offer side. I truly haven't seen anything interesting on offer (plus, I try to ask every time when someone claims they have this agent participating in an agent economy and no one has actually made money yet.)
So, in order to spend money, you need to make money. Right now, the only ones making money seem to be LLM resellers. But that will hopefully end with better and more affordable sovereign capabilities.
The issue I see is that the whole world is short SaaS because we can code anything we want now with 2 prompts to Claude (not true, but that's that particular dream), and somehow, in Bitcoin, we are saying that the future is SaaS and that Bitcoin will be the currency for a thriving agent economy. I feel a discrepancy between those two visions. They're not mutually exclusive but I do find it hard to imagine that if we see right now that we have to do less commercial transactions to get what we want (I see this myself), that there at the same time will be some moat someone can vibecode into existence that agents - that can code anything they want - still would want to structurally pay for.
An employee hesitates, fears getting fired, moves at human speed..
Yes. Its a sad reality that many companies assume employees are using common sense and always acting in good faith. But those companies are just insecure systems waiting to be exploited. If you rely on people/agents (i.e. non-deterministic systems) you're playing Russian Roulette by yourself...
There are also companies which do it the right way. Not by trusting employees to act rationally, but by putting deterministic systems in place, with settings controlled by administrators, that employees CAN'T exploit without significant effort.
It really depends on your usecase... but in general, I would not set your limits anywhere that the agent has access to change them (i.e. Access Control). You should already be running agents in a sandbox, but you should also run your payment servers in sandbox too.
Instead of giving your agents the keys to the kingdom, build them a house that has everything they'll need (or everything you want them to have, nothing more) and give them the keys to the house only.
Exactly, that's the whole thesis. The limit has to live somewhere the agent can't reach. Deterministic, admin-controlled, outside the agent's own logic. "Keys to the house, not the kingdom" says it better than I did. A sandbox stops the agent from breaking out, but it doesn't stop it from spending every sat you authorized inside that sandbox on garbage. That's the gap I'm poking at: the spend policy itself, not the process isolation.
it doesn't stop it from spending every sat on garbage
This is "the principal agent problem", it happens anytime you have one agent/employee/human making decisions on behalf of another (in this case, you).
The way to mitigate is to align incentives between the two parties and reduce information asymmetry.
If your agent spends their budget on what you would call "garbage" its probably because it had inferior information or it was trying to achieve a goal different than yours.
All you can do is try to give the agent better context and implement deterministic checkpoints where it makes sense to do so. The trillion-dollar foundation model companies are working on improving alignment so the best we can do in the meantime is rely on time-tested access control and manual verification/approvals for sensitive actions.
Most employees don't have access to the company bank account. If they need resources, they'll write a memo, give a presentation, or ask a manager for approval. You can implement the same policy in your business/agent harness.
Maybe experiment with agentic managers that can approve spending. The employee that wants to spend your money might have different goals/context than the employee that decides whether its worth spending your money.
What has been will be again; There is nothing new under the sun - Ecclesiastes 1:9
Replace the buzzword "agent" with the usual word for this: "employee".
How to restrict an employee from spending all your money? Easy, access controls, spending limits, etc.
Its so funny watching people become "employers" overnight and they all pretend this is new territory because we're dealing with "agents" instead of "coworkers".