Agents Explained: Tools, System Prompts and the Thought-Action Loop

Modern AI agents rest on a short list of ideas: tools, a system prompt, and a repeating cycle of thinking, acting and observing. Once those pieces click, most agent frameworks look like variations on one theme. The sections below build the picture from the ground up, starting with what an agent actually is.

What an agent is

An agent is a system in which an AI model works with its surroundings to complete a particular task. It blends reasoning, planning and the carrying out of actions, usually through external tools. Most agents are driven by an LLM, although a vision-language model could fill the same role.

Your chat app forgets everything

Here is a fact that surprises many people: when you chat with ChatGPT or a similar assistant, no conversation exists inside the model. It stores nothing, tracks no ongoing state and keeps nothing between your messages. Each time you press send, the whole exchange so far is glued into one long block of text, and the model reads that block from the beginning.

Picture this exchange:

conversation = [
    {"role": "user", "content": "I need help with my order"},
    {"role": "assistant", "content": "Could you provide your order number?"},
    {"role": "user", "content": "It's ORDER-123"},
]

A tidy list of turns with roles is what you see and what developers handle in code. The model never receives a list, though. Before anything reaches it, the turns are flattened and joined into a single sequence of text, and its only job, same as always, is to predict the next token given everything before it.

No special "remember this" step exists. When the model seems to recall your order number, that isn't memory. The number is simply still sitting in the text it is reading at that moment.

Tools

A tool is a function, ideally with one clear purpose, that is handed to the LLM. Typical examples include:

• searching the web
• generating images
• retrieving documents
• calling an API

A good tool extends what the model can do. It needs these parts:

• a text description of what the function does
• a callable, meaning the code that performs the action
• typed arguments
• optionally, a typed output

How a tool actually gets called

The key point is that an LLM can't operate any external tool directly. Text goes in and text comes out, nothing more. Saying a model "has access to tools" really means it has learned to write down a tool call in text. Ask about the weather in Paris, and the model doesn't fetch a forecast. It emits a structured message saying the weather tool should run.

An agent layer sits between the user and the model. It spots that message, runs the tool, collects the result and adds it to the conversation before sending everything back to the model. With that extra context, the model writes a normal answer. The user feels as if the model reached the weather service itself, yet the agent did all the orchestration behind the curtain.

A small example

For illustration, take a calculator tool that does just one thing, multiplying two integers:

def multiply(a:int, b:int):
  "Multiply two integers"
  return a * b

Turning a function into a tool

The Hugging Face transformers library offers a @tool decorator that wraps an ordinary Python function so an agent can understand it. First comes the import:

from transformers import tool

Then the decorated function:

@tool
def multiply(a: int, b: int):
    """Multiply two integers."""
    return a * b

Behind the scenes, the decorator collects metadata:

• the function's name
• its description
• argument names
• argument types
• the return type

That metadata is later placed into the prompt, which tells the model how to use the tool correctly.

Looking at a tool

After decoration, a tool can describe itself in text:

print(multiply.to_string())

The printed output contains details along these lines:

Tool Name: multiply

Description:
Multiply two integers.Arguments:
- a (int)
- b (int)

This structured description is precisely what the agent shows the model. The LLM reads it like any other text and decides whether the tool would help with the user's request.

The agentic workflow

An agent works in a repeating cycle: it thinks (Thought), acts (Action) and then observes (Observation).

1. Thought. The LLM portion of the agent decides what to do next.
2. Action. The agent calls tools with the chosen arguments.
3. Observation. The model considers what the tool returned.

The agent stays in this loop of think, act, observe until its objective has been met.

The system prompt

A system prompt is a set of instructions delivered to a model before any user message. It sets out behavior, role, constraints and goals for the entire conversation.

When a user writes something, the model sees more than that text. It typically receives something shaped like this:

<System Prompt>

You are a helpful programming assistant.
Always explain concepts before showing code.
If the user asks for unsafe code, refuse politely.

<User>

Explain binary search.

The system prompt outranks the user's prompt. Suppose it says to always answer in English and the user asks for French. The model will generally side with the system prompt, unless the application deliberately lets user requests override it.

