Commitments, Not Colleagues

The popular picture of the agent-native company is a staff directory. Each agent has a name, a title, and a responsibility. One owns marketing, another owns support, a third owns research. You configure them, place them beside your human team, and watch a small org chart of software colleagues fill in.

It is a comfortable picture because it matches how we already think about work. It is also the wrong unit.

A colleague can be busy while the work fails. An agent can run all night, produce plausible output, and still miss the renewal that was due, skip the claim that needed a human, or fall short of the standard the result had to meet. When you manage a roster of colleagues, you are managing entities. What a company actually owes the world is something else: a set of promises it has to keep, over and over, whether or not any particular worker is available to keep them.

A company is a system of commitments

A company is better understood as a system of commitments. A commitment is a recurring promise with an owner, a standard, and a record. Renew every contract before it lapses. Answer every support request within a day. Never send an untrue claim to a customer. Close the books each month against the same checklist. The promise is the durable thing. Who performs it is a detail that can change.

This is an old idea about firms, newly useful. Ronald Coase asked why firms exist at all and answered that they exist to coordinate work that would cost too much to coordinate through the open market. Michael Jensen and William Meckling later described the firm itself as a nexus of contracts, a meeting point for a set of contracting relationships among people, capital, and suppliers rather than a thing with a will of its own. Strip "contract" back to its plainer meaning and the firm becomes a nexus of commitments: the promises it has agreed to keep, and the arrangements that keep them.

Agents change who can be party to those arrangements, not the nature of the arrangements. The work of keeping a promise can now fall to a person, an agent, a deterministic script, an external service, or several of them in sequence. The commitment does not care which. It cares that the work advances, meets its standard, and can be corrected when it goes wrong.

The performer is a variable

Once the commitment is the unit, the performer becomes a variable. The same promise can be kept different ways at different steps and at different times.

Take outbound sales as a commitment: reach the right prospects each week with something true and useful, and never send a claim the company cannot stand behind. Research on each prospect is work an agent does well. The uncertain claims that need a human eye are a decision that belongs to a person. The follow-up three days later is a scheduled step a script can own. One promise, three kinds of performer, assigned per step rather than handed to a "Sales Bot" that owns all of it and answers for none of it.

Treating the performer as a variable also makes the company more resilient. A model improves and you route a step to it. A human leaves and the promise does not leave with them, because the promise was never a property of the person. In the roster model, knowledge and accountability walk out the door with whoever owned the persona. In the commitment model, the promise, its standard, and its record stay put.

Managing promises instead of personas

The two models diverge most clearly in how they are managed.

The difference is easiest to see when something goes wrong. In the roster model, a failure is a bad employee. You read the transcript, decide the agent underperformed, and adjust its instructions. The promise it was supposed to keep is nowhere in the frame. In the commitment model, a failure is a promise that was not kept to standard, and the system already holds the standard, the owner, and the last ten runs. The question stops being "was the bot good" and becomes "is this promise still dependable."

That second question is the one a company can actually manage. It has an answer that changes over time, and the answer tells you where to look.

What it costs

The commitment model asks more of you up front, and it is worth being honest about that. A persona is easy to stand up and hard to hold to account. A commitment is harder to define. You have to say what the promise is, what counts as keeping it, where a human must decide, and what a good record looks like.

For a one-off task, that effort is not worth it. If you need something once, ask an agent and move on. The payoff arrives with repetition. Anything a company does once is a task. Anything it does every week is a commitment, and commitments are where reliability, or its absence, compounds. The work of defining them is the work of deciding how your company actually operates, which was never going to be free.

Keeping promises you can see

This is why Task Machine does not start from the agent. The unit is the commitment, expressed as a workflow with a defined standard: the steps that keep the promise, the checks that confirm it was kept, the points where a human decides, and the record every run leaves behind. Humans and agents are performers assigned to that work, not colleagues who own it. When judgment or authority is genuinely needed, the exception arrives in one inbox instead of scattering across chats and terminals. An agent earns more room as a commitment proves dependable, rather than because someone raised a setting on a persona.

The shift is small to describe and large in consequence. You are not hiring a company of bots to sit beside your team. You are stating what your company promises to do, and letting the most fitting mix of people, agents, and software keep those promises under standards you can read.

The next question is what that makes possible once capability stops being tied to headcount. Continue with The Age of Organizational Leverage.