What Is an AI Agent? A Plain Answer for Owners

An AI agent is a computer program that looks at what it just found and then picks its own next step. It stays inside limits that you set. A workflow is different, because it does the steps in an order that someone wrote down ahead of time. We use that split whenever an owner asks us if the new line on the invoice is a real agent or just a form with a louder name.

Cited in this note

88%

Anthropic’s December 2024 essay draws the line the same way. In a workflow, large language models (the kind of AI that reads and writes text) follow a path that the builder set up. In an agent, the model directs its own process and decides which tools to use.¹ The essay also says to start with the simplest thing that works. Add more only when the simple version fails. We keep that advice on the table during these talks.

Most of the businesses we sit with are not stuck because their software is too plain. They are stuck because the work still lives in one person’s memory. Then a seller asks a model to make up a process that nobody ever wrote down.

If the steps are still in someone’s head, the process guide is the check that fits. The use-case note lists jobs that a system might take over. The comparison note stays on the words, which is where sales pages get slippery.

When a workflow is enough

Use a workflow when you already know the steps. Think of taking an email, pulling out the details, writing a draft, and waiting for a person to look at it. Use an agent when the next step depends on what the last step found, and you cannot write down every branch ahead of time. If you cannot say when the system should stop, you do not really have either one yet.

Picture a plumbing desk on a loud Monday. The scheduler runs the book, so she gets the name, the address, and whether there is water on the floor. Then she asks which room it is in and whether anyone shut off the main. Those questions do not change just because a model showed up. A workflow can hold them in a form, a text to the on-call tech, and a line in the book. The fork comes after that intake, and it is the part people like to skip.

A restaurant with water coming through the ceiling is a very different promise from a slow drip under a rental sink. The restaurant needs the owner or the senior tech to say if someone rolls right now. The drip can wait for the afternoon route. Sellers offer an agent for that fork, one that reads the note and picks a tech, a part, and a time. We would let it draft the options. We would not let it text a time until the scheduler or the owner has looked. If the order is known, a workflow will do. If the order depends on what you just learned, an agent may help, and you still want a person who can stop the send.

Here is how the three kinds of system compare. With one prompt, the person at the keyboard picks the next step, and it fits a single draft or a single answer. With a workflow, the path you wrote picks the next step, and it fits work where the steps rarely change. With an agent, the model picks the next step inside the limits you set, and it fits work where the path depends on what it finds.

Read that before you read any product page. With one prompt, the person is still choosing. They paste in the job notes, ask for a reply, and send it themselves, which can save a tired afternoon. That is not an agent, and it does not need to become one. A workflow means you know the order, and the software repeats it without getting bored or skipping the address. An agent means the model looks at what it found and picks a tool, such as the calendar, the parts list, or the text message. The limits are yours, because you decide which tools exist, what the system may never send, and who holds the stop.

That last test is the one we use with owners. If the steps rarely change, stop shopping and write down the path. If the path depends on what the system finds, you may want an agent. You still want the limits on one page that a new hire could follow. We have watched shops pay for an agent to do work that belongs in a simple workflow. Then the staff spends the week fixing a machine that was never supposed to decide anything.

What the survey actually counts

Owners hear a loud number and think the whole trade has already moved past them. McKinsey’s 2025 survey says that 88% of people report regular AI use in at least one part of their business, up from 78% a year earlier.² That is a wide claim, because regular use can mean a person pasting a quote into a chat window on a Thursday. It is a very different thing from saying “we run an agent.”

The numbers about agents are smaller, and they are the ones we want in the room. About 23% say their companies are rolling out an AI agent system somewhere, and another 39% are trying agents out. In any single part of the business, no more than 10% say they are rolling out agents. Read that last number slowly. An agent somewhere in a big company is not the same as an agent running the scheduling desk. Companies that earn less than $100 million a year are less often at the wide rollout stage, at 29%. Nearly half of the companies that earn more than $5 billion are further along.

Those are survey shares for big groups of companies. They are not a score for one small business. An agent still needs a written process and a person who can stop it.

We say this out loud because the big percentage gets used as a shove. A seller will put the 88% on a slide and talk as if a shop with a few trucks is running late. The survey does not say that. It says use is common, and rolling out an agent inside one team is not. If companies with real operations teams are mostly still trying things, you are allowed to write down your process first. You can do that before you buy a system that picks its own tools. The survey is a count of what people said. It is not a definition of an agent, and it is not a grade for your desk.

A worked example

Stay with the plumbing desk and give everyone a job. This is a walk-through and not a result we measured. The owner takes the hard calls, a scheduler runs the book, and Luis and Priya work on the trucks.

