How Agents Use Tools: The Loop That Makes Everything Work

The most important thing to understand about AI agents is the loop. Everything else, the memory, the planning, the multi-agent coordination, is built on top of one basic cycle that happens over and over. Once you see this clearly, agentic systems stop feeling like magic and start feeling like something you can actually design.

What a tool is

In the context of AI agents, a tool is a function the language model can choose to call. When the model decides it needs information or needs to take an action, it names a tool and provides the inputs. The tool runs, returns a result, and the model reads that result and decides what to do next.

Tools are how an agent reaches beyond text. Without tools, the model can only write. With tools, it can search the web, read files, write files, execute code, call APIs, send messages, look up data, and anything else you define a function for.

A few examples of what tools look like in practice:

• search_web(query) - searches Google or another engine and returns the top results
• read_file(path) - opens a file and returns its contents
• write_file(path, content) - saves content to a specified file
• call_api(url, method, body) - makes an HTTP request and returns the response
• run_code(code, language) - executes a snippet and returns the output
• send_email(to, subject, body) - sends an email
• query_database(sql) - runs a query and returns rows

These are not hypothetical. Each of these is a real tool type used in production agent systems today.

The request-action-observe loop

Here is the core loop, step by step:

1. The model receives a goal For example: "Research the top three competitors to Notion and summarize what each one does well."

2. The model decides what to do first It looks at the goal and the tools available. It decides to call search_web with a query like "Notion competitors 2024 comparison".

3. The tool runs The search function actually runs and returns a list of results: titles, URLs, short descriptions.

4. The model observes the result It reads the search results and decides what to do with them. It picks two or three pages that look relevant and decides to read each one using read_url.

5. The loop continues For each page, the model reads it, extracts what is useful, and keeps track of what it has learned. After reading three pages, it has enough to write the summary.

6. The model produces a final output It writes the comparison and returns it to you.

The whole thing took six or seven steps. None of them required you to do anything after giving the initial goal. That is the loop.

Why the loop matters so much

The loop is what separates a capable agent from an expensive autocomplete.

A model that just responds to your question can only work with what you gave it. A model running in a loop can go get more information, try something, see if it worked, and adjust. It is the difference between giving someone a question and giving someone a job.

The quality of an agent depends almost entirely on two things: the quality of the model doing the reasoning, and the quality and breadth of the tools available to it.

Common tool categories

Here is a map of the tool categories that appear most often in real agent builds:

Information retrieval Web search, URL fetching, database queries, document reading, API calls for data. These are the tools that let an agent answer questions it was not trained to answer.

File and document operations Reading files, writing files, creating and editing documents, moving and organizing folders. These are among the most useful tools for everyday automation tasks.

Code execution Running Python, JavaScript, or shell commands. This is what lets an agent do calculations, transform data, run tests, or call system-level operations.

Communication Sending emails, posting to Slack, writing to a Notion page, creating a calendar event. These are the tools that let an agent take visible action in the world.

Memory and storage Writing to a vector database, querying stored memories, updating a knowledge base. These are how agents remember things that would not fit in a single context window.

External services Calling a payment processor, a CRM, a shipping API, a weather service. These are what make domain-specific agents possible.

How you define tools

When you build an agent, you write a short description of each tool along with its name and the inputs it expects. This description is what the model reads to understand when to use the tool.

A good tool description answers three questions:

• What does this tool do?
• When should I use it?
• What do I give it and what do I get back?

Here is an example of a well-written tool definition:

Name: search_web
Description: Searches the web for current information on a topic.
             Use this when you need facts, recent news, or information
             that may not be in your training data.
Inputs: query (string) - the search terms to use
Returns: A list of results, each with a title, URL, and short description.

And one that is too vague to be useful:

Name: search
Description: Searches things.
Inputs: q
Returns: results

The model uses your descriptions to decide when and how to use each tool. Vague descriptions lead to poor tool selection. Clear descriptions lead to an agent that reaches for the right tool at the right moment.

Thinking about tool design before you build

Before you define any tools, ask two questions.

What does the agent need to know that it cannot know on its own? Current prices, the content of a specific document, the result of a calculation, the status of an order. Each answer becomes a retrieval tool.

What does the agent need to do in the world? Send a message, write a file, create a record, run a process. Each answer becomes an action tool.

Start with the minimum set of tools that lets the agent complete its goal. You can add more later. An agent with three well-defined tools will outperform one with ten poorly-defined ones every time.

A quick note on trust

Tools take real actions. A tool that sends an email will send a real email. A tool that deletes a file will delete a real file. This is obvious but worth sitting with before the next modules, because it shapes how you think about testing, scope, and safety.

That topic gets its own module at the end of this course. For now, just hold this in the back of your mind: every tool you give an agent is a capability you are choosing to hand over. Design accordingly.