Only a person can promise
The question everybody is asking about AI agents is what they can do. It is the less interesting question, because the answer keeps changing and the direction is obvious. The question that decides how work gets arranged is a different one: what can an agent be — and specifically, can it be a party to an agreement?
Not can it produce the sentence. It can produce the sentence. Can it be held to it.
The doing and the promising are different jobs
Coordination has two halves, and they are easy to confuse because the same person usually does both. There is the work — the slab poured, the report written, the code shipped. And there is everything said around it: the asking, the answering, the reporting, the accepting. The first half is where the effort is. The second half is where the accountability is.
Automation has always eaten the first half. That is what it is for, it is usually right, and there is nothing to mourn in it. What is new is the speed: a machine that can do the doing at a thousand times the rate turns the second half into the constraint. The volume of work goes up. The volume of promising does not, because promising is not a throughput problem.
So the part that was always load-bearing and rarely looked at becomes the part everything rests on.
What makes a promise a promise
A promise is not a sentence with certain words in it. If it were, this would be a solved problem — models are very good at sentences.
What makes it a promise is that somebody is now on the hook, and that they were in a position not to be. Both halves matter and the second one is the one that gets skipped. An agreement that could not have been withheld carries no information, because it would have been given either way — which is the difference between compliance and a promise, and why one can be relied on and the other cannot. That is true of a person in a job where declining is career-limiting, and it is true of a model whose configuration does not contain a refusal.
This is worth being exact about, because it cuts both ways.
Ask one agent to reconcile last month's invoices and it returns a reconciliation. Ask another and it returns: three of these are against a supplier I have no record of, and I have not guessed — who should I ask? The second one has declined, and declining is what makes the first reply worth anything: if it could only ever hand something back, the something it handed back tells you nothing about whether it could be done.
An agent that cannot decline is not a performer in the sense the notation means. It is a mechanism, and it should be drawn as one. An agent that can is doing something much closer to the real thing, and the design needs somewhere to put that answer. Most designs have nowhere. They have a retry.
Who accepts
Then there is the closing, which is where the argument bites hardest.
A conversation for action is finished when the person who asked says it was what they wanted. Not when the performer reports it done. Those are two acts, held by two parties, and the whole structure depends on them being different people. Only the one who asked can close it, and nobody can close it on their behalf.
Give an agent both and you have built a system that performs and judges its own performance. That is precisely the arrangement the loop exists to prevent, and it is the default arrangement in almost every agentic system being built right now, because it is what happens when nobody asks the question. The agent does the work, marks it complete, and the completion flows onward as a fact. There is no moment where anybody could have said no, that is not it.
The alternative is not that a person inspects everything, which does not scale and nobody wants. It is that the acceptance moments are drawn, and that a person's name is on the ones that matter. Some can be delegated. Some cannot, and the difference is a design decision somebody should be making on purpose rather than discovering afterwards.
This is not the first time
None of this is a new observation, which is the reassuring part.
When software components only called each other, request-and-reply was enough and a vocabulary of promises would have been decoration. That stopped being true the first time with multi-agent systems: FIPA's agent communication language, and KQML before it, took their message types straight from speech act theory — request, inform, agree, refuse, propose. Not an aesthetic choice. Once a component can decline, the protocol needs somewhere to put the declining, and a status field does not have one.
The vocabulary those protocols reached for is the one Austin and Searle worked out, and that Fernando Flores and Terry Winograd brought into the design of software in the 1980s. It was built for exactly this: describing what people are doing when they speak to each other, in a way precise enough to build on. It is the only account we have that treats a request and a report as different kinds of thing rather than as two messages.
What is actually left to people
The answers usually given are creativity and judgement, and they are not wrong so much as unfalsifiable. Here is a narrower one, and it holds up.
What is left to people is being the party. Wanting something in the first place, which is where every loop starts and is not a task anybody delegates. Being free to refuse and refusing when it is right. Being the one who says yes, that was it — or no, it was not, which is the more valuable of the two and the one no automated acceptance will ever produce.
And underneath all of them: being answerable. A machine can be wrong. It cannot be disappointed, and it cannot be the one who let somebody down. Accountability is not a feature that has failed to ship yet; it is a relation between people, and there is no version of it that runs on a schedule.
That is not a small residue. It is the part that holds a business together, and it is about to be carrying a great deal more weight than it did when people were also doing all the work.
What to do about it
Draw the coordination you are building, before the agents are in it and while it is still cheap to change.
Three questions do most of the work. For every step an agent performs: who asked it, in words, and would that request be clear to a person? For every step it completes: whose acceptance closes it, and if the answer is nobody's, is that deliberate? And for every step where it could fail or push back: where does the refusal go — is there a path drawn for it, or only a retry?
One more thing worth trying, since the argument is about what a model can be handed rather than what it can do. The editor will write a network out as a prompt — the notation first, so it knows a report is not an acceptance and that only the customer closes a loop, then the map itself, then an instruction to walk it one moment at a time and stop. Paste that into whichever assistant you use and it plays the other people while you take a part, or watch.
It is the argument of this page in miniature. The model is not being asked to know who owes what; it is being given an account of who owes what, and the account is the thing it does not otherwise have. Nothing is sent from the editor — the prompt is written in your browser and shown to you before you decide to paste it anywhere.
What it does to software has the same argument from the schema's side, including what a commitment-shaped record carries that a status column does not. Language is how commitments get made has where the vocabulary comes from, and the objection to it worth taking seriously.