A property manager calls about a smell in more than one unit. The scheduler opens the job the way she always does. She takes the name, a callback number, the address, the keys, and whether anyone is home. That part is a workflow, and it should not depend on a model’s mood. Then the notes get messy. One unit had a dishwasher replaced not long ago, and another has a tenant who shuts off the water and tells nobody. A third unit is empty. The next step depends on what the scheduler just heard. Which door gets the first visit? Should the truck carry a camera? Is a smell in an empty unit a bigger problem than a clogged trap?

An agent, in the sense of that 2024 essay, could read the notes, look at the afternoon routes and the parts list, and suggest an order. It might send the empty unit first and put a camera on the truck. It might pick Luis because he did the camera work last week, while Priya is already on a job across town. The suggestion is the agent’s work. The text to the manager is not, until the scheduler okays the words and the time. If the model cannot see the route, it should say so and stop. It should not make up an arrival window. A card by the phone says that no time goes out unless a person on the desk has tapped yes.

A workflow ends at the form. That is the right ending for intake, but it is the wrong tool for this fork, because you cannot write every branch of a messy call about many units ahead of time. A single prompt would mean the scheduler pastes the notes into a chat box and asks for a polite reply. That is fine on a quiet afternoon. But it does not watch the route, and it does not send anything.

The owner does not need a lecture on models. He needs to know which choices the desk may hand off. The scheduler needs “suggest” and “send” to be two different buttons. Luis needs the camera on his truck if the camera was the point. If none of them can point at the control that stops the system, you do not have an agent yet. You have a chat box wearing a job title, and the customer will hear its mistakes in your voice.

How we’d run it

We would not start by picking software. We would sit with the scheduler and write down what she already does when the phone is mean.

First, name the job in one sentence that a new hire could repeat. For example, turn a call into a visit the tech can finish, without promising a time the route cannot keep. If that sentence grows into a whole menu, you have not named the job yet.

Second, write down the steps that never change. These are the name, the number, the address, the access, what is happening, and who is rolling. Use the scheduler’s order and not a template’s order. This workflow is the floor you build on, even if an agent comes later.

Third, mark the forks. A fork is any moment when the next step depends on what the last step found. It might be which unit to visit, whether to bring a camera, or whether the job is an emergency or can wait for the afternoon route. If you can write it as a rule, it is still a workflow. A rule like “water through the ceiling, page the owner” does not need a model.

Fourth, choose what the model may touch. We let it draft, suggest a tech, and suggest a part. We do not let it send, set a price, or say a word about who pays for damage. If the limit says “use your judgment,” you have left a hole, and the model will fill it with something polite.

Fifth, name the stop and the person who holds it. The scheduler can stop it, the owner can stop it, and a tech can send back a job that came without the part. The system stops when a fact is missing, when a time falls outside the route, or when the caller is angry. Stopping is a good result and not a failure.

Sixth, replay recent jobs with the names covered up. The scheduler compares what the system suggested with what the desk actually did. She hunts for the time it sounded sure but was wrong. Fix the limits before a live customer sees a message. Only then should you try it on today’s calls, with the send button still in a person’s hand. We would repeat that replay until the refusals look right. We would not turn on automatic texts just because a free trial is ending.

Common mistakes

The first mistake is a new name on an old tool. The chat box gets called an agent because the invoice said so. But if a person still picks every next step, you have one prompt. That can be the right tool, yet the new name makes the staff expect judgment that the box does not have.

The second mistake is skipping the written path because writing feels slow. Then every exception becomes the model’s problem, even the ones a card by the phone could handle. The staff stops trusting the book, and the scheduler goes back to her memory while you pay a fee on top.

The third mistake is a missing stop. The model may send texts, and nobody is named to halt it on a bad afternoon. The bad promise is usually small, like a time the tech cannot make. But the customer hears it as the business talking.

The fourth mistake is treating the survey as a target. Having 23% of companies rolling out an agent system somewhere is not a quota. Having 10% in any one part of the business is not a score you are failing. Chasing those shares just buys a tool that nobody can watch over.

The fifth mistake is letting the system near money. That means a price, a waived fee, or a line about whether the landlord pays. A draft that the owner edits is a very different thing from a message that has already gone out.

The sixth mistake is a limit written as a mood. “Be helpful” is not a limit. But “do not offer a same-day visit unless the owner has marked the job urgent” is one. If the scheduler cannot enforce the sentence, the model will be helpful in the wrong direction.

What we’d do

We would write down the scheduler’s path before we paid for anything that picks its own tools. We would use one prompt for the messy replies and a workflow for intake. We would use an agent only at the fork where the next visit depends on what the notes say. We would also keep the send button in a person’s hand longer than a seller likes. Our view is plain. An agent is worth the trouble when the branch is real and a named person owns the stop. It is a poor buy when the process is still a story the owner tells at the counter.

The 2024 essay says to earn the extra complexity. The 2025 survey says that even large companies are mostly not rolling out agents inside any one team. We believe both. Then we go sit with the person who answers the phone, because that person already knows where the path breaks, and the software does not.