An agent that acts for your company needs two permissions: yours, and the other side's
Agent programs design the permission an employee grants and ignore the one the counterparty must grant. Research and recent news show both sides fail, and in different ways.
Listen to this article · 6 min
AI-generated narration of the full article.
When an employee buys something for the company, two things make the purchase legitimate. The employee has authority: a role, a spending limit, an approved supplier list. And the supplier accepts the employee as someone it will deal with: an account, a contract, a known person to call when something goes wrong.
Agents are being designed with the first half only. Most agent programs spend their governance effort on what the agent may do on the company’s behalf. Almost none ask the second question: will the other side accept an agent, and on what terms? The past week gave evidence that both halves fail, and that they fail in different ways.
The mandate fails on understanding, not bargaining
Anthropic’s Project Swap, published in September, set up a market in which agents traded books for 201 employees, and reran it 205 times with different models and instructions. Each person described their tastes in a short chat, an agent ranked the books from that conversation and then negotiated with other agents. The result fell well short of the best possible assignment, and Anthropic attributed about 85% of the gap to the agent misunderstanding what its person wanted. Only about 15% came from the bargaining itself. Claude’s rankings agreed with people’s own rankings on 61% of book pairs, against 50% for a random guess. Asked how much of a budget they would hand to an agent, participants said about 30%, against about 40% for a well-read friend, and less when the agent’s summary of their tastes had missed something.
Books are not contracts, and Anthropic’s own caveats are long: employees as participants, no adversarial agents, fixed market rules. But the direction of the finding is what matters for enterprise design. The weak link was not the agent’s negotiating skill. It was the mandate, a preference expressed in conversation and interpreted by a model.
Enterprises have a better option than conversation: write the mandate as something a machine can check. GitHub’s new license compliance API, which lets a coding agent ask whether a dependency is allowed before choosing it, is a small example: a rule the agent queries rather than a preference it guesses. The same applies to price ceilings, approved counterparties, contract clauses the agent may never accept and amounts above which a person decides. Authority that lives only in a prompt is authority the agent will reconstruct imperfectly.
Acceptance fails on identity
On the other side of the door, The Verge reported that JPMorgan Chase and Charles Schwab block agents from customer accounts for security reasons, Delta stops agents from booking, and Yelp admits only agents that license its data. We read that as a warning about agents built on browser automation. It is also a statement about acceptance: a counterparty cannot accept what it cannot identify.
An agent arriving with a customer’s password looks exactly like an attacker with stolen credentials. What a counterparty needs before it can say yes is the same thing a supplier needs from a new buyer: who the principal is, what this agent is authorized to do for them, until when, and who answers if the agent exceeds it. Signed, scoped agent credentials such as ServiceNow’s AI Passport are an early form of that, designed for inside the enterprise. Between companies, nothing standard exists yet.
A delegated transaction has two permissions and one record
Your side: the mandate
- Principal and accountable person
- Scope and hard limits
- Expiry and revocation
Machine-checkable, not a prompt
The transaction record
- What was agreed, by which agent
- Which mandate version applied
- Evidence both sides can read
Their side: acceptance
- Identifies the agent and principal
- Verifies the scope presented
- Chooses to deal: API, license or partnership
Granted by the counterparty
A mandate record, before any agent transacts
Our view, and it is a view rather than established practice: any agent that can commit the company to something, a purchase, a booking, a dependency, a contract term, should carry a mandate record with five elements. The principal and the person accountable. The scope, as actions and counterparties. The limits, as numbers and forbidden terms. The expiry and revocation path. And the evidence it leaves: what it agreed, under which version of the mandate. The same record is what a counterparty would need to accept the agent, which is why designing it once serves both sides.
Regulated companies already have the parts. Banks run trading authorities, payment limits, powers of attorney and four-eyes approvals; pharmaceutical companies run delegation of authority matrices for every contract signature. Agents should inherit those structures, not get a parallel, softer set because they arrived through an AI program. We made a related argument that the authority to commit a transaction stays with the system of record; the mandate record is how that authority travels with an agent when it leaves the building.
The legal treatment of agreements made by agents is unsettled and varies by jurisdiction, and nothing here is legal advice. That uncertainty is a reason to keep the record, not to wait. When the first dispute over an agent-made commitment reaches a lawyer, the question will be what the agent was authorized to do and whether the other side could have known. A company that can answer both from one record will be in a far better position than one that has to reconstruct them from a chat log.