What Is an AI Agent and How Does It Work

What Is an AI Agent and How Does It Work

An AI agent is a model that is allowed to use tools, remember what it already did, and keep going until the job is done or a person stops it. A chatbot answers and waits. An agent acts inside permissions you set, and it stops for a human before it sends, pays, posts, or deletes.

I write this for the operator or the executive who has been in a demo and is now being asked what, exactly, the company would be buying. I build these loops. The pages that rank for the phrase are mostly written as a developer tutorial. Tool names matter to the person wiring the loop. They are not the question in the room. The question in the room is what the thing does when nobody is watching the screen.

This page is the explainer. How to build an AI agent for a business is the build order, and I will not repeat it here. Agentic workflows is the production version of the same loop, the one that reads a system you already run and writes back under a named owner. If you want the test I use before either of those, what an agentic workflow is is the sibling. A named owner, a system of record, a human gate. This page stays on the parts of the loop, in plain language.

What is an AI agent, in one sitting?

An AI agent is a worker with a narrow job, a short list of tools, and a stop. You give it a goal that fits in a sentence. It decides a next step. It uses a tool to look something up or to draft something. It keeps the result of that step. It decides again. It stops when the job is done, when it is unsure, or when the next step would commit the business.

That is the whole object. It is not a person. It is not a department. It is not "AI" as a mood. If you cannot name the job in a sentence a manager can repeat, you do not have an agent yet. You have a login.

I use one picture with operators. An exception queue. A case arrives. A person used to open four systems, draft a note, and decide whether the customer should be contacted. An agent can do the opening and the draft. The decision to contact the customer stays with the person, until you have watched the draft be right often enough to argue about moving the gate. The agent is the loop. The gate is still yours.

A copilot that only drafts when you ask is a chatbot with a document open. A saved automation that always clicks the same three buttons is a script. An agent is the thing in the middle. It chooses a tool for this case, and it can be told to stop. If a vendor cannot show you the choice and the stop, they are selling one of the other two.

How does an AI agent work?

It works as a loop. Five parts. I will walk them in the order I have to explain them to a board, not in the order a framework diagram prefers.

1. The model looks at the job and picks a next step.
2. A tool does something the model cannot do by guessing. A lookup. A draft. A write you have allowed.
3. Memory holds what already happened on this job, so the next step is not amnesia.
4. Permissions cut the tools and the data down to what this agent is allowed to touch.
5. A human approval sits on any step that sends, pays, posts, or deletes.

Then the loop either finishes or goes back to the model with the new fact. That return is the part demos hide. A chatbot has no return. It answered. An agent that cannot take the result of a tool and decide again is a chatbot that called one function and stopped, which is a fine product, and it is not an agent.

The loop is also where the time goes, and the time is not where people guess. On a wealth advisory platform we build, one heavy turn took 148.6 seconds before we changed the design. 86 seconds were the model. 56.5 seconds were tools. Retrieval was under 1 second. The build page holds the budget and the test. The lesson here is the split. "The AI" was not one blob. If you cannot see model time apart from tool time, you will blame the wrong part when someone is still waiting.

What does the model actually do?

The model reads the job, the memory, and the tool results, and it proposes the next step in text. That proposal can be a sentence to a person, or a request to call a tool. The model does not contain your order system. It does not contain last quarter's close. It contains a guess, a very fluent one, conditioned on what you just handed it.

I say that in operating reviews because the failure mode is confidence. The model will describe a customer, a balance, or a policy with the same tone whether the tool returned a row or the tool was never called. Your defense is not a smarter adjective in the prompt. Your defense is the rest of the loop. No tool result, no factual claim. No permission, no tool. No approval, no send.

The model wanders when the job is vague. "Help the team with email" is not a job. It will invent a scope, and the scope will be larger than you wanted, because larger sounds helpful. Give it the exception queue. Vault the data before you chase agentic depth is what I do when the model is fluent and the rows under it disagree. Fluency on a split source is how a wrong number becomes the number people repeat.

What are tools, in operator language?

Tools are the hands. They are the lookups and the writes you explicitly allowed. Open the order. Read the ticket. Draft the reply. Create the draft invoice. They are not a personality. They are functions with names, inputs, and outputs a person can inspect.

