What Is an AI Agent?

Start with the goal, not the buzzword

"AI agent" gets used loosely, but the useful definition is narrow: an AI agent is a system where a language model decides what to do next toward a goal, takes an action, looks at the result, and repeats -- until the goal is met or it hits a limit. The model isn't just producing text; it's driving a loop that changes something in the world (a file, an API call, a database row, a browser tab) and then adapts based on what happened.

Compare that to a single model call. When you ask a chatbot a question and it answers, that's one input and one output -- no loop, no tools, no independent decisions about what to do next. An agent might take that same question and decide it needs to search the web, read three pages, run a calculation, and then answer -- choosing each of those steps itself rather than following a fixed script.

Four traits nearly every agent shares

Definitions vary by vendor, but in practice, working agent systems share four traits: they pursue a goal stated in natural language rather than a single fixed input; they can take actions through tools (search, code execution, an API, a database); they observe the result of each action and use it to decide the next step; and they operate over multiple steps, not a single turn, stopping only when the goal is met, a limit is hit, or a person intervenes.

Agent characteristics across system types

The four traits manifest differently depending on the kind of agent being built. Here's how they compare across common agent patterns:

These latency figures are illustrative estimates based on typical cloud API call times and model response latencies; actual performance depends heavily on network, tool complexity, and model endpoint configuration.

A concrete example, start to finish

Take a single request: "Check order #4521 -- if it's delayed, notify the customer." Watch how differently a chatbot and an agent handle it.

A chatbot has no way to actually check anything. It can only respond with what it already knows or a generic instruction like "you can check your order status on our tracking page" -- it cannot look anything up, so it cannot finish the task, only describe how a human might.

An agent treats the same sentence as a goal, not a question to answer from memory. It reasons out loud (or internally) something like: this requires looking up real order data before I can say anything useful. It calls a get_order_status(order_id) tool. The tool returns {status: "delayed", expected: "3 days late"}. The agent observes that result, recognizes the condition "if it's delayed" is true, and takes the second action: calling send_notification(customer_id, message). Only after both actions succeed does it produce a final answer: "Order #4521 is delayed by 3 days; I've notified the customer."

Nothing about this required a smarter model than the chatbot was using -- the difference is entirely that the agent was given tools, permission to call them repeatedly, and a loop that keeps going until the conditional in the goal ("if it's delayed") has actually been checked and acted on, not just restated.

Code structure: the agent loop

Here's the skeleton of how that agent-shaped behavior is built in code:

def process_order_check_goal(order_id: str, customer_id: str) -> str:
    """Agent loop to check order status and notify if delayed."""
    context = [f"Goal: Check order #{order_id}. If delayed, notify customer."]
    max_iterations = 5
    iteration = 0

    while iteration < max_iterations:
        iteration += 1

        # Perceive: what do we know so far?
        response = call_model(context=context)

        # Check if model signals it's done
        if response.is_final_answer:
            return response.text

        # Plan & Act: if model chose a tool, run it
        if response.tool_choice == "get_order_status":
            order_data = database.get_order(order_id)
            tool_result = f"Order status: {order_data['status']}, expected delivery: {order_data['expected_date']}"

        elif response.tool_choice == "send_notification":
            send_email(customer_id, response.message_content)
            tool_result = "Notification sent successfully"

        else:
            tool_result = "Unknown tool"

        # Observe: add what happened to context for next iteration
        context.append(f"Tool result: {tool_result}")

    return "Agent reached max iterations without completing the task"

The key difference from a chatbot: a chatbot would call the model once and return the text. This agent loops, adding the result of each tool call back into context, giving the model a chance to read what happened and decide the next step. The model doesn't "know" in advance that it needs two steps; it discovers that by observing the first result.

Why the loop matters more than the model

It's tempting to think a bigger or smarter model is what makes an agent better. In practice, most failures in agent systems come from the scaffolding around the model -- how tools are described, how much context is kept between steps, when to stop, what to do when a tool call fails -- not from the raw intelligence of the model itself. Anthropic's engineering team makes this point directly: the simplest agent designs that clearly define tools and stopping conditions tend to outperform elaborate ones that don't.

Consider two agents built on the identical underlying model. One has a vague tool description ("checks stuff") and no stopping guidance; it might call the tool at the wrong moment, misread the result, or keep going after the goal is already met. The other has a precise tool description and an explicit "stop once you've confirmed the order status and sent a notification if needed" instruction. Same model, same tool, radically different reliability -- because the gap wasn't intelligence, it was scaffolding. That scaffolding -- tool design, context management, stopping conditions -- is exactly what the rest of this course covers, lesson by lesson.

Why agents are different from automation or search

The word "agent" is sometimes used loosely to mean any automation. But notice how the order-checking example earlier differs from both. Automation (a scheduled script that sends a report every Monday) follows a fixed sequence that a human designed in advance -- no adaptive branching, no model decision-making. An agent, by contrast, adapts its plan on the fly based on what it observes. Search (looking up information and returning it) stops after retrieval -- an agent continues, deciding what to do based on what it found. A search system that retrieves flight prices is not an agent; an agent that retrieves prices, compares them against a threshold, and then books the cheaper flight is genuinely agentic because the booking step depends on the information the retrieval step produced.

