TechByteByByte

What Is an AI Agent?

The precise definition Module 1's evolution story built toward — why an Agent is a real SYSTEM, not just a model, and sharp distinctions from an LLM, a chatbot, an LLM application, automation, and a workflow.

#AI Agents#AI#Foundations#Level 1

Begin with the problem

Calling every tool-using chatbot an agent hides the important part: an agent is the surrounding system that pursues a goal across a controlled loop.

goal + observations → model chooses next action → tool runs → state changes → repeat or stop

What you will learn

  • Define an AI agent as a complete system rather than only an LLM.
  • Identify the goal, decision loop, tools, state, observations, and stopping rule.
  • Distinguish an agent from a chatbot, one-shot tool call, and fixed workflow.
  • Test whether a product described as an “agent” actually behaves like one.

Current real-system grounding: Google’s current Agents overview documents managed agent harnesses with tools, loops, context management, sandboxed execution, and multi-step research.

These official links document available product features. They do not reveal every provider’s private implementation, hidden reasoning, default setting, or internal limit.

1. The problem this module solves

Module 1 traced the evolution that led to AI Agents, ending with Section 7’s loop. This module gives that loop a precise, defensible definition — and, critically, corrects a common misconception about Agents before it can take root.

2. The Definition We’re NOT Using

You will see this definition everywhere:

“An Agent is an LLM with tools.”

This is incomplete, and worth being direct about why: a system that makes exactly one LLM call, which happens to call one tool, technically matches this definition — but Module 1, Section 6 already showed this is just a “tool-using LLM,” not an Agent. This definition misses the single most important ingredient.

3. The Definition This Course Uses

An AI Agent is a SYSTEM — built around an LLM, but more than the LLM alone — that pursues a goal by repeatedly observing its environment, reasoning about what to do next, taking an action, and using the result of that action to inform its next decision, until the goal is achieved or the system decides to stop.

flowchart TD
    A[Goal] --> B[Observe]
    B --> C[Reason / Decide]
    C --> D[Act]
    D --> E[Observe Result]
    E --> C
    C --> F[Goal Completed]

The essential ingredient this definition captures that “LLM with tools” misses: the loop, and the fact that the system decides when to stop, rather than a human deciding that for it in advance.

4. Agent as a System, Not a Model

This is worth stating explicitly, since it’s easy to conflate:

The LLM is not the Agent. The LLM is one COMPONENT of the Agent — the reasoning engine, but the Agent also needs state, tools, memory, and control logic (the code that actually runs the loop) working together. Module 5 covers this composition in full depth.

A useful mental check: if you removed the surrounding control logic and just called the LLM once, would you still have something that pursues a goal across multiple steps? If not, the “Agent” behavior was never in the LLM alone — it was in the system around it.

5. Agent vs. LLM

LLM (alone)Agent
What it doesGenerates text from an inputPursues a goal through repeated reasoning and action
Access to toolsNone, by itselfuses tools to act on its environment
Number of stepsOne (a single generation)Potentially many, decided dynamically
Decides when to stopN/A — always stops after generatingdecides based on whether the goal is met

6. Agent vs. Chatbot

A CHATBOT: optimized for CONVERSATION -- responding
          naturally, turn by turn, to what a user says.

An AGENT: optimized for TASK COMPLETION -- pursuing a
         goal, which MAY involve conversation, but also involves
         taking real ACTIONS and using tools autonomously.

A chatbot can be built ON TOP of an agent (an agent that happens to communicate its progress conversationally) — but a chatbot that only ever responds to messages, with no goal-pursuit loop, is not itself an Agent.

7. Agent vs. LLM Application

An LLM APPLICATION: any software product built around an LLM call --
                    includes simple, ONE-SHOT uses (Module
                    1, Section 5) alongside agentic ones.

An AGENT is ONE KIND of LLM application -- specifically, one built
around the real goal-pursuit loop from Section 3, not just any
LLM-powered product.

Every Agent is an LLM application. Not every LLM application is an Agent — this directly connects to Module 1’s entire evolution story.

8. Agent vs. Automation, Agent vs. Workflow

This is the most practically important distinction for architecture decisions:

AUTOMATION / WORKFLOW:      the SEQUENCE of steps and DECISIONS are
                           fully determined by a HUMAN in advance --
                           the system EXECUTES a known plan reliably.

