What is an AI agent? The agentic loop, explained

Every vendor now sells an 'AI agent,' and the word has been sanded down until it means nothing. So here is the version that actually helps you build one.

An agent is the same Claude you already use, handed a goal, a few tools, and permission to act on its own and check its own work. That last permission is the whole story, the useful part and the part that bites.

An agent is a loop, not a smarter chatbot

A chatbot does one turn. You ask, it answers, it forgets. An agent runs a loop: you give it a goal, it looks at the current state, decides the single next action, takes that action with a tool, reads what came back, and decides again. It keeps going until the goal is met or it hits a stop you set. People write the loop as perceive, reason, act. The plain version is look, do, look again.

The model in the middle is the same one in your chat window. Nothing about the weights changed. What changed is that you stopped asking it for words and started letting it take steps. An agent is a posture, not a different product.

Agent vs copilot vs workflow

Three words get used interchangeably and should not. A copilot waits for you at every step: it suggests, you accept, it suggests again, and you are still doing the work with better autocomplete. A workflow is a fixed set of steps someone wired up in advance, no judgment, the same path every time. An agent sits between them: it decides the path as it goes, takes the steps itself, and comes back when it is done or stuck.

The move that matters for you is copilot to agent. With a copilot you are in the chair for every keystroke. With an agent you go up a level: you set the goal and the guardrails, it does the doing, and your job becomes approving the result instead of producing it. That shift, from doing the work to deciding on the work, is the entire reason agents are worth the trouble.

The three parts every agent has, and the fourth that makes it compound

Strip an agent to its frame and you find three parts. A goal, stated clearly enough that the agent can tell when it is done. Tools, the specific actions it is allowed to take. And the loop that runs the model against the goal, one action at a time, until it finishes. Remove any one of the three and you are back to a chatbot.

The fourth part is memory, and it is what turns a clever single run into something that compounds. There is memory in the moment, the context it is holding right now, and memory across runs, a durable record it reads at the start and writes at the end. Without the second kind, your agent re-learns the same account every Monday and re-makes decisions you already made.

Tools are how an agent touches the world

On its own the model can only produce text. Tools are what let it do something: read a webpage, query your CRM, drop a draft in Slack, write a row to a database. You define the tools it can call and, just as important, the ones it cannot. Model Context Protocol is the standard way to plug those tools in without hand-wiring each one, which is its own piece on this hub.

The line that keeps you safe here is read versus write. A read-only agent that pulls an account, scores it, and hands you a summary is almost impossible to get in trouble. A write-enabled agent that can change a budget or email a customer is where the value is and where the risk lives. Earn the write access on purpose, not by accident.

Memory is the part that makes it more than one good turn

Give an agent a place to write down what it did and why, and read it back next time, and the thing stops being a party trick. The account it researched last week, the change you rejected on Monday, the fact that this prospect already got the case study, all of it lives in a log the agent consults before it acts. That is the difference between an agent and a very fast intern with amnesia.

How you steer that memory, what stays in the live context versus what gets written down for next time, is worth its own read in the context and memory piece.

The dangerous part is the action, not the reasoning

Here is the scar. I once let an agent write to a live system off a number that turned out to be stale, and it did exactly what I told it to, fast, to a real record. The reasoning was fine. The action was wrong, and there was nothing sitting between the decision and the consequence. That gap is where agents bite.

So you build three boring seatbelts before you turn one on. An approval gate, where the agent proposes and a human signs off, and the sign-off is the only thing that authorizes an irreversible action. A cap, so no single action can swing a number past a limit without a second confirmation. And a dry run, a mode that prints exactly what it would do and touches nothing. All three are unglamorous, and all three are what make an agent safe to leave running.

What an agent actually looks like in GTM

Concretely, on a go-to-market team: an inbound lead lands, and an agent enriches it, scores it against your ICP, writes the record to the CRM, and pings the right rep in seconds, before a human touches it. Or every Monday an agent reads your ad account by layer, ranks the changes worth making, and waits for your one-line approval before it executes any of them. Same loop every time: look, propose, act on what you approved, log it.

That is the shape worth building toward: a system that does the reading and the doing while you keep the deciding, not a robot that replaces the rep. The use cases on this site are that pattern made specific, from inbound routing to a LinkedIn ads agent that acts only on what you sign off.

Frequently asked questions

Sources & further reading

• Anthropic: Building effective agents
• Claude Docs
• Model Context Protocol

Claude ships fast. This page was last reviewed Aug 22, 2026; verify time-sensitive details against the official docs above before relying on them.