An enterprise AI agent is software that picks its own next step and acts in your business systems until a task is done. A chatbot only answers. A workflow follows fixed steps.
Give an agent its first job where work repeats, done is easy to check, mistakes are cheap, and people take the hard cases.
A payments company switched on an AI assistant for customer service. In its first month, it handled 2.3 million conversations, two-thirds of all chats.
The company said that was the work of 700 full-time staff. Answers that took 11 minutes now took under 2. Cue the victory lap.
Over a year later, its chief executive said cost had weighed too heavily in how they judged the project. Quality had dropped. They started hiring people again.
The assistant was not switched off. It still answers two-thirds of the questions. What changed is which questions it gets.
An enterprise AI agent is software that picks its own next step and acts in your business systems until a job is done. It looks, decides, acts, checks the result, and goes again.
Most talk about agents is about the model. The money is in the job you hand it.
So this guide is about that choice. Which work goes to the agent, which goes to a plain workflow, and which stays with a person.

The agent kept its job; it lost the hard cases
Company figures as reported by CX Dive, March 2024 and May 2025. Company-reported, not independently verified.
Three different things get sold under the word agent. They behave very differently once real work hits them.
A chatbot answers. It may answer well, but it changes nothing in your systems.
A workflow follows steps a person wrote in advance. AI does some of the steps, like reading an email or drafting a reply. The path never changes.
An agent picks its own path. It gets a goal and a set of tools, looks at what comes back, and decides what to do next.
The idea is older than any of this. The classic AI textbook defines the whole field as the study of agents. Chip Huyen's AI Engineering puts it simply: an agent senses its surroundings and acts on them.
So the tool list is the real job description. No email tool means no email gets sent.
John Berryman and Albert Ziegler, who helped build one of the first AI coding assistants, describe a trade-off in Prompt Engineering for LLMs. The more general an AI setup is, the weaker it is at hard, multi-step work.
Narrow the job and add structure, and it gets stronger. A chat window will talk about anything and finish almost nothing.
A chatbot answers, a workflow follows steps, an agent picks them
| Chatbot | Workflow | Agent | |
|---|---|---|---|
| Who picks the next step | Nobody; it only replies | A person, in advance | The model, as it goes |
| Can it change your systems? | No | Yes, at fixed steps | Yes, with the tools you grant |
| How easy to check | Easy | Easiest | Hardest |
| Best for | Answering questions | Repeat jobs with known steps | Jobs where the next step depends on what it finds |
| Example | Answers billing questions from help pages | Matches each invoice to an order and flags gaps | Researches a new lead across sources until it can write a brief |
Our comparison. Examples are illustrations, not client work.
Narrow the job and the AI gets stronger
Berryman and Ziegler, Prompt Engineering for LLMs (the generality and strength trade-off).
The Finish-Line Test picks an AI agent's first job with five questions: does the work repeat every week, can two people name the finish line in one sentence as the customer's result, does someone know the job well enough to grade it, is a mistake cheap or approved first, and does a named person take the hard cases. Fail the finish line and you fix the process first. Pass all five with fixed steps and you build a workflow.
Pass all five where the next step depends on what it finds and you have an agent job, launched read-only with one write action at a time.
Berryman and Ziegler's clearest example is a pitch job. A small shop that builds add-ons for online stores has a slow quarter.
The plan: find stores, study each one, invent an add-on it would want, and email the owner a pitch. One developer really did this, sent thousands of AI-written emails, and got some eager replies from store owners.
Then the authors tried the same job with a general agent. With no tools, it wrote a plan and stopped.
Given search, browsing and email tools, it ran one lazy web search. It wrote thin ideas and drafted form letters that still said [your_name].
More rules in its instructions made it worse. The prompt grew, the agent got confused, and nothing let it work through stores one at a time.
When it failed, what would you fix? Nobody could say. Their verdict on the long instructions: a strong suggestion and nothing more.
What worked was a workflow. Each step became a small task with one input and one output, joined in a fixed order.
Not every step even used AI. Fetching store pages was a plain web crawler.
Less impressive than an agent? Sure. It also worked.
Their rule is ours too: simpler is almost always better. If a step works without AI, take the AI out.
An agent earns its place only when the next step truly cannot be known in advance. Everything else is a workflow. Boring wins.
The same pitch job failed as an agent and worked as a workflow
| General agent with tools | Workflow of small tasks |
|---|---|
| One lazy web search for stores | A plain crawler fetches store pages, no AI |
| Thin, samey add-on ideas | Brainstorm several ideas, then pick the best |
| Form letters that still said [your_name] | Plan the pitch, then the subject line, then the body |
| Longer instructions, more confusion | Each task has one input and one output |
| When it failed, nothing clear to fix | A failure points to one task |
Berryman and Ziegler, Prompt Engineering for LLMs (the add-on pitch example).
Example: the pitch job as a workflow, with AI only where it helps
Steps 1 to 4 follow Berryman and Ziegler, Prompt Engineering for LLMs. Step 5 is our addition.
The Finish-Line Test is our five-question check for picking an AI agent's first job. A job must pass all five.
1. Does it repeat? Dozens of similar cases a week, not a few a year, or the savings never add up.
2. Can you name the finish line? Two of your people should agree, in one sentence, when one case is done right.
3. Do you know the job cold? Pick work someone on the team could do and grade in a minute.
4. Is a mistake cheap? A wrong move can be undone, or a person approves it before it lands.
5. Is there a lane for hard cases? The agent hands what it cannot solve to a named person, fast.
Fail question 2 and you have a process problem, not an AI problem. Fix the process first, as our guide to operations problems disguised as AI problems explains.
Pass all five, but the steps never change? Build a workflow. It is cheaper and easier to check.
Pass all five, and the next step depends on what the agent finds? That is an agent job.
Five yeses or no agent. No exceptions for the pilot.
A job must pass all five questions before an agent gets it
Our test. Question 3 draws on Andy Grove, High Output Management (hand off the work you know best).
Start where work repeats and mistakes are cheap
Our decision rule.
Four tasks, five questions each: only one is an agent job

