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:

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.