An agent's system prompt goes further and describes tools and the cycle itself:

You are an AI assistant that can answer user questions.

You have access to the following tools:

Tool: search_web
Description:
Searches the web for up-to-date information.

Arguments:
- query (string)

Tool: calculator
Description:
Evaluates mathematical expressions.

Arguments:
- expression (string)

If a user's question requires current information, use search_web.
If a calculation is required, use calculator.
Otherwise, answer directly.

Three things are defined in that system message:

• how the agent should behave
• which tools it can use, described the way the previous section showed
• the Thought, Action, Observation cycle, built into the model's instructions

Each of the three stages deserves a closer look.

Thoughts

Thoughts capture the agent's internal reasoning and planning as it works toward the task. Two common styles are:

1. chain-of-thought (CoT)
2. ReAct (reasoning plus acting)

Chain-of-thought is a prompting method that nudges a model to work through a problem step by step before it commits to a final answer. The reasoning stays internal, which suits logic and math problems that need no outside tools.

ReAct is a method that also asks for step-by-step thinking but mixes actions, such as tool calls, in between the reasoning steps.

Both let an LLM reason through problems gradually. The distinction is that CoT depends only on what the model already knows, whereas ReAct pairs reasoning with actions. That lets the model use outside tools, collect fresh information and keep reasoning from the results, a better fit for dynamic, real-world work that touches external systems.

Actions: from thinking to doing

Actions are the steps an agent takes to interact with its environment. A customer-service agent might pull up customer data, suggest support articles or hand a case to a human.

A text generator manages to trigger real tools through a straightforward pattern known as stop and parse. The model never performs anything itself. It produces a structured request describing what should happen, and the agent carries it out on the model's behalf.

Under the hood this is the same cycle as before. The model reasons about the task, outputs an action such as a weather API call, and stops. The agent detects the action, runs the matching tool and returns the result as an observation. Equipped with it, the model either keeps reasoning, takes another action or gives the final response.

Historically, actions were expressed as function calls or JSON objects naming a tool and its arguments. That works but gets clumsy when a workflow needs many tool calls. Code agents take another route: instead of describing actions in JSON, the model writes executable Python. Loops, conditions, variables and several tool calls can then share one block of code, which is more expressive and more efficient for complicated tasks.

The traditional JSON form looks like this:

{
  "tool": "get_weather",
  "arguments": {"location": "Tokyo"}
}

A code agent writes a runnable snippet instead:

# The agent writes actual Python code as its action
cities = ["Tokyo", "Paris", "New York", "London", "Sydney"]
temps = [get_weather(city) for city in cities]
avg_temp = sum(temps) / len(temps)
print(f"Average temperature: {avg_temp}")

Observations: feedback from each action

Reasoning and acting are only half the story. After acting, an agent has to understand the outcome, and that's the role of an observation: the feedback received once an action has run. It may be a web search result, an API reply, the output of a Python program or even an error message. Whatever it is, it becomes new information for choosing the next step.

The flow is simple. The agent produces an action, the framework executes it, and the output is appended to the conversation as an observation. The LLM reads the updated context and keeps going. With enough information it gives the final answer. If not, it plans another action.

Observations needn't be successes. When a call fails, with a 404 Not Found from an endpoint or a Python TypeError from generated code, that failure is still valuable. The error message shows the agent what went wrong, so its next action can correct course instead of repeating the mistake.

This ongoing loop is what makes agents adaptive. Instead of depending only on pretrained knowledge, they gather new facts, learn from outcomes and refine their approach until the task is done.

Putting the pieces together

Agents can look like a brand-new paradigm, but they come from a handful of simple ideas combined. A language model reasons about a problem, a system prompt shapes its behavior, tools extend it beyond text, actions connect it to the outside world and observations supply feedback so it can adapt.

Grasping these building blocks, and noticing how little magic each one contains, is the first step toward building your own agents. Coding assistants, research copilots and autonomous workflows all rely on the same Thought, Action, Observation cycle. From here, the natural next step is to implement a first agent with the Hugging Face ecosystem.