Every era of commerce has had to solve the same problem: how do you deal with someone you've never met?
Identity made strangers recognizable. You can check a name, a domain or a certificate, and know who is on the other end. Payment networks made strangers economically interoperable. You can take money from someone you'll never see again, and it will clear. The next step is still open: making delegated authority between strangers verifiable.
That's the question AI agents force. An agent turns up at your service acting for a company you've never dealt with. It's authenticated. Its payment method works. And you still don't know whether the company behind it actually allowed it to do this.
The first answer: yes or no, and a receipt#
Delegus started with the simplest honest answer to that question. Before you act, you check: is this agent allowed to do this, for this company, right now? You get a yes or a no, with the reason, and a signed receipt that proves the decision was made. The company signed the permission. Its agent signed the request. Neither of you had to trust the other's word, or ours, for the rules.
For one agent placing one order at one seller, that's enough. But commerce between strangers is rarely one step.
What a yes or no leaves out#
Watch two companies' machines do a real deal.
The seller's agent quotes a price. The buyer's agent places the order. The seller's agent accepts it, and later commits to deliver. Four steps, two companies, two agents, each acting for someone who isn't in the room.
A single yes or no at the first step doesn't cover that. Three things are missing.
Both sides act on someone's behalf. The buyer's agent needs its company's permission to buy. The seller's agent needs its company's permission to quote that price and to promise delivery. Checking only the buyer is checking half the deal.
One limit per order isn't a budget. A permission that says "up to $500 per order" says nothing about fifty orders of $499. Companies think in budgets: this much this month, this much in total. An agent that stays under the per-order line while running up the total is doing exactly what its permission allows, and still not what its company meant.
Decisions depend on earlier decisions. When the seller's agent promises delivery, the buyer is relying on more than that promise: that the order was accepted by an agent allowed to accept it, and that nothing has been withdrawn since.
What v0.3 adds#
v0.3 is our answer to those three gaps, plus a fourth that runs through all of them: how much a receipt reveals.
Both sides can show their authority#
v0.3 adds the seller's side: quoting a price, accepting an order and committing to fulfil it. Each side's agent carries a permission its own organization signed, and each side's step is checked before it happens. A deal between strangers now has authority on both sides of the table, not just one.
Budgets that add up, spent last#
A permission can now carry a budget across orders: a total, a limit per day, week or month, or a number of uses (money budgets on purchases; quotes and acceptances take a number of uses). The important detail is when the budget is spent: as the very last step, only after every other check has passed. A refused request never uses up budget. And when two requests race for the last of it, only one gets it.
The next party can rely on an earlier decision#
A later action can now declare the earlier decisions it relies on, and the service receiving it can say which ones it requires. There are two ways to declare one, and the difference matters:
- "That decision was made." The earlier decision was genuine, it was a yes, and it belongs to this deal. It says nothing about today.
- "That authority still holds." All of the above, plus the permission behind it hasn't expired or been withdrawn since.
A buyer receiving a promise of delivery would ask for the second. If the seller's company withdrew its agent's permission after the order was accepted, the check fails before the buyer acts on the promise. "Relying" here means something narrow and checkable: the earlier receipt was a declared input to this decision, and it was checked. It isn't a legal promise, and we don't describe it as one.
(Technically, this is the chain of reliance: relies_on, with the modes PRIOR_DECISION and CURRENT_AUTHORITY.)
A receipt that reveals no more than it needs to#
Here's the part that's easy to miss. The more a receipt is passed along a chain of strangers, the more it matters what it gives away.
In v0.2 a receipt carried a copy of the permission it matched. In v0.3 it carries a sealed commitment to it instead. The permission, and the key that opens the commitment, go only to the service that asked. Anyone else holding the receipt learns that a permission matched, and nothing about what it says. Earlier decisions are named by a sealed fingerprint, not an address, so naming one doesn't reveal which decision it is, or let anyone go looking for it.
We wrote three principles into the specification itself, because they decide how the rest is built:
Verifiability does not imply discoverability.
Evidence should reveal no more than is necessary to verify the claim being made.
Receipt authenticity is public. Receipt reasoning is entitled.
Anyone holding a receipt can check it's genuine and unaltered. Working out why it was decided takes material only the parties to it can get.
Knowing the company is real#
None of this helps if the company behind the agent isn't who it claims to be. Going live now takes a company domain the organization has verified, started from a verified email address on that domain, and re-checked every day. Free email accounts stay in the sandbox. If a company is suspended or disputed after a report that its agents were misused, services checking those agents get a signed no that says so, so they can show why they refused.
One deal, end to end#
Here's how that fits together, as an illustration with example companies.
Acme's procurement agent needs 400 GPU-hours. ComputeCo's sales agent quotes $18,400, and Acme checks that ComputeCo's agent may quote that price for ComputeCo. Acme's agent places the order, declaring the quote it relies on; ComputeCo checks that Acme's agent may commit Acme to $18,400, and that the spend fits Acme's monthly budget. ComputeCo's agent accepts the order, and Acme checks that too. Days later ComputeCo's agent commits to deliver, declaring the accepted order, and Acme asks that the authority behind that acceptance still holds. Every step gets a signed receipt. None of them hands either company's permission to anyone who didn't need it.
Two companies that have never dealt with each other, four checked steps, and a trail each side can check for itself afterwards.
Where it stands, honestly#
v0.3 is a release candidate, not frozen. The way earlier decisions are sealed is going through an external cryptographic review, and if the review changes it, a second release candidate follows. v0.2 receipts still verify.
It doesn't do everything:
- Today Delegus accepts only its own permission format. Other ways of writing delegation down are future work.
- Delegus issues every receipt in a deal, so Delegus itself can see how they relate. Sealed fingerprints limit what outsiders can link, not what we can.
- It checks what a company allowed, not why.
What doesn't change: when in doubt, the answer is no. There's one check before the act, a signed receipt for every decision, and a revocation that every later check sees.
Identity made strangers recognizable. Payment networks made strangers economically interoperable. The next step is making delegated authority between strangers verifiable, and v0.3 is how far we've got.