The Agents Guide

An agent is an AI that is given a goal and takes its own steps to reach it, using tools, while you supervise.

A plain chatbot answers and stops. You ask, it replies, the turn is over. A copilot rides along while you work, suggesting the next line while you stay in the driver's seat. An agent is the step past both. You hand it a goal like "sort these invoices and flag the ones that look wrong," and it works out the steps and does them, checking with you when it matters.

The difference is who takes the steps. With a chatbot, you do. With an agent, it does, and you watch.

Under the hood an agent runs a simple cycle called the agent loop. It looks at the situation, decides the next move, does one thing, then looks again at what changed.

Perceive, plan, act, observe, and around again until the goal is met or it gets stuck. That loop is the whole engine. A chatbot does one pass and stops. An agent keeps going, using what just happened to decide what to do next.

This is why agents can handle messier jobs than a single answer ever could. They get to react, not just respond.

On its own an LLM can only produce text. It cannot send an email or read a file. It does those things through tool use, where the model is handed a set of actions it is allowed to take and decides when to call one.

The plumbing for this is function calling. You describe the tools available, like "search the database" or "create a calendar event," and the model picks the right one and fills in the details. The tool runs, the result comes back, and the agent keeps going.

Tools are what turn a clever talker into something that can actually get work done. They are also where the real risk lives, which is why the rest of this guide spends so much time on supervision.

An agent has two kinds of memory, and they do different jobs.

Short-term memory is what it is holding right now for the task at hand, the recent steps and results. It lives in the context window and it clears when the job ends, like notes on a whiteboard.

Long-term memory is what it keeps across sessions, like your preferences or facts it learned last week. This is usually stored outside the model and looked up when needed. Short-term is the whiteboard. Long-term is the filing cabinet it walks over to.

An agent does not have to wait for you to type. A trigger is the event that wakes it up and sets it running.

A trigger can be a clock, like "every morning at eight." It can be an event, like "a new email landed" or "a customer filled out the form." Once an agent is wired to a trigger, it runs on its own, which is the point. It is also exactly when you want strong limits in place, because nobody is watching each run in real time.

The single most important habit with agents is deciding where a person has to sign off. That is the human-in-the-loop idea, where the agent pauses and waits for your yes before it does something that matters.

A close cousin is human-on-the-loop, where the agent acts on its own but a person watches and can step in. The rule of thumb is simple. The more expensive or hard to undo an action is, the more you want a human gate in front of it. Reading data, low risk. Sending money, get approval.

The tighter rules that enforce all this, the lines an agent is never allowed to cross, are called guardrails.

Before you point an agent at a job, run it through a quick test. Good agent work tends to share four traits.

The goal is clear and you can tell when it is done. The steps lean on tools and data the agent can actually reach. A wrong move is cheap to catch and undo, or there is a human gate before anything costly. And the task repeats often enough to be worth setting up.

When a job has all four, an agent shines. When the goal is fuzzy, the stakes are high, and every run is different, you are usually better off keeping a person in the chair.

For anything beyond a couple of steps, a common and reliable design is planner-executor. One part of the system makes a plan, and another part carries it out step by step.

Splitting the thinking from the doing helps a lot. The planner can lay out the whole approach before any action is taken, which is easier to review. The executor just works the list. If something breaks, you can see whether it was a bad plan or a bad step, and fix the right one.

Sometimes one agent is not the best shape for the job. A multi-agent system splits the work across several agents, each with a narrow role, like a small team.

One might gather information, another draft, another check the work. Coordinating them, deciding who does what and in what order, is called orchestration. This can be powerful for big jobs, but every extra agent is another thing that can go wrong, so reach for it only when one agent genuinely is not enough.

An agent should only be able to touch what its job requires, and nothing more. A sandbox is a walled-off space where it can run without reaching the rest of your systems.

Pair that with tight permissions. If an agent only needs to read a calendar, do not also hand it the keys to send payments. This matters even more once an agent reads outside text, because a hidden instruction buried in a web page or email can try to hijack it, a trick called prompt injection. The safe assumption is that anything an agent ingests might be trying to steer it, so the less it is allowed to do, the less damage a bad instruction can cause.

Agents will sometimes get things wrong, so you need to be able to see what happened and recover cleanly. Being able to watch an agent's steps, inputs, and decisions is called observability.

Good observability means that when a run goes sideways, you can trace exactly where, instead of guessing. Pair it with sensible recovery, like retrying a failed step, stopping after too many errors, and never leaving a job half done in a way that is hard to clean up. Plan for the bad run, not just the good one.

Agents are not always the answer, and reaching for one too early is a common mistake.

If a task runs once, a person can just do it. If plain software with fixed rules already handles it, that is simpler and more predictable. If the goal is vague or changes every time, an agent will flail. And if a wrong action is expensive and there is no good way to gate or undo it, the risk may not be worth it.

The honest test is whether the autonomy actually buys you something. If supervising the agent is as much work as doing the task, skip it.

Pro Tip Start an agent with its hands tied. Give it read-only access and a human approval gate on every real action, then watch it work for a while. Loosen the leash one notch at a time, only after it has earned your trust on the easy cases. It is far cheaper to grant power slowly than to claw it back after something breaks.

A few shapes that work well in practice.

An inbox triage agent that reads incoming email, sorts it, drafts replies for routine ones, and leaves anything sensitive for you to approve. A research agent that takes a question, searches several sources, and hands back a summary with links you can check. A monitoring agent that watches a system and pings a human the moment something looks off.

Notice the pattern in all three. The goal is clear, the agent uses tools, and a person stays in the loop where it counts. That is the recipe. Give it a real job, the tools to do it, and a clear line it cannot cross, and an agent earns its keep.