When AI Moves from Answers to Action

At 9:12 on Monday morning, a message arrives in the inbox of a small company that sells commercial coffee equipment:

We run a bakery with two locations and need a machine that can handle the morning rush. Can you recommend one, tell us whether it can be installed before our new location opens on the 18th, and send pricing?

The message is ordinary. The work it creates is not. Someone must understand the request, find a suitable product, check stock and installation capacity, assemble accurate pricing, and respond. The intended outcome is not merely to send a quote; it is to help the customer identify a suitable machine and get a reliable answer about price and timing. Here is how the same inquiry might be handled in four ways.

1. A person does the work

Maya, the company’s sales coordinator, reads the email and notices the important details: two locations, a busy morning, a firm opening date. She checks the product guide, asks the warehouse about availability, and messages the installation team. Once she has answers, she decides which machine is suitable, prepares a quote, and replies. If the installation date is uncertain, she might call the customer before promising anything.

2. An AI assistant helps Maya

Maya could give the inquiry and relevant product information to an AI assistant and ask for a draft response. It might summarize the customer’s needs, suggest a machine, and produce a polished email. Maya would still need to verify stock and installation availability, judge the recommendation, and move the inquiry forward.

3. Fixed automation handles a known step

The company could set up a rule to send a standard price list when an email mentions “pricing,” or route requests with installation questions to sales. That may handle routine cases efficiently, but this inquiry still needs someone to reconcile the bakery’s needs with current availability and its opening date.

4. An agent works through the inquiry

As a hypothetical example, an AI agent could be given the assignment to determine what the customer needs, identify a suitable machine, consult company product and pricing records, check current stock and installation availability, prepare a quote, and send a response within company rules. Whether a real system can reliably do those things depends on its capabilities, the quality of its data and tools, and the limits set for it. If the schedule is unclear, the requested discount exceeds its authority, or two products seem equally suitable, it could pause and ask Maya to decide.

In this proposed arrangement, the difference would become tangible in the work Maya no longer has to do herself: gathering information across systems, resolving the steps, and preparing the response. An action is not an outcome: sending a quote is only useful if it is accurate, suitable, and timely. The next question is which parts of that work are suitable to delegate.

That last distinction—who decides how the work gets done—is the useful one. The words assistant, automation, and agent can be used loosely in product descriptions, but they point to three different arrangements between a person and a system.

Assistance: the person stays at the desk

An AI assistant helps someone think, write, summarize, compare, or plan. Maya might paste in the customer’s inquiry and ask for a concise reply, or ask the system to list questions she should clarify before recommending a product. The system contributes useful work, but Maya remains responsible for deciding what to do and carrying it out.

In this arrangement, Maya directs the work one request at a time. An assistant may have access to company records or tools; lack of access is not what defines assistance. The useful distinction is how much of the sequence Maya delegates. Asking it to retrieve an order is different from assigning it to investigate a delayed delivery, choose the necessary checks, and return with a supported next step.

Automation: the route is fixed in advance

Fixed automation follows predefined rules, which may include many steps and branches, when defined conditions are met. If an inquiry arrives through the website, the system might send an acknowledgment, create a record, and assign it to the sales queue. The rule is chosen beforehand; the system follows it when the matching event occurs.

This can be dependable and efficient. A thermostat does not reconsider the purpose of keeping a room comfortable each time it switches on. In the same way, a business rule does not improvise a new process for each customer. It handles the cases its designers anticipated. If the inquiry arrives in an unexpected format, asks two unrelated questions, or requires a judgment the rule cannot express, the automation may do nothing—or do the wrong predefined thing.

Delegation: the goal is given, and the route can vary

In this book, an AI agent means a system in which a language model helps choose the next steps and tools toward an objective, using the results to guide what happens next. The model is the component that interprets language and proposes actions; the surrounding software supplies access, executes permitted actions, and manages the workflow. This distinction between a predefined route and model-directed steps is useful even though product labels vary ^[1].

An agent is given an objective, access to relevant context and tools, and boundaries on what it may do. It can decide which steps to take, perform some of them, inspect the results, and adjust its approach. For Maya’s bakery inquiry, that might mean clarifying the equipment needs, checking product suitability and installation capacity, drafting a tailored quote, and preparing a follow-up—while pausing before offering an unapproved discount or sending a message in an uncertain case.

The distinction is not that an agent has freedom without limits. It is that the instructions describe an outcome, not only a single route. Two inquiries may require different steps to reach the same useful result. The agent has some discretion over those steps; the business still sets the objective and the boundaries. Delegate a bounded objective, not a blank check.

A compact way to remember the difference is this: assistance helps a person do the work; fixed automation follows a preset route; delegation gives a system room to pursue a goal. In practice, these arrangements can overlap. An agent may use fixed rules for routine actions and ask an assistant-like question of a person when it reaches uncertainty. What matters is not the label on the software, but who chooses the next move—and who remains answerable for the result.

That last question—who chooses the next move—sounds like a matter of convenience. It is really a change in how work is organized.

When an AI drafts a reply to a customer, a person can inspect the draft before anything happens. If the system instead sends the reply, updates the customer record, and schedules a follow-up, the work has crossed a boundary: the system is carrying out part of the process, not just shaping a decision.

For the company handling inquiries, this means distinguishing ordinary requests from cases that need a person’s judgment. A customer asking where an order is may be straightforward. A customer reporting a damaged product, disputing a charge, or threatening legal action is not just another message to process. The workflow needs a way to route unusual or consequential cases for attention.

A system can perform an action, but it cannot take responsibility for the consequences in the human or organizational sense. If an agent promises a refund the company cannot honor, the organization still has to answer for what was sent. Capability does not confer accountability. The business remains accountable for the process it designed.

The cost of a mistake depends on what the action does. A slightly awkward draft is easy to revise; a message sent to hundreds of customers, a changed account setting, or a commitment of company money may be harder to undo. Oversight should reflect those differences. Likewise, a polished explanation is not proof that the agent understood the customer or relied on current information. The important question is whether the work produced the intended result, not simply whether the system took an action.

And the word agent does not settle any of those questions. It does not guarantee that a system can handle ambiguity, that its judgment is sound, or that it will reliably complete a task. Some products called agents follow narrow, prearranged paths. Some systems that are not marketed with the label can still take useful, goal-directed actions. The name may tell you something about the intended style of operation; it is not a quality certificate.

For the small company handling customer inquiries, the practical question is therefore not, “Can we let the agent take over?” It is, “Which parts of this work can it handle within clear limits, how will we notice when those limits are reached, and what happens next?” That question keeps the promise of delegation—and its risks—in view. It also points to the mechanics beneath the label: how an agent receives an objective, uses context, chooses among possible steps, and checks what happened.

Throughout the book, the Delegation Check returns to five questions: What outcome matters? Where does the route require judgment? What information and tools are needed? What actions are allowed? How will results be verified, and who owns them? The chapters build these questions into a practical way to assess a piece of work.