Probabilistic, Steerable, and Holding Our Wallet. What Could Go Wrong?
Intent is not authority: why the agent that transacts for you cannot be an LLM on its own
A lot of the discussion lately about AI agents in commerce focuses on intent. Tell the agent what you want, and it goes and gets it. I understand the appeal. It’s almost seductive, and it sounds so simple. But it’s not accurate. Intent is only the beginning. If an agent is going to spend money on our behalf, intent is not enough, and a large language model on its own is the wrong place to hold it.
This is not a criticism of LLMs. They are remarkable at what they do. It is more a question of which job we are asking them to do.
There is a second problem, and it gets far less attention than it should. An LLM can be steered. It can be steered by what it reads, and it can be steered by whoever owns it. If an agent can be steered in ways the customer cannot see, it should not be the thing that holds the customer’s authority to spend.
Two different jobs
An agent that transacts for a customer has two jobs. The first is understanding: listening to what the customer wants, asking the right follow-up question, and interpreting a request made in ordinary language. That is a language problem, and LLMs are very good at it.
The second job is acting with authority: staying within the limits the customer set, confirming who is on the other side of the transaction, and producing a record of what happened that someone can rely on later. That is a control problem. It has to give the same answer every time, and it has to be accountable.
Too often, these are treated as one job. “The model understands what I want” has quietly become “the model can be trusted to act on it.” Those are not the same thing.
Why an LLM cannot hold the authority
- It can be steered by its owner. Whoever controls the model controls the system prompt, the tuning, and which merchants and offers it puts first. The customer cannot see any of that. Where a platform earns from the merchant side of a transaction, the incentive is built into the business model. This is harder to catch than an attack, because it looks like normal behaviour.
- It can be steered by what it reads. A product page, an email or another agent’s message can redirect it. A spending limit written into a prompt is a suggestion, not a constraint.
- It is probabilistic. The same input can produce a different output. Liability cannot rest on behaviour that will not repeat.
- It does not produce evidence. “The model reasoned that” is not something a bank, a dispute process or a court can work with.
Intent is not a mandate
Intent tells the agent what the customer wants. It does not say how much, with whom, until when, or what should happen if something changes.
Take a simple request: “Book me a flight to Vancouver next week.” It does not say what the customer is willing to spend, which airlines are acceptable, whether the fare must be refundable, or whether the agent may add a seat selection or travel insurance. An LLM will fill those gaps in. It will do it plausibly, and it may do it differently each time.
A mandate is different. It has a scope, limits and an expiry. The customer signs it, and code can check it at the moment of commitment. Intent is what the customer wants. The mandate is what the agent is allowed to do.
What belongs in code
Three things should never be left to a model’s judgment:
The rule is simple:
The model proposes. The code commits.
Code has an owner too
To be fair, code is not neutral just because it is code. It can also be written to favour someone. What changes the picture is that code is deterministic and inspectable. It can be tested and audited. If the mandate belongs to the customer and is signed by the customer, the agent’s owner cannot quietly widen it. If the receipt records what was checked and why, any steering leaves a trace.
The rest depends on who owns the code. An agent that transacts for a customer should owe that customer a duty of loyalty, built into its structure and its contracts. Code makes loyalty enforceable. A duty makes the owner answerable for it.
Where the industry is heading
Much of the serious work in the industry is already moving in this direction. Signed mandates are part of Google’s Agent Payments Protocol, and the card networks are adding agent verification and tokenization to their agent programs. That is real progress.
Most of it, though, is built to protect the network and the merchant. The open question is on the customer’s side. Who enforces the customer’s mandate? Who checks the counterparty on the customer’s behalf? Who gives the customer a receipt they can rely on if something goes wrong? That is the work we are doing at Twinvocate.
Twinvocate is at the prototype stage, and nothing in it is left to a model. The mandate and the receipt are built in code, and so is the counterparty check, which runs as a separate engine that we will connect to the agent. No live payments or real customer data run through it. A proof of concept is the next step. If we add a model later to help listen and propose, it will never be the part that commits.
The short version
Most of the conversation so far has been about the first of these. The other three are where trust and liability are decided.
Let the LLM listen. Let code decide.