Example page built for this article with a made-up company, 2026-10-18. Tasks, volumes and owners are invented to show the Finish-Line Test. No client data.
A finish line is the result the customer notices. Activity is what your system did along the way.
Clayton Christensen and his coauthors tell this story in Competing Against Luck. A big tax-software company spent years polishing the question-and-answer interview inside its product. Customers asked for 150 features.
Then a new leader saw the real job. Customers did not want a better interview. They wanted their taxes done.
So the team worked to remove questions. Filling in just one section from payroll data raised the share of people who finished, even when they had to fix some of it.
Taxes done, not questions answered. That is a finish line. Christensen's team calls this the job to be done.
Apply that to the payments company, in our reading. Cost per chat is easy to count. The finish line is whether the customer's problem got solved.
Our rule: write the finish line as something the customer would notice, then count that. Activity numbers flatter the agent. The finish line tells the truth.
Count what the customer notices, not what the agent did
| Activity count | Finish line |
|---|---|
| Chats closed | Problem solved, with no second contact |
| Interview questions answered | Taxes filed |
| Emails sent | Replies that book a meeting |
| Reports generated | A decision made from the report |
| Leads tagged | The right leads reach sales the same day |
Tax example: Christensen et al., Competing Against Luck. Other rows are our examples.
Your first agent job is probably hiding in someone's week. You find it with a time log, not a vendor demo.
Mike Michalowicz has teams log their time, then sort every task in Clockwork. Trash it, transfer it, trim it, or keep it. Transfer means handing work to cheaper people or to software.
When he ran this on his own team, his assistant was spending more than 68 percent of her day booking his schedule. That work moved to scheduling software, not to a new hire.
Notice it was not an agent. It was plain software. The log still came first.
Andy Grove adds a rule in High Output Management that feels backwards. Hand off the work you know best, because that is the work you can check.
We apply it to agents. Never automate a job nobody on the team understands.
Who on your team is drowning in repeat work they could grade in their sleep? Start there.
One time log found most of a skilled person's day in work software could take
Mike Michalowicz, Clockwork (a case from his own team).
One week of real hours shows the first agent job, and how few rows need one

