What is an AI agent?

The short answer

An AI agent is software that pursues a goal by deciding what to do next and then doing it. That is the whole distinction. A model that answers a question produces text. An agent takes that reasoning and turns it into action inside a system: it queries a database, calls an API, updates a record, escalates to a human.

The useful test is not how sophisticated the model is. It is whether the software chooses its own next step. If every action is hardcoded in a fixed sequence, you have an automation. If the software evaluates the situation and selects an action from a set of options, you have an agent.

What separates an agent from a chatbot

A chatbot receives a message and returns a message. The loop closes with the user. It can be extremely good and still change nothing about your operation, because the outcome depends entirely on the person reading the answer and deciding to act.

An agent closes the loop inside the system. When a customer asks to change a booking, a chatbot explains the policy. An agent checks availability, applies the fare rule, processes the change, and confirms it. The first one deflects a question. The second one moves a number.

This is why a chatbot in the footer rarely shows up in the funnel. It sits away from the decision. The agent has to sit where the business is won or lost.

The four parts every agent has

Strip away the vocabulary and every production agent has the same four components. A model that reasons about what to do. A set of tools, which are the functions it is allowed to call in your systems. Memory, meaning the context it carries about the task and the user. And a loop that lets it act, observe the result, and decide again.

The loop is what people underestimate. A single model call is predictable. A loop that can run five or fifteen steps compounds every weakness in the other three components: a vague tool description, a missing permission, an ambiguous instruction. Most agent failures in production are loop failures, not model failures.

Where agents actually belong

The question that matters is not which process is annoying. It is which decision is worth automating. Look for a point where a human currently decides something repeatedly, with a rule that is real but fuzzy, and where the decision has a measurable consequence.

Credit approval at the point of application. Fare and availability decisions in a booking flow. Triage of an incoming claim. Qualification of an inbound lead. These are decisions with volume, with consequences, and with enough structure that an agent can be held to a standard.

If a decision happens twice a month, an agent is the wrong shape. Write a document instead.

What breaks when an agent reaches production

Demos work because the demo picks the input. Production does not. The failures that appear in week one are almost never about the model being wrong in an interesting way. They are about volume, permissions, and the systems around the agent.

The recurring ones: the agent calls a tool it should not have been allowed to call. It retries a write operation and creates a duplicate. It runs eleven steps on a task that should have taken two, and the latency ruins the flow. It answers confidently from stale data because nobody wired invalidation. It works perfectly until a legacy system returns a shape nobody documented.

None of these are solved by a better prompt. They are solved by engineering: scoped permissions, idempotent operations, timeouts, evaluation on real traffic, and observability that tells you what the agent actually did.

Guardrails are not a feature you add later

A production agent needs to be constrained before it is useful, not after it causes an incident. In practice that means the agent only sees the data the requesting user is allowed to see, only calls the functions that are safe for its role, and has a defined path for handing a case to a human.

The compliance version of this matters in regulated sectors. If the agent participates in a decision about a person, you need an audit trail showing what it saw and why it acted. That is a design requirement, not a report you generate at the end.

Agents are one shape, not the only one

The industry talks as if the agent is the goal. It is not. It is one shape that production AI can take, and it fits when the decision worth automating lives at the point of action.

Sometimes the right answer is a decision layer wired into a flow you already have. Sometimes it is a retrieval system your team can actually trust. Sometimes it is a reconciliation that has to be right every single time and should never be creative. Choosing the agent shape when the problem wanted a simpler one is the most common and most expensive mistake we see.

That is why we build production AI, end to end and treat production AI agents as one capability inside it, not as the product itself.

How to tell if your use case needs one

Four questions, in order. Does a human make this decision repeatedly, at volume? Does the decision require pulling information from more than one place? Is there a real consequence you can measure in your funnel or your cost line? And can you write down what a wrong answer looks like?

If you answer yes to all four, an agent is probably the right shape. If you cannot answer the fourth one, stop. If you cannot define failure, you cannot evaluate the agent, and an agent you cannot evaluate will not survive its first month in production.

Where to start

Not with a platform decision. Start by naming one decision, writing down the rule a good human applies, and defining what a wrong answer costs. That document is worth more than a model selection.

From there, a functional pilot is a four to six week exercise, and an agent running in production is typically eight to sixteen weeks depending on integration depth and compliance. The long pole is almost never the model. It is the integration and the evidence that the thing behaves.