What Is an AI Agent? A Plain-English Guide

// In plain English

An AI agent is a large language model (LLM) that doesn't just answer you — it acts. You give it a goal, and it works toward that goal on its own: thinking about what to do next, using tools, looking at the results, and trying again until the job is finished.

Think of the difference between asking a friend "what's the weather in Tokyo?" and asking them "book me the cheapest flight to Tokyo next week." The first is one answer. The second is a small project: they have to search flights, compare prices, check dates, maybe ask you a clarifying question, then actually do the booking. An agent is built for the second kind of task.

A plain LLM is a brilliant text-completion machine. Ask it something and it produces the most likely next words — see what is an LLM for how that works. It has no hands. It can't check a live calendar, run code, or send an email. An agent wraps that same model in a loop and hands it tools, so the model's words can turn into real actions.

// Why it matters

A chatbot can tell you how to reset a customer's password. An agent can actually look up the customer, reset the password, and email them the confirmation. That gap — between describing an action and performing it — is the whole point of agents, and it's why they became the dominant pattern in AI products.

Before agents, every multi-step task meant a human stitching the steps together. You'd ask the model for SQL, copy it into a database, paste the error back, ask for a fix, and repeat. Agents close that loop automatically: the model writes the query, runs it, reads the error itself, and corrects it without you in the middle. That's the same reason coding agents can edit a whole repository instead of handing you one snippet at a time.

Who should care

• Developers building anything beyond a single question-and-answer call — support bots, research assistants, data pipelines, coding tools.
• Product teams deciding whether a feature needs a simple prompt or a full agent (often it doesn't — more on that below).
• Anyone using AI tools daily — the coding assistant in your editor and the "deep research" button in your chat app are both agents under the hood.

// How it works

At the center of every agent is the agent loop (also called the reason–act loop, popularized by the ReAct pattern). It runs the same handful of steps over and over until the goal is met:

Walk through one turn. The model observes the goal and everything that has happened so far. It reasons about what to do next — sometimes out loud, in a short chain of thought (see chain-of-thought prompting). It then acts by either calling a tool or, if it has enough information, giving a final answer. If it called a tool, the result is fed back in and the loop runs again.

Tools are how the agent touches the world

A tool is just a function the model is allowed to call — search the web, run a SQL query, send an email, read a file. You describe each tool's name, what it does, and what inputs it needs. The model can't run code itself; instead it outputs a structured request like "call get_weather with city = Tokyo", your program runs the real function, and you hand the result back. This mechanism is function calling, and the broader pattern is tool use.

The loop needs a stopping condition so it doesn't run forever. The model stops when it decides the goal is done and returns a final answer — but you also cap the maximum number of steps as a safety net, because a confused agent can otherwise loop indefinitely, burning tokens and money.

Everything the agent has seen so far — the goal, its own reasoning, every tool call and result — lives in the model's context window. That growing transcript is the agent's short-term memory. When it overflows the window, you have to summarize or trim it, which is one of the central challenges of building agents.

// AI agent vs. chatbot vs. workflow

These three terms get blurred constantly. The cleanest way to tell them apart is who decides what happens next.

A chatbot is a single round-trip — useful and often enough. A workflow chains several LLM calls along a path you hard-coded; the model never decides the route, it just does the work at each station. An agent is the only one where the model itself decides the path at runtime, which makes it the most flexible and the least predictable of the three.

// Build a tiny agent

Here's a minimal agent loop in Python using the Anthropic SDK. It gives the model one tool — a calculator — and lets it loop until it produces a final answer. This is the entire core idea of agents in about 40 lines; real frameworks just add error handling, more tools, and memory management on top.

import anthropic

client = anthropic.Anthropic(api_key="sk-...")  # your key here

# 1. Describe the tools the model is allowed to call.
tools = [{
    "name": "calculator",
    "description": "Evaluate a basic math expression like '14 * 3'.",
    "input_schema": {
        "type": "object",
        "properties": {"expr": {"type": "string"}},
        "required": ["expr"],
    },
}]

# 2. The actual function behind the tool (the model never runs this itself).
def run_tool(name, args):
    if name == "calculator":
        return str(eval(args["expr"]))  # demo only — never eval untrusted input
    return "unknown tool"

messages = [{"role": "user", "content": "What is 14 * 3, then minus 7?"}]

# 3. The agent loop: keep going until the model stops asking for tools.
while True:
    resp = client.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=1024,
        tools=tools,
        messages=messages,
    )
    messages.append({"role": "assistant", "content": resp.content})

    if resp.stop_reason != "tool_use":
        # No tool requested -> the model gave its final answer.
        print(resp.content[-1].text)
        break

    # The model asked for a tool. Run it and feed the result back.
    results = []
    for block in resp.content:
        if block.type == "tool_use":
            output = run_tool(block.name, block.input)
            results.append({
                "type": "tool_result",
                "tool_use_id": block.id,
                "content": output,
            })
    messages.append({"role": "user", "content": results})

The shape is universal across providers and frameworks: call the model, check whether it asked for a tool, run the tool, append the result, repeat. The while True loop is the agent. Notice there's no AI magic in your code — the intelligence is entirely in the model's choice of which tool to call and when to stop.

// Where agents show up in the real world

You're probably already using agents without naming them. A few concrete examples:

Two patterns power most of these. Planning lets an agent break a big goal into ordered sub-tasks before diving in — see agent planning. And when one agent isn't enough, you split the work across several specialists in a multi-agent system — for example a "manager" agent that delegates research to worker agents and merges their findings.

Connecting an agent to all these tools used to mean writing custom glue for every integration. The Model Context Protocol (MCP) standardizes that wiring, so a tool server built once works with any MCP-aware agent — think of it as a universal adapter between agents and tools.

// Going deeper

Once the basic loop clicks, the hard parts of real agents come into focus. None of these are solved problems — they're the active frontier of agent engineering.

Reliability and error compounding

Agents fail in a way single prompts don't: errors compound. If each step is 95% reliable, a 10-step task succeeds only about 60% of the time (0.95^10). Long agent runs need guardrails — retries, validation after each tool call, and self-checks where the agent reviews its own work. This is why LLM observability and tracing matter so much for agents: when a 30-step run fails, you need to see exactly which step went wrong.

Context and memory

The transcript that serves as short-term memory keeps growing, and a bloated context both costs more and makes the model worse at finding what matters. Managing this — summarizing old steps, deciding what to keep — is its own discipline, context engineering. For long-term memory across sessions, agents often store and retrieve facts using a vector database, the same retrieval idea behind RAG.

Frameworks vs. building it yourself

You can write the loop by hand, as above, or use an agent framework like LangGraph, the OpenAI Agents SDK, or the Claude Agent SDK that bundles the loop, tool plumbing, memory, and tracing. Frameworks save time but add abstraction; a widely-shared lesson from practitioners is to start with the raw loop, understand it, and adopt a framework only once you feel the pain it solves.

Autonomy, evaluation, and safety

The more freedom an agent has, the more it can do — and the more it can go wrong. Computer-use agents that click around a real screen are the high-autonomy frontier, and also the highest-risk: an agent with the power to send emails or spend money needs hard limits and, often, a human approval step. Because agent behavior is non-deterministic, you can't unit-test it like normal code; instead you build evals that score whether the agent reached the goal across many runs. Evaluation, not coding, is usually the bottleneck in shipping a reliable agent.