A long tool list feels capable in a sales meeting. In production it is how a single question spends a minute calling things the question did not need. I have watched that. The retrieval was fine. The tools were the turn. Ask for the list. If it includes send, refund, post, or delete, those are actions, not tools you leave on for a demo. A tool may draft the email. It may not send it. A tool that finishes the action has removed the human from the loop.

What does memory mean, and what should it not remember?

Memory is the scratchpad for this job. The case so far. The tool results so far. The draft so far. It is how the agent avoids asking the order system the same question every step, and how it avoids contradicting the note it wrote two steps ago.

Memory is not a diary of the company, and it is not permission to keep every customer conversation because the model might find it useful. I separate three stores, because vendors blend them.

The job scratchpad dies with the job, or lives on the case you already keep. That is the memory an agent needs. The system of record is the order, the ledger, the chart. The agent may read it through a tool. It does not get a second copy in a private store. The leftover prompt is the dangerous one. An instruction someone typed last month is still in the thread, and the agent will treat it as current policy.

On the wealth platform, a product consideration carries a version, a validation flag, a staleness mark, and a sign-off, so an old row is not a current instruction just because it is still stored. Named workspaces keep a second team's files from becoming the first team's context. Memory that crosses a tenant is a leak you will later call a surprise.

What do permissions actually stop?

Permissions are the wall around the tools and the data. They are not a sentence in the prompt that says "be careful." The model will be careful in tone and careless in action, because tone is cheap and the tool will do whatever it is allowed to call.

I want permissions in three sentences an executive can read without a diagram.

Who may start this agent. On the wealth platform, a new investment agent is gated to admins. The demo working is not a reason to put it on every login.

Which records it may see. Matching stays inside one organization. A record from one firm does not resolve against another firm's book. The agent does not get a search box across every tenant because that would be a better demo.

Which tools it may call, and which of those stop before the commit. Read is not write. Draft is not send. A permission that says the integration can do anything the service account can do is how you discover, on a Friday, that the service account could delete. If the answer is "the vendor's default," you have whatever shipped. Ask for the three sentences in writing.

Where does human approval sit?

Human approval sits on the step that commits the business, and on the case the loop has not seen. A loop that asks before every lookup is a queue with a model in front of it. A loop that asks nobody will write the weird case into the system of record and treat it as normal the next morning.

The approval has to be a real control. A typed "yes" in the chat is not one. On a media production pipeline we build, a high-impact step proceeds only when the owner uses a one-time link. The link expires. When it expires, the agent mints a fresh link. It does not accept yes in the chat as a substitute. The click is the record. The transcript is not.

You do not need that exact mechanism on day one. You need the property. A named person. An unambiguous action. A record you can open on Thursday and see who allowed the send. The build page walks how to put that gate on a workflow. A software development retainer is how I keep the same owner on the loop after the workshop. An agent that cannot stop is a script you are afraid to turn off.

What should you ask before you fund one?

Ask these in the meeting where someone wants a budget. Each one maps to a part of the loop. A vague answer means that part is still a demo.

What is the job, in one sentence? If the answer is a platform, you are buying a platform.

Which system does it read, and which system does it write? If the truth still lives in a mailbox, the agent will sound informed and change nothing you can audit.

What is on the tool list? Send, pay, post, and delete are either on the list or they are not. "It depends" means they are on the list.

What may it remember, and for how long? If the answer is "the context window," nobody has decided.

Who can pause it on a Tuesday? If the pause is an email to the vendor, you do not own the loop.

What number will you look at next month? Not a launch. The number the business already tracks for that job. If nobody can name it, you will know that it ran. You will not know whether it worked.

If those answers are solid, go to the build page and run the order. If they are not, do not buy seats to make the meeting feel finished. Bring the job and the system. Start in chat. I will tell you which part of the loop is still a guess.

What this page will not do

I will not give you install steps, a framework ranking, or a repository to clone. That is the wrong altitude for this decision. A chatbot does not become an agent because a menu label changed. The loop is the product. The model is one station in it. A chatbot waits for you. An agent continues. Your job is to decide how far it may continue, and who stops it.

Related reading

• How to build an AI agent for a business
• Agentic workflows for PE and mid-market operators
• Agentic workflows, the production service
• Vault the data before you chase agentic depth
• Software development retainer for mid-market ops