Example page built for this article with a made-up company, 2026-10-18. Trash, transfer, trim and keep follow Mike Michalowicz, Clockwork; the agent and workflow split is ours. Every task and hour is invented.
Every tool an agent gets does one of two things. It reads, or it changes something.
Huyen splits them the same way. Read-only actions let an agent look around. Write actions let it act: send the email, update the record, move the money.
Write actions are where the payoff is. They are also where the damage is.
Her comparison is plain. You would not let an intern delete your live database, and you should not let an untested AI start bank transfers.
Her warning goes further: the more automated an agent gets, the worse its failures can be. The security group OWASP calls the same risk excessive agency.
So the first job starts read-only. Research new leads, sort the inbox, pull the weekly numbers, draft replies into a queue a person sends.
Then add one write action at a time, each behind a person's approval until it earns trust. Write those approval levels into your AI governance framework. The full build order is in our guide to what an agent harness is.
How to turn an agent pilot into an emergency board meeting in four easy steps:
1. Pick the job with the biggest headcount number, not the clearest finish line.
2. Give it every login on day one. Setup is faster.
3. Measure chats closed and call it success.
4. Let customers find the hard cases for you.
Congratulations. You automated annoying your customers.
Climb one rung at a time, one action at a time
Our ladder. Read and write actions as defined in Chip Huyen, AI Engineering.
Reading is cheap to allow; every write action is a decision
| Read-only (the agent looks) | Write (the agent changes things) |
|---|---|
| Search the CRM for a contact | Update the contact's status |
| Read the inbox | Reply to the customer |
| Pull last week's ad results | Change an ad budget |
| Look up an order | Issue a refund |
| Worst case: a wrong summary | Worst case: the customer or the bank sees it |
Categories from Chip Huyen, AI Engineering. Examples are ours.
Grove describes a post office that sorted 90 percent of letters by machine. The 10 percent it could not read went to people, who typed in the addresses from photos.
Nobody called that 10 percent a failure. It was the design.
Agents work the same way, in our reading. The easy cases go to the machine. The odd, angry and high-stakes cases go to a person, fast.
That is where the payments company ended up. Its spokesperson summed it up: AI solves the easy stuff, and people handle the moments that matter.
So write the handoff rule before launch. Name the person, the trigger, and how fast they answer. Engineers call this human in the loop.
Can't name who catches the hard cases? Then your customers will find them for you.
The post office automated 90 percent and planned for the other 10
Share of letters, by who sorted them
Andy Grove, High Output Management (the post office example).
They fail for boring reasons. The model is rarely the problem. That is good news, because boring is fixable.
Grove's breakfast factory buys a machine that boils eggs nonstop. It is cheap and steady, but it only makes three-minute eggs.
Worse, if the water drifts out of range, every egg in the machine spoils before anyone notices. His fix was a thermometer with an alarm.
Agents behave the same way, in our reading. They pay on standard work, and they can go wrong quietly at scale.
So every agent needs its thermometer. Pick one number someone checks daily, with an alarm level written down.
Long chains add risk too, because small errors stack up step by step. Our guide to evaluating AI agents shows the math and the tests.
And one person must answer for it. Our guide on who should own AI covers how to pick them. Cost per finished case belongs on their scorecard, as in controlling AI token spend.
Agent projects fail for boring reasons you can check
| Cause | What it looks like | Fix |
|---|---|---|
| Wrong finish line | Great activity numbers, unhappy customers | Count the customer's result |
| Nobody knows the job | No one can say if the agent was right | Pick work you know cold |
| Steps never change | An agent slowly doing a checklist | Build a workflow instead |
| No lane for hard cases | Customers stuck in loops | Name the person and the trigger |
| Silent drift | Quality slides for weeks before anyone looks | One daily number with an alarm |
| No owner | Everyone's pilot, nobody's problem | One named person |
Our list. Silent drift draws on Grove's egg-boiler example in High Output Management.
The prompt below runs the Finish-Line Test on your own task list. Paste it into your preferred AI and answer six short questions.
It scores each task, tells you whether it needs a workflow, an agent or a process fix, and drafts a read-only launch plan. It never invents your numbers.
Once you have a winner, write its brief with our agent job spec.
Paste into your preferred AI. It asks six questions about your tasks, scores each one, and drafts a read-only launch plan.
Act as an AI operations advisor. Help me pick the first job to give an AI agent, using the Finish-Line Test. Ask me one question at a time, with the example: 1. List 3 to 5 tasks my team repeats. (Example: sorting new leads, matching invoices to orders, pulling the weekly ad report) 2. For each task: how many times a week, and how many minutes each? (Example: 120 leads a week, 4 minutes each) 3. For each task: in one sentence, what does done right look like to the customer or the person who gets the result? (Example: a qualified lead gets a reply within one hour) 4. For each task: who on my team knows it well enough to grade it? (Example: our sales lead) 5. For each task: what is the worst mistake, and can it be undone? (Example: quoting a wrong price; no, the customer sees it) 6. For each task: who handles the hard or odd cases today? (Example: the office manager) Rules: - Score each task pass or fail on five questions: it repeats every week; the finish line fits in one sentence and is the customer's result, not a count of activity; someone on my team can grade it; a mistake is cheap to undo or a person approves first; a named person takes the hard cases. - A fail on the finish line means fix the process first. Say so plainly. - If the steps are always the same, recommend a workflow, not an agent. Recommend an agent only where the next step depends on what it finds. - Start every pick read-only. List each action that changes something. Anything that contacts a customer, spends money or deletes data needs a person's approval. - Show weekly hours as times per week multiplied by minutes each. - Never invent my volumes, times or costs. If I do not know, mark it unknown and count it as a fail. Show your scoring, then answer in this format: Scorecard: each task, five pass or fail marks, one line why Shape: workflow, agent, or fix the process first, for each task First job: one task and its finish line Launch plan: read-only actions, actions that need approval, the hard-case owner, one number to watch daily with its alarm level Next three actions: 1. 2. 3.
1. Log one week of your team's time. Circle the tasks that repeat.
2. Run the prompt on your top three. Keep only jobs that pass all five questions.
3. Launch the winner read-only, with a named person for hard cases and one number on an alarm.
The payments company did not need a smarter agent. It needed a clear line between the agent's job and a person's job.
Nobody wins a race with no finish line. Draw it first, then let the agent run.
Bring one question from this article. We will tell you what we would do, whether or not you hire us.
Book a 15-Min Chat →