# AI Agents, Explained > An agent is a chatbot that can act: it plans, uses tools, looks at the result, and tries again. Here is the loop, the power, and where to keep it on a leash. --- # AI Agents, Explained You have used a chatbot. You type a question, it types an answer, done. An agent is the next step: instead of only telling you what to do, it goes and does it. It books the meeting, edits the file, runs the search, files the ticket. Same underlying model, but now it has hands. That one change - giving the model tools and a goal instead of a single question - is what people mean by "agent" or "agentic AI." The word gets thrown around loosely, and vendors slap it on anything, so this guide cuts to what is actually different and why it matters for the work you do. You do not need to write code or understand how the model was built. You need a clear mental picture of what these things are good at, how they fail, and how to keep them from doing something dumb at scale. Three phases. First, what actually separates an agent from a chatbot: access to tools and the freedom to use them toward a goal. Second, the loop at the center of every agent - act, observe what happened, adjust, repeat - and why that loop is both the source of the power and the source of the trouble. Third, the part most people skip until it bites them: autonomy and guardrails. How much rope to hand an agent, when to require a human's approval, and how to box it in so a wrong turn stays cheap. By the end you will be able to look at any "AI agent" product and tell what it can really do, where it will trip, and how to use it without getting burned. --- # From Answering to Doing Picture two versions of the same assistant. The first one you already know. You ask, "What's a good subject line for my launch email?" It writes you three options. Useful, but the email still sits in your drafts. The assistant produced words and stopped. Everything after that is on you. The second one you ask, "Send the launch email to my newsletter list, but hold it for my approval first." It pulls your list from the email tool, drafts the message, schedules it, and shows you a preview before anything goes out. It did not only suggest - it acted in the real world. That gap is the whole ballgame. A chatbot turns your words into more words. An agent turns your words into actions. The model in the middle can be identical. What changed is that the second one was handed tools and pointed at a goal. ## What "tools" actually means "Tool" sounds technical. It is not. A tool is anything the agent can reach out and use besides its own text. A few you will run into: - **Search the web** and read the pages it finds. - **Read and write files** on your computer or in a shared drive. - **Call another app** - your calendar, your CRM, your email, your project tracker - through a connection. - **Run a small program or query** - for example, pulling numbers from a spreadsheet or a database. When you hear that an agent has "access to your Google Drive" or "can use the Slack integration," that is tools. The agent does not magically know your files; someone connected a tool that lets it look. A common way these connections get described today is **MCP** (Model Context Protocol) - a shared standard for plugging tools into an agent. You do not need to understand the plumbing. You only need to know: no tool, no action. The list of tools an agent has is the exact list of things it can do. Anything not on that list, it cannot touch. This is also your first safety lever, and we will come back to it: the fastest way to limit what an agent can do is to limit which tools it can reach. ## The second ingredient: a goal, and room to pursue it Tools alone are not enough. A vending machine has a "tool" - it dispenses snacks - but it only does the one thing you press. An agent gets a goal and the freedom to decide which tools to use, in what order, to get there. Say you tell it: "Find out which of our top 20 customers haven't logged in this month, and draft a check-in email to each." A chatbot would ask you to paste the data. An agent figures out the steps itself: query the usage data, sort it, cross-reference the customer list, then write the emails. You described the *destination*. It chose the *route*. That freedom is exactly what makes agents feel different - and exactly why they need a leash. The model is deciding, in the moment, what to do next. Most of the time that is helpful. Sometimes it reaches for the wrong tool, misreads a result, or takes a step you never wanted. The same freedom that lets it handle a messy task without hand-holding lets it wander off. ## Why this matters for real work Most genuinely useful work is not a single answer. It is a chain: look something up, decide based on what you found, do the next thing, check it worked. That chain is precisely what a plain chatbot cannot do and an agent can. Think about the difference between these two requests: | You ask | Chatbot | Agent | |---|---|---| | "Summarize this contract." | Reads the text you paste, returns a summary. | Same - no tools needed. | | "Pull last quarter's invoices and flag any over 30 days late." | "Please paste the invoices." | Opens the accounting tool, fetches them, applies the rule, hands you a list. | | "Book a 30-min call with Priya next week." | "Here's a template email to send." | Checks both calendars, finds a slot, sends the invite. | The first row needs no tools. The other two are only possible because the agent can reach out and do things. That is the line. When something is described as "agentic," ask one question: *what can it actually touch, and how much does it decide on its own?* The answer tells you both how useful it will be and how carefully you need to watch it. In the next phase we get to the engine that makes all of this run - the loop the agent spins through every time it acts. --- # The Act-Observe Loop Strip away the branding and every agent runs the same cycle. It is worth burning into your memory, because once you can see the loop, you can predict how an agent will behave and where it will break. Here it is: ```mermaid flowchart LR A[Look at the goal] --> B[Plan one step] B --> C[Act: use a tool] C --> D[Observe the result] D --> E{Done?} E -- No --> B E -- Yes --> F[Stop and report] ``` Plan a step. Do it. Look at what came back. Decide if you are done. If not, plan the next step using what you learned. Repeat. That is the engine. A chatbot does one pass and stops. An agent loops. ## Walking through one loop Say you ask an agent: "Find the cheapest flight from Boston to Lisbon in October and put it on my calendar as a placeholder." ```text Goal: cheap BOS→LIS flight in October, add to calendar Step 1 - Plan: I need flight prices. Use the flight-search tool. Step 1 - Act: search BOS→LIS, October. Step 1 - Observe: got 12 results, cheapest is Oct 14, $480. Step 2 - Plan: confirm it's a real bookable fare, not a glitch. Step 2 - Act: open the Oct 14 listing. Step 2 - Observe: still $480, one stop, looks legit. Step 3 - Plan: add a placeholder to the calendar. Step 3 - Act: create event "Possible LIS trip" on Oct 14. Step 3 - Observe: event created successfully. Done? Yes. Report back to the user. ``` Notice what happened. The agent did not plan all three steps up front and march through blindly. It planned *one* step, looked at the result, and the result shaped the next step. If the search had returned nothing, step two would have been "try different dates," not "open the listing." The loop lets the agent react to reality instead of following a fixed script. ## Why the loop is the whole point This is what makes agents feel smart. Real tasks are full of surprises - a file is missing, a login expired, a number looks wrong. A rigid script snaps the moment reality differs from the plan. The loop bends. Each pass, the agent sees what actually happened and adjusts. That is why an agent can muddle through a messy task that you could not have scripted in advance: it is not following your steps, it is finding its own, one at a time. It is also why agents can *recover*. Ask it to save a file and the folder does not exist? A good agent observes the error, plans a new step - create the folder - and tries again. You did not tell it to. The loop did. ## Why the loop is also where it goes wrong The same loop that gives an agent its power gives it three classic failure modes. Watch for all three. **It misreads the result.** The agent observes the wrong thing - thinks a step worked when it failed, or grabs the wrong number from a page - and then confidently builds the next step on a bad foundation. One misread early can poison everything after it. **It loops without making progress.** It tries something, it fails, it tries almost the same thing, fails again, and again. Without a stop condition it can churn - sometimes burning real money on tool calls - getting nowhere. This is why serious agents have limits: a maximum number of steps, a budget, a timeout. When you hear an agent "got stuck in a loop," this is it. **It decides "done" too early or too late.** That `Done?` check is a judgment call the model makes, and it can be wrong. Stop too early and it hands you half a job and calls it finished. Stop too late and it keeps "improving" things you never asked it to touch. None of these mean agents are useless. They mean the loop is doing exactly what it does - making decisions step by step - and sometimes a step is wrong. The fix is not to trust the loop blindly. It is to watch the steps and put limits around them. ## What this means for you When you use an agent, you are not getting one answer you can glance at and accept. You are getting a *chain of decisions*, any link of which could be off. So: - **Read the steps, not only the final answer.** Most agent tools show you what it did. That trace is where you catch the misread before it matters. - **Give it a clear finish line.** "Draft the email and stop" beats "handle the email." A vague goal makes the `Done?` check a guess. - **Expect limits, and want them.** Step caps and budgets are not the tool being weak. They are the seatbelt. The loop is the heart of every agent. Once you see it running, the next question is obvious: how much should you let it do on its own before a human steps in? That is the next phase. --- # Autonomy and Guardrails You now know what an agent is and how its loop runs. The last question is the one that decides whether an agent helps you or hurts you: how much do you let it do without asking? Call it the autonomy dial. Turn it all the way down and the agent asks permission before every action - safe, but barely faster than doing it yourself. Turn it all the way up and it runs the whole job untouched - fast, but a single wrong step can do real damage before you notice. The skill is not picking one setting forever. It is matching the dial to the stakes. ## The one rule that decides everything Before anything else: **how bad is the worst step this agent could take?** That question, not how clever the agent is, sets how much rope it gets. Reversible and cheap mistakes - drafting text, sorting a list, searching the web - deserve a long leash. Irreversible or expensive ones - sending email to thousands of people, deleting files, moving money, posting publicly - deserve a short one, no matter how good the agent is. A useful split: | Stakes | Examples | How much autonomy | |---|---|---| | Low - reversible, private | Drafting, summarizing, searching, sorting | Let it run; review the output. | | Medium - visible or annoying to undo | Editing a shared doc, scheduling, filing tickets | Let it run, but watch the steps. | | High - irreversible, costly, public | Sending mass email, deleting data, payments, posting | Require approval before the action. | When in doubt, treat it as higher stakes than you think. The cost of an unnecessary approval click is a few seconds. The cost of a skipped one can be your weekend. ## The four guardrails Different tools give these different names, but they come down to four levers. **Permissions - what it can touch.** This is the strongest and simplest control, and it comes straight from phase one: an agent can only use the tools you give it. Do not connect the production database if the task only needs to read a report. Do not grant "send email" if it only needs to draft. The fewer tools on the list, the smaller the blast radius. Set this *before* the agent runs, because it is the one guardrail that does not depend on you watching. **Approvals - the pause before a big move (human-in-the-loop).** The agent does its work but stops and asks before any high-stakes action: "About to send this to 4,000 people - go?" You look, you confirm or you cancel. This is the single most valuable habit with agents. It keeps the speed of automation for the safe 95% of steps and inserts a human exactly at the moment that matters. The phrase you will hear is "human-in-the-loop," and it means precisely this: a person sits inside the loop at the risky step. **Sandboxes - a safe place to make mistakes.** A sandbox is a walled-off copy of the world where the agent's actions cannot escape - a test version of your data, a throwaway folder, a draft that is not published. Let it loop freely there. If it makes a mess, you throw the sandbox away. Many coding and automation agents run this way by default: they work on a copy, and nothing reaches the real thing until you say so. **Limits - caps on how far it can go.** From phase two: a maximum number of steps, a spending budget, a time limit. These catch the agent that gets stuck looping or quietly runs up a bill. Limits do not make the agent smarter; they make its failures cheap and bounded. ## Putting the dial in the right place A way to think about it, from loosest to tightest: ```text Watch after → agent runs fully, you review the result. (low stakes) Watch during → agent runs, you read the steps live. (medium stakes) Approve each → agent pauses before each big action. (high stakes) Sandbox only → agent can't touch the real thing at all. (untrusted / new) ``` You do not have to commit to one. The right move with a new agent, or a new kind of task, is to start tight and loosen as it earns trust. Run it in a sandbox or with approvals the first few times. Watch where it stumbles. Once you have seen it handle that task cleanly a dozen times, you can let it run with a lighter touch - for *that* task. A different task starts tight again. ## A word of straight talk Agents are genuinely useful and getting better fast. They are also not trustworthy in the way a careful colleague is. They will, on occasion, do something confident and wrong - misread a result, take a step you did not intend, declare a half-done job finished. This is not a flaw that the next version fully erases; it is the nature of a system that decides step by step in a messy world. So the guardrails are not training wheels you discard once you are "good at it." They are how anyone, including the people building these things, runs agents responsibly. Give them the smallest set of tools the job needs. Require a human at the steps that cannot be undone. Box them in when the stakes are high or the task is new. Do that, and an agent becomes what it should be: a fast, tireless helper that you keep on a leash sized to the danger - long where mistakes are cheap, short where they are not.