AGENT:                          the SEQUENCE of steps and DECISIONS
                              are determined DYNAMICALLY, by the
                              system itself, AT RUNTIME, based on
                              what it actually observes.

The useful test: could you draw the complete flowchart of every possible path this system might take, BEFORE it runs? If yes — even if the flowchart has many branches — it’s a workflow. If the actual sequence of steps can only be known by watching the system reason through the specific situation it encounters, it’s an Agent.

9. A Real Developer Example

TechCorp is deciding how to build three different features:

Featurereal ClassificationWhy
Auto-close tickets marked “resolved” every nightAutomationFixed action, no reasoning, no adaptation
Route a new ticket to Tier 1, 2, or Manager based on category and urgencyWorkflowEvery branch was pre-designed by a human — the flowchart is fully known in advance
Draft a reply to a simple FAQ questionLLM application (one-shot)One LLM call, no tools, no loop needed
Investigate and resolve a customer’s late-order complaint, deciding dynamically which systems to check and what remedy to offerAI AgentThe actual sequence of steps can’t be known in advance — it depends on what the agent discovers along the way

10. A Simple Agentic AI Connection

This module is the agentic AI connection — every subsequent module in this course builds directly on this definition. Worth restating the core test from Section 8 as a habit: whenever you encounter a system described as “an Agent,” check whether it has a loop where the system itself decides the next step based on what it just observed — or whether it’s actually a fixed workflow wearing an “Agent” label.

11. How Is This Used in AI?

🤖 How Is This Used in AI?

This precise definition directly shapes real architectural decisions — teams that clearly distinguish “does this task need dynamic, runtime decision-making” from “can this be fully planned in advance” build more reliable, more debuggable, and more cost- effective systems than teams that reach for “Agent” as a default label for anything involving an LLM.

12. Real-World Applications

  • Scoping decisions when a team is deciding how to build a new AI-powered feature
  • Technical interviews, where precisely distinguishing these terms is a common signal of real understanding
  • Debugging: recognizing whether an underperforming system’s problem is in its LLM reasoning, or in the surrounding control logic (Section 4)

13. Common Mistakes

Incorrect idea: Defining an Agent as “an LLM with tools.”

Why it is incorrect: As shown directly in Section 2-3, this misses the essential loop and stop-decision components.

Incorrect idea: Calling any LLM-powered chatbot an “Agent.”

Why it is incorrect: As shown directly in Section 6, a chatbot without a real goal-pursuit loop is not itself an Agent.

Incorrect idea: Calling a workflow with many branches an “Agent” because it feels complex.

Why it is incorrect: As shown directly in Section 8, complexity isn’t the test — whether the SEQUENCE is knowable in advance is the test.

14. Limitations

  • “Agent” is not a single, perfectly standardized industry term — this course uses a precise and useful definition, but you will encounter looser usage elsewhere
  • The line between “a workflow with many conditional branches” and “a real agent” can, in some real systems, become blurry at the edges

15. Quick Reference

flowchart TD
    Q{Can every possible<br/>step be fully mapped<br/>out BEFORE running?}
    Q -->|Yes| W[Workflow / Automation]
    Q -->|No — depends on<br/>runtime observations| A[AI Agent]
    A --> L{Does it loop,<br/>deciding its own<br/>stopping point?}
    L -->|No, one shot| App[LLM Application]
    L -->|Yes| Agent[real AI Agent]

16. Code — Testing Whether a System Is an AI Agent

🎯 Target of this example: implement Section 3’s precise definition as a direct, testable check — verifying that a system qualifies as an Agent only when it has a loop, adapts its next decision based on observation, AND pursues an explicit goal, not merely when it uses a tool.

Example 1 — Simple

def is_genuine_agent(system: dict) -> dict:
    """Directly implements Section 3's definition -- checks for ALL
    THREE essential ingredients, not just 'uses a tool.'"""
    has_loop = system.get("repeats_until_goal_met", False)
    has_dynamic_decisions = system.get("decides_next_action_from_observation", False)
    has_goal = system.get("has_explicit_goal", False)

    is_agent = has_loop and has_dynamic_decisions and has_goal
    missing = []
    if not has_loop:
        missing.append("no real loop -- stops after one action")
    if not has_dynamic_decisions:
        missing.append("doesn't adapt next action based on observation")
    if not has_goal:
        missing.append("no explicit goal to work toward")

    return {"is_genuine_agent": is_agent, "missing_requirements": missing}

