AI agent

An AI agent is software that works toward a goal by choosing what to do next, using a tool, and checking what happened. From there it can continue, stop, or ask for help, without you choosing every step.

In the 150+ franchise units in the delivery data I review, roughly 80% still use chatbots, 15% use trigger-based workflows, and about 5% use agents started by conditions. The difference is who chooses the next step, you in a chatbot, the written path in a fixed workflow, or the model in an agent.

That flexibility can help when you can’t map every next action in advance, but you can still set a goal, permissions, and a way to check completion. And somebody in your firm still has to own the result and take over when the agent fails.

What does an AI agent do?

An AI agent repeats a small loop around a goal. It gathers information, decides what to do, acts through a tool, reads the result, and decides whether another step is needed. The loop ends when the job is complete, when a rule says to stop, or when a person must take over.

OpenAI’s practical guide to building agents describes three basic parts, a model, tools, and instructions. The model chooses the action, the tools let it read or change another system, and the instructions define the job and its limits.

For a new client request, a model can draft a reply from text someone pastes into a chat. An agent can go further, opening the approved account record, checking scope and the last client commitment, then choosing a response type, drafting the reply, creating a task, and sending a pricing exception to a person.

What it finds at each step can change what it does next.

So don’t check only whether the email reads well. If the job includes updating the client record and creating a task, those things need to happen on the right account, with evidence you can check, before you call the work finished.

How is an AI agent different from nearby terms?

These labels describe different parts of the work, so it helps to separate them before you buy or build anything. In a chatbot, a manager asks for a follow-up email, while a fixed AI workflow might draft it, send it for review, and file it in an order someone already chose.

An agent can check the account and choose the next allowed action based on what it finds. That’s the behavior people mean by agentic AI, while AI employee names the role you give the software, such as watching client health and recording what needs attention.

Agentic AI names the behavior of choosing and taking action, while the AI agent is the software doing the work. One agent can behave that way, and several agents can still follow a mostly fixed path.

An AI workflow follows steps defined before the run, which is the distinction in Anthropic’s engineering guidance. An agent chooses its process and tools as it goes, though you can put one agent inside a fixed workflow for a decision you can’t map ahead of time.

An AI employee is the organizational role assigned to the software. It has a job, access, trigger, and way to validate the result. The agent is one way that role performs flexible work. Orchestration coordinates state, handoffs, retries, and stop conditions around the run.

What does an AI agent look like in a business?

I’d start with one narrow job rather than asking the first agent to run a whole department.

For client health, you might start the agent when an account goes four business days without recorded contact with the client. It reads the approved account history and checks for a scheduled meeting or delivery, then chooses among three actions, drafting a check-in, creating an internal task, or sending the evidence to the account owner when a person needs to decide.

The run should end in the system where you manage delivery, with the task created, the draft attached to the correct account, and the source records kept. You need to check those things there, because a message saying “done” doesn’t prove they happened.

Anthropic’s guide to agent evals separates the outcome, what actually changed in the system, from the transcript, the steps the agent took. A booking agent can say it booked a flight when no reservation exists, just as a service agent can say it handled a request while the CRM points to the wrong client.

A long prompt that produces the same client-health draft can still help a manager, but the person finds the account, collects the context, starts the work, and carries the answer into the CRM. The agent starts to own that job when a defined condition starts the run and a checked business record confirms it finished.

What authority should an AI agent have?

When you give an agent a tool, you’re giving it permission to do something. Reading the CRM, sending a client message, changing a price, and deleting a record have different consequences, so don’t bundle them into one permission called “CRM access.”

In February 2026, NIST opened work on agent identity and authorization because agents can reach data, tools, and applications. Its concept paper names identification, authorization, auditing, non-repudiation, and prompt-injection controls.

For a business, the operating rules are plain:

• give the agent its own identity;
• grant only the access the job needs;
• record reads, decisions, and writes;
• require approval before a hard-to-reverse action;
• name the person who receives a stopped or failed run.

Start with read access and a draft. Add a reversible write after the agent passes representative cases. Keep a person before money moves, scope changes, a client receives a promise, permissions change, or a record disappears.

Use this test for autonomy: can the firm check the result and undo the action? A better model can improve the answer. It does not make a bank transfer reversible or a client promise cheap to retract.

When is a workflow better?

Use a workflow when you can draw the path before the run starts. For that kind of work, it’s usually easier to test, cheaper to run, and more predictable when a step fails.

A proposal process often has a stable sequence. Collect the approved transcript, match the CRM record, extract requirements, draft, review the price, and file the final version. The model can write inside that path without deciding what the whole process should do next.

An agent is worth its extra cost when the next action depends on evidence found during the run. A support request may need a policy lookup, a refund check, a technical investigation, or a handoff. Writing every branch as ordinary rules may cost more to maintain than giving one bounded agent a small tool set and a clear decision standard.

Anthropic recommends starting with the simplest design that works because agents add delay and cost in exchange for flexibility. A fixed workflow gives you a known path to investigate, while an agent may reach the same wrong outcome through several paths, so you need to budget for finding out what happened.

OpenAI recommends expanding a single agent’s tools before splitting work across specialists. A second agent adds a handoff, which means deciding what information it receives and who owns the result.

I’d add one when part of the work needs its own specialist. More boxes in the diagram aren’t a reason on their own.

How should a business test its first agent?

Test the job before testing the demo. Write the goal, allowed tools, final business record, stop rule, and recovery owner before the first production run.

Build cases from real work. Include a clean request, missing information, conflicting client records, a tool timeout after a write, an instruction hidden inside an untrusted document, and a request the agent should refuse. Run several trials because model choices vary.

Score the final state with an eval. Check that the right account changed, the right evidence was used, the action stayed inside permission, and the agent stopped where the rules required. A strong draft attached to the wrong client is a failed run.

There’s still little public evidence about agent safety testing. The 2025 AI Agent Index documented 30 prominent deployed agents, and only four provided agent-specific safety evaluations.

That doesn’t give you a failure rate for your job, so you still need your own cases, records, and tests of what happens when a run needs recovery.

Where does an AI agent sit on the Delivery Model Ladder?

An AI agent sits at Stage 2, Augmented, on the Delivery Model Ladder when a condition starts a bounded job, the agent uses approved company systems, a check confirms the result, and a named person receives judgment calls or failures.

At Stage 1, a person starts the run, watches it, and carries the result into the next system. The model may make several choices, but the person still holds the workflow together.

Stage 3 requires a change in how the firm delivers work, and a complex group of agents can remain at Stage 1 if people repair every handoff. One plain agent with limited tools, a reliable check, and a clear way to recover can be solid Stage 2, doing the job the firm assigned to its AI employee.

Use an agent when mapping every next action in advance becomes impractical and your firm can still test, monitor, stop, and recover the work. Otherwise, start with fixed automation or an AI workflow.