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 extracted from somebody who could not have said no is not a commitment; it is compliance, and compliance has none of the reliability of a promise. 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. 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 decline — that can say the request is unclear, or the deadline is not achievable, or this is outside what I was built to do — is doing something much closer to the real thing, and the design should have somewhere to put that answer. Most designs do not. 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 — the customer has the final say on whether the conversation has ended.

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?

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.