chatbot = {"has_explicit_goal": False, "repeats_until_goal_met": False, "decides_next_action_from_observation": False}
tool_llm = {"has_explicit_goal": True, "repeats_until_goal_met": False, "decides_next_action_from_observation": False}
genuine_agent = {"has_explicit_goal": True, "repeats_until_goal_met": True, "decides_next_action_from_observation": True}

for name, system in [("Simple chatbot", chatbot), ("Single tool-call LLM", tool_llm), ("real agent", genuine_agent)]:
    result = is_genuine_agent(system)
    print(f"{name}: is_agent={result['is_genuine_agent']}")
    if result["missing_requirements"]:
        print(f"  Missing: {result['missing_requirements']}")

Expected Output:

Simple chatbot: is_agent=False
  Missing: ['no real loop -- stops after one action', "doesn't
adapt next action based on observation", 'no explicit goal to work
toward']
Single tool-call LLM: is_agent=False
  Missing: ['no real loop -- stops after one action', "doesn't
adapt next action based on observation"]
real agent: is_agent=True

What we conclude from this example: the single tool-call LLM correctly fails the real-agent test, even though it DOES use a tool — exactly Section 2’s point: “uses a tool” alone is insufficient, since it’s still missing the loop and the dynamic decision-making Section 3’s definition requires.

Example 2 — Intermediate

def can_be_fully_planned_in_advance(task_description: str) -> bool:
    """Directly implements Section 8's practical test: could every
    possible path be drawn as a flowchart BEFORE running?"""
    predictable_signals = ["every branch", "known categories", "fixed schedule", "same steps every time"]
    unpredictable_signals = ["depends on what", "investigate", "decide dynamically", "based on what it finds"]

    text = task_description.lower()
    if any(signal in text for signal in unpredictable_signals):
        return False
    if any(signal in text for signal in predictable_signals):
        return True
    return True  # default to workflow-classifiable unless unpredictable signals appear

def classify(task_description: str) -> str:
    return "Workflow / Automation" if can_be_fully_planned_in_advance(task_description) else "AI Agent"

tasks = [
    "Route tickets to one of three known categories using fixed rules.",
    "Investigate a late order, deciding dynamically which systems to check based on what it finds.",
    "Run the same backup steps every night on a fixed schedule.",
]

for task in tasks:
    print(f"{classify(task)}: {task}")

Expected Output:

Workflow / Automation: Route tickets to one of three known
categories using fixed rules.
AI Agent: Investigate a late order, deciding dynamically which
systems to check based on what it finds.
Workflow / Automation: Run the same backup steps every night on a
fixed schedule.

What we conclude from this example: the classifier correctly distinguishes Section 9’s TechCorp examples using nothing but Section 8’s “can this be planned in advance” test — directly turning that conceptual test into a concrete, working check.

Example 3 — Production Grade

from dataclasses import dataclass, field
from enum import Enum

class SystemClassification(Enum):
    AUTOMATION = "automation"
    WORKFLOW = "workflow"
    LLM_APPLICATION = "llm_application"
    AI_AGENT = "ai_agent"

@dataclass
class ClassificationResult:
    classification: SystemClassification
    confidence_notes: list = field(default_factory=list)

class AgentClassifier:
    """A production-style classifier COMBINING Example 1's essential-
    ingredients check with Example 2's plannability test, directly
    implementing this module's FULL definition as reusable,
    auditable logic."""

    def classify(self, has_goal: bool, has_loop: bool, adapts_to_observations: bool,
                 uses_llm: bool, fully_plannable_in_advance: bool) -> ClassificationResult:
        notes = []

        if fully_plannable_in_advance:
            notes.append("Every possible path can be mapped out in advance.")
            classification = SystemClassification.WORKFLOW if (has_loop or uses_llm) else SystemClassification.AUTOMATION
            return ClassificationResult(classification, notes)

        if not uses_llm:
            notes.append("No LLM involved despite unpredictable behavior -- likely still rule-based, just complex.")
            return ClassificationResult(SystemClassification.WORKFLOW, notes)

        if not (has_goal and has_loop and adapts_to_observations):
            missing = []
            if not has_goal: missing.append("explicit goal")
            if not has_loop: missing.append("real loop")
            if not adapts_to_observations: missing.append("dynamic adaptation")
            notes.append(f"Missing for AI agent status: {', '.join(missing)}.")
            return ClassificationResult(SystemClassification.LLM_APPLICATION, notes)

        notes.append("Has goal, loop, and dynamic adaptation -- meets Section 3's definition.")
        return ClassificationResult(SystemClassification.AI_AGENT, notes)

classifier = AgentClassifier()

# TechCorp's late-order investigator, Section 9's AI agent example
result = classifier.classify(
    has_goal=True, has_loop=True, adapts_to_observations=True,
    uses_llm=True, fully_plannable_in_advance=False,
)
print(f"Classification: {result.classification.value}")
for note in result.confidence_notes:
    print(f"  {note}")

Expected Output:

Classification: ai_agent
  Has goal, loop, and dynamic adaptation -- meets Section
3's definition.

What we conclude from this example: this classifier applies this module’s COMPLETE definition — plannability, goal, loop, and dynamic adaptation together — correctly identifying TechCorp’s late-order investigator as an AI agent, with an explicit, auditable note explaining exactly why, rather than a bare label with no justification.

17. Interview Questions

Q: Why is “an Agent is an LLM with tools” considered an incomplete definition?

Ans: This definition is satisfied by a system that makes a single LLM call which happens to invoke one tool — but that’s just a tool-using LLM, not an Agent, since it never loops or adapts its next decision based on what the tool returned. The essential ingredient this definition misses is the loop: an Agent repeatedly observes, reasons, and acts, using each result to inform its next decision, until a goal is achieved — a single tool call satisfies “LLM with tools” without ever demonstrating this defining behavior.

Q: Explain the practical test for distinguishing a workflow from a real AI Agent.

Ans: The test is whether every possible path the system might take could be fully mapped out as a flowchart before the system ever runs. A workflow, even one with many conditional branches, has all of its decision logic predetermined by a human in advance. A AI agent’s actual sequence of steps can only be known by observing how it reasons through the specific situation it encounters at runtime — the decisions are made dynamically, not pre-planned.

Q: Why is it inaccurate to say “the LLM is the Agent”?

Ans: The LLM is one component of an Agent — the reasoning engine that decides what to do next — but a functioning Agent also requires state, tools, memory, and control logic (the code that actually implements and runs the loop) working together as a system. Removing everything except the LLM and calling it once would produce a single generation, not a goal-pursuing loop — the “Agent” behavior lives in the system surrounding the LLM, not in the LLM in isolation.

Q: A team describes their new feature as “an Agent that handles customer refunds.” How would you verify whether it’s an Agent or a well-disguised workflow?

Ans: I’d ask whether the system’s actual sequence of steps for handling a refund could be fully diagrammed in advance — for example, “always check order status, then always check refund eligibility, then always process or deny” — which would make it a workflow, regardless of how many branches it has. If instead the system decides, at runtime, which systems to check and in what order based on what it discovers (for example, only checking a shipping carrier’s API if the order was marked as delivered but the customer disputes receiving it), that dynamic, observation-driven decision-making is what would qualify it as an Agent under this module’s definition.

18. What You Should Remember

  • An AI Agent is a real system — LLM plus state, tools, memory, and control logic — built around a goal-pursuit loop, not simply “an LLM with tools.”
  • The practical test for Agent vs. workflow: can every possible path be mapped out in advance? If yes, it’s a workflow; if the sequence depends on runtime observations, it’s an Agent — verified directly through a working classifier applying this exact test.
  • Every Agent is an LLM application; not every LLM application is an Agent — verified directly by correctly distinguishing a single tool-call system from a real, looping Agent.

19. Quick Practice

Describe a system you’ve used or heard about that’s labeled an “Agent.” Apply this module’s plannability test and essential- ingredients check to it — does it qualify, or is it more accurately a workflow or a tool-using LLM application?

20. Next Step

Next: Module 3 — The Agent Mental Model — mapping this module’s precise definition onto a complete set of concepts (goal, environment, state, observation, action, decision, tool, context, feedback) using a human-employee analogy that will anchor the rest of this course.

Author
TechByteByByte Editorial Team
Reviewed by
TechByteByByte Admin
Published
Last reviewed