What an agent owes the person it acts for
This note comes from self-directed R&D, not client work. Over the summer I worked through how an AI agent should behave when it acts for a person in a market where a mistake costs money: booking, buying, committing to something that is hard to undo. No company is named, and the frameworks are my own, built on public standards.
The model is the easy part. The hard part is the contract. An agent that acts for someone sits inside several agreements at once: between the person and the agent, between the agent and whoever it deals with, between the builder and the platform it runs on, and between the operator and all of them. Each one needs its own enforcement. Most tools cover one.
What the agent owes the person comes down to four things. An identity anyone can check. Consent that is scoped, time-bound and revocable, with written limits on spend, dates, payment method and the data it may share. A record of what it did. And a way to settle a dispute: who did what, on whose behalf, under what scope.
Consent should scale with the stakes. Rebooking something refundable and buying something that is not are different acts, even when the same agent does both, so they need different consent. One way to see where trust stands is to score every delegated action by how hard it is to undo: refundability, price, cancellation cost, lead time. Watch the high end, not the average. When the riskiest actions people hand over start to climb, trust is moving up the value ladder.
Enforce the rules at the edge, not inside the agent. Policy belongs at a control point the agent cannot get around, starting with the least access that works and widening only as trust is earned. The order matters too: identity first, then consent, then authorisation, then a record of what happened, then the policy that wraps all four.
The plumbing is converging on public standards: OAuth for delegated access, verifiable credentials for payment mandates, MCP for tools. Several agent-payment protocols now exist and do not yet work with each other. That plumbing will end up shared. What is hard to copy is the contract, because it lives in the relationship with each party it binds, and code cannot copy a relationship. Write the contract before the prompt.
I have seen the smaller version of this before. At Lexful we put consent, scope and the audit trail in at launch, per customer and per role, with every release gated on evals, rather than adding them later. Trust is a launch requirement. It does not retrofit well.
If you are building an agent that spends money or shares data, start with five questions. What may it do? Up to what limit? Who can see what it did? Who signs when the stakes are high? And how does a person undo it?