Lesson 1: What AI Agents Actually Are
Course: Building AI Agents
Estimated time: 20 minutes
Difficulty: Intermediate Builder
Everyone's talking about agents. The word is everywhere, and most definitions fall into one of two failure modes: too vague to be useful ("it does things autonomously") or too technical to act on ("it's an LLM with a ReAct loop and tool-use capabilities"). Neither one helps you decide if you should build one, or what you'd actually build.
Let's fix that. An agent is not magic. It's a pattern.
The Loop
At the core of every agent - simple or complex - is the same four-step loop:
Perceive: The agent takes in information. A message, a file, the result of a previous action, sensor data, whatever.
Decide: The agent figures out what to do next. This is where the LLM lives. It reads the context and picks an action.
Act: The agent does something. Calls an API, writes a file, sends a message, runs a search, or calls another tool.
Learn: The result of that action goes back into context. The agent perceives it, and the loop starts again.
That's it. Everything you read about agents - autonomous systems, AI workflows, self-improving bots - is some variant of this loop running with different inputs, tools, and stopping conditions.
The reason agents feel different from regular LLM interactions is the loop. A single prompt-response exchange doesn't loop. The model reads your message, responds, and stops. An agent keeps going until it hits a condition that says "done." That condition might be a human saying stop, a task completion check, a maximum number of steps, or just running out of context.
Understanding the loop matters because it tells you exactly where things go wrong. An agent that's stuck in a bad loop burns API credits and achieves nothing. An agent without a clear stopping condition runs forever. An agent with bad perception (garbage input) makes bad decisions even with a great LLM. Fixing agents means knowing which part of the loop broke.
The Spectrum
Not everything that uses an LLM is an agent. There's a spectrum, and knowing where your use case sits tells you how much infrastructure you actually need.
Scripts with LLM calls. A Python script that calls the OpenAI API, does something with the response, and exits. No loop. No memory. No tools. Just structured output from a model. This covers most "AI features" in early-stage products.
Chatbots. The loop exists, but only for conversation. The bot receives a message, generates a reply, and waits. No external tool calls. No autonomous action. The LLM is just talking. This is most of what people call "AI assistants" in products.
Tool-using agents. The LLM can call external tools mid-conversation. It searches the web, reads a file, calls an API, runs code. Now it can actually do things, not just talk about them. This is where agents get genuinely useful.
Autonomous agents. Given a goal, the agent runs the loop without human input until the goal is complete. It might take 20 steps, make 50 tool calls, and run for 10 minutes. You give it the task and check back when it's done.
Multi-agent systems. Multiple agents with different roles, sharing context and handing off work. An orchestrator breaks a task into pieces. Specialists handle each piece. Quality gates check the output before it continues.
Most of the useful things you'll build in the next few months will sit somewhere between tool-using agents and autonomous agents. Multi-agent systems are powerful, but they're also where complexity compounds fast. Start simpler than you think you need to.
When You Need an Agent vs When a Script Is Fine
This is the question most agent tutorials skip, which is why people over-engineer their first few projects.
Use a script when:
- The task has a fixed sequence of steps
- The steps don't depend on dynamic conditions you can't predict
- The task is fast enough that a loop adds unnecessary overhead
- You need deterministic, predictable behavior
Use an agent when:
- The task involves branching logic that's hard to fully specify upfront
- The steps depend on information you don't have until mid-execution
- The task needs to use different tools depending on what it finds
- You want the system to handle failure cases by trying alternatives instead of just crashing
- The task is too long or complex to do in a single prompt
A concrete example: you want to pull data from an API, clean it, and write it to a database. That's a script. The sequence is fixed. There's no branching. Write the function, schedule it with a cron job, done.
Now imagine you want to monitor a competitor's pricing page, notice when prices change, look up why they might have changed (news, product launches, etc.), and draft a Slack message to your team with context. That's an agent. The task branches depending on what it finds. It needs to use multiple tools in sequence. The right output depends on what earlier steps discovered.
A useful mental test: if you could write the full decision tree as a flowchart with no "it depends" nodes, you probably don't need an agent. If the task has "it depends" nodes that won't resolve until runtime, an agent earns its overhead.
The Hype vs The Reality
Three things you'll read about agents that are true, and three that are mostly noise.
True:
Agents can replace significant manual work for tasks that have structure but require judgment. Customer support triage, research and summarization, code review, content production pipelines - these are all real agent use cases running in production today.
Agents compose well. You can start with a single agent doing one thing and expand it into a system with specialists, quality gates, and parallel processing. The architecture scales.
The latency and cost situation is improving fast. Agents that would have been prohibitively expensive to run in 2024 are practical in 2026.
Mostly noise:
"Fully autonomous" agents that operate without human oversight are a research project, not a production pattern. Real deployed agents have checkpoints, approval gates, and scope limits for good reason.
Agents don't make bad LLMs good. If the underlying model makes reasoning errors on a task, wrapping it in an agentic loop makes that worse, not better. An agent amplifies the model's strengths and weaknesses.
"Just give the agent a goal and it figures out the rest" works in demos. In production, you still write detailed system prompts, constrain the tool set, set failure conditions, and test the loop carefully.
The builders doing real work with agents right now are not waving a wand. They're writing code, debugging loops, and treating agents like any other system that needs careful engineering.
What Makes a Task "Agent-Shaped"
When you look at your own workflow, here's what to scan for:
A task is agent-shaped when it has most of these properties:
- It's repetitive enough that you do it multiple times per week
- It requires gathering information from more than one source
- The right action at each step depends on what you found at the previous step
- Doing it manually requires context-switching between multiple tools
- The task produces a clear, evaluable output (you'd know if it was done correctly)
- The cost of errors is low enough to tolerate occasional mistakes
If you can think of a task in your work that matches four or more of those, you probably have a good first agent project waiting.
Exercise: Identify Your Agent-Shaped Task
Take 10 minutes and do this:
Write down 5 tasks you do regularly that involve gathering information, making a decision based on that information, and taking some action as a result.
For each one, answer:
- How many tools or sources does this require? (browser, email, Slack, a specific app, etc.)
- Does the action you take depend on what you find, or is it always the same?
- How often do you do this? (daily, weekly, occasionally)
- How long does it take manually?
- What would a correct output look like - could you tell if an agent got it right?
Any task that hits "yes" on questions 2 and 5, uses 2+ tools, and happens at least weekly is worth building into an agent.
Pick one. That's your project for this course.
Key Takeaway
An agent is the perceive-decide-act-learn loop with tools. Know where your task sits on the spectrum - and don't build a multi-agent system when a script will do.
What's Next
You've identified your task. Lesson 2 is hands-on: building your first working agent in under an hour, using the platform and approach that fits how you work.