The confusion arises because agent products often include search or database lookups as tools. But the agent part is the decision loop around them, not the individual tools. Adding a search tool to a chatbot doesn't make it an agent; what makes it an agent is the ability to recognize "I need to search, so I'll call this tool, and I'll use the result to decide what to do next."

When an agent is the wrong tool

Just as important as recognizing when you need an agent is recognizing when you don't. Some tasks sound like they need an agent but benefit more from a simpler approach:

Straight information retrieval: "What's the capital of France?" No agent needed. One model call with the answer from training knowledge is sufficient. Adding a loop that searches the web and confirms the result just adds latency and cost.

Creative generation with a fixed format: "Write me a haiku about AI." No agent needed. One well-crafted prompt produces multiple haiku options in a single call. An agent loop wouldn't improve quality.

Classification or labeling: "Classify these 100 support tickets by category." Depending on the complexity, a single batch processing call or a simple loop that classifies one at a time might be enough. A full agent loop with multiple decision points is overkill.

Tasks already fully specified: "Translate this document from French to English." The process is entirely known: load the document, translate it, return it. No branching or decision-making needed. An agent loop adds complexity for no benefit.

The pattern: if you can write a deterministic flowchart of all possible paths, you probably don't need an agent. If the next step genuinely depends on information you can't predict in advance, an agent becomes valuable.

The hidden role of context

One detail that recurs throughout agent systems is context -- the information the model is given to make decisions on. A chatbot's context is usually just the current conversation. An agent's context grows across multiple steps: the original goal, past steps already taken, tool results returned so far, and even the agent's own earlier reasoning about what to do next. That growing context is where the agent "learns" what it has already tried and what it should do next. Managing that context -- keeping signal in, removing noise, refreshing stale data -- is a major part of agent engineering that we'll return to in later lessons.

A second example: research and synthesis

Take a research task: "What are the top three threats to solar panel efficiency, and what's the current industry standard response to each?" A chatbot might describe generic knowledge from its training ("dust, weather, temperature"), but without checking current industry standards or recent research. An agent approaches it differently. It reasons: I need current information, not just what I was trained on. It might call a search_industry_publications(query="solar panel degradation 2024-2026") tool. The result brings back three papers. The agent observes those papers and decides it needs details on industry responses, so it calls fetch_technical_standard(name="IEC 61215 efficiency testing"). Only after reading both sources does it produce a final answer that cites specific degradation rates, specific mitigation techniques, and the standards behind them. The answer's reliability traces directly to those tool calls -- nothing is guessed.

Notice again: the agent's next step (fetching the standard) depended on what the earlier search returned. A fixed script would either always fetch the standard or never; only an agentic loop lets the model reason if I have a paper saying solar panels lose 0.5% efficiency per year, do I actually need the efficiency testing standard, or is the efficiency-loss rate enough to answer the original question? That kind of adaptive, data-dependent branching is what distinguishes agents from scripts, even when both are technically "automated."

Case study: E-commerce support agent

Consider a real-world scenario: a mid-sized online retailer implements an AI agent to handle tier-1 customer support. A customer emails: "My order has been pending for 10 days and says 'processing.' Can you ship it or refund me?"

A chatbot would offer generic guidance: "You can check your order status on your account page" or "Your order typically ships within 5-7 business days." The customer has to escalate to a human.

The support agent, by contrast: (1) looks up the order using the customer's email; (2) checks the inventory system to see if the item is in stock; (3) retrieves the shipping partner's tracking info to see if it's stuck or genuinely delayed; (4) based on what it finds, either (a) authorizes expedited shipping, (b) initiates a refund, or (c) escalates to a human with a detailed summary. The agent completes the task because it adapted based on what it discovered at each step. The outcome cost was lower (no human escalation for simple cases) and faster (response in seconds instead of waiting for human availability).

This only works because the agent looped -- observed the results of earlier tool calls before deciding the next action. A fixed script would either always refund or always reship, unable to read the actual inventory and shipping state.

Edge case: Recognizing false agency

A subtle but important trap: a system that calls a tool once and wraps the result in a chatbot-style answer is not an agent, even if the marketing calls it that. True agency requires the loop -- the model calling a tool, reading the result, and then deciding what to do based on that result. If the tool call is fixed in advance (always search the knowledge base before answering) and there's no branching based on what was found, it's just a chatbot with a retrieval step, not an agent.

This matters because the debugging approach changes. A chatbot with retrieval has one failure mode: the retrieved information is wrong. An agent has richer failure modes: it might call the right tool but misinterpret the result, or call the wrong tool because the first result was ambiguous. The architecture is fundamentally different, even if they look similar from the outside.

Common mistake

Treating "add an agent" as a checkbox that automatically makes a product smarter. An agent is a specific architecture -- goal, tools, loop, stopping condition -- suited to tasks that genuinely need multiple adaptive steps. A task that can be answered in one good prompt does not benefit from looping it through an agent framework; it just adds latency, cost, and new failure modes for no gain.