An AI agent is a language model that has been given a goal, a set of tools, and permission to keep working until it decides it is finished.

That is the whole idea. Everything else is detail.

The word gets used loosely enough that it has started to mean nothing, so it is worth being precise. A chatbot answers you. An agent does something and then checks whether it worked. The difference is not intelligence. It is whether the system can reach outside itself and change the state of the world.

The four parts

Every agent, regardless of vendor or framework, is assembled from the same four components.

The model. The reasoning engine. It reads the current situation and decides what to do next. It does not know anything about your business except what you put in front of it.

The instructions. A written definition of the job, the boundaries, and the standard for done. This is the part most people underinvest in. A vague instruction produces a plausible-sounding agent that quietly does the wrong thing.

The tools. The specific actions the agent is permitted to take. Look up a customer record. Send an email. Create a calendar event. Query a database. An agent with no tools is a chatbot. An agent's real capability is exactly the list of tools you gave it, and nothing more.

The loop. The mechanism that makes it an agent rather than a single response. The model picks a tool, the tool runs, the result comes back, and the model looks at that result and decides what to do next. It repeats until the goal is met or a stop condition fires.

What a run actually looks like

Say you give an agent one job: when a new inquiry arrives, qualify it and get it in front of the right person.

The loop runs something like this. Read the inquiry. Call a tool to check whether this company already exists in the CRM. It does, and there is a note from eight months ago. Call another tool to pull the prior conversation. Decide, based on the instructions, that this is a returning prospect rather than a cold lead. Draft an internal summary. Call a tool to post it to the right channel. Stop.

Five tool calls and a handful of decisions. No human touched it.

Now notice what made that work. The agent had a real CRM connection, not a description of one. It had a written rule for what separates a returning prospect from a cold lead. It had a defined stopping point. Remove any one of those and the run either fails or, worse, produces something confident and wrong.

How this differs from the automation you already have

If you have used a tool like n8n or Zapier, you have built deterministic automation. When this happens, do that. The path is fixed. You drew it.

An agent chooses its own path at each step. That is the entire trade.

Deterministic automation is predictable and brittle. It does precisely what you specified, and it breaks the moment reality presents something you did not anticipate. An agent handles the unanticipated case, and in exchange you give up the guarantee that it will do the same thing twice.

Neither is better. They solve different problems, and most systems worth building use both. The judgment is knowing which parts of a workflow need to bend and which parts must never vary. Billing should never bend. Triage usually should.

The part that is missing from most demos

Agents are probabilistic. Every individual step has an error rate, and in a loop, those rates compound.

Work the arithmetic. If each step in a chain is right 95 percent of the time, and the agent takes ten steps, the odds that the whole run is correct end to end are about 60 percent. Not 95. Four runs in ten go wrong somewhere.

This is why the demo is always impressive and the deployment is always disappointing. A demo is one run, curated. Production is a thousand runs, uncurated, on inputs nobody previewed.

The number does not mean agents do not work. It means the design problem is not "how capable is the model." It is "how do I keep the chain short, catch the failures, and make sure the expensive ones cannot happen silently."

What separates the ones that work

Four things, consistently.

Narrow scope. An agent that does one job well beats one that does six jobs unreliably. Shorter chains fail less. The compounding math is the argument.

Tools that fail loudly. When a tool call fails, the agent must be told it failed. A tool that returns an empty result on error teaches the agent that there was nothing there, and it will proceed on that basis with total confidence. Most agent failures I have investigated trace back to a tool that swallowed its own error.

A checkpoint before anything irreversible. Sending money, deleting records, emailing a client. An agent can draft it. A person approves it. This single rule eliminates most of the risk that makes people nervous about agents, and it costs almost nothing in throughput.

A record of what happened. Every tool call, every decision, logged. When an agent does something strange, you need to be able to read back what it saw and what it chose. Without that you are guessing, and guessing at a probabilistic system is how you end up rebuilding it from scratch.

The question to ask first

The useful question is not whether AI agents work. They do, within limits that are now reasonably well understood.

The question is whether the process you want to hand over is one you could write down. Not automate. Write down. If you cannot describe the decision rules in plain language, an agent will not discover them for you. It will produce something that looks like the answer and behaves like a guess.

Most failed agent projects are not model failures. They are the discovery, halfway through, that nobody had ever actually defined the process being automated.

Define it first. The agent is the easy part.