Software used to be a thing you launched and closed. You opened the spreadsheet, you opened the browser, you ran the script. The computer waited for your input, did one step, then waited again.
Agents break that. An agent is software you give a goal to — not a command — and then it decides which steps to take, which tools to call, which other agents to ask for help. It might finish in three seconds or run quietly for three hours. It might succeed, or fail, or ask you a clarifying question, or realize halfway through that your real goal isn't what you said and come back to confirm.
This shift — from tools you use to agents you delegate to — is the most disruptive change in how we work with computers since the graphical user interface. This first course in the Agents series starts with where agents are being deployed today, what they're good at, what they break, and what decisions you need to make before putting one between you and your customer.
If you finish every module, here's who you become:
What formal computer-science and AI-research literature actually means by "agent" — and why the word is used so loosely in product marketing.
In March 2023, Stanford researchers released a paper titled "Generative Agents: Interactive Simulacra of Human Behavior." They ran 25 language-model instances inside a virtual town called Smallville. Each instance maintained a persistent memory stream, wrote plans each morning, and revised those plans when new information arrived — entirely without human prompting. One agent organised a Valentine's Day party: it sent invitations, checked whether others RSVP'd, and rerouted logistics when a venue conflict arose. No human typed a single instruction after the initial character description. The researchers explicitly used the word "agent" to distinguish these systems from chatbots, which require a human turn to produce every output.
That same month, OpenAI shipped GPT-4 with a system-prompt field. Tech journalists immediately called it an "AI agent." The two uses of the word described fundamentally different systems — and that gap is what this module resolves.
Stuart Russell and Peter Norvig's textbook Artificial Intelligence: A Modern Approach — the standard reference in university AI courses — defines an agent as "anything that perceives its environment through sensors and acts upon that environment through actuators." The definition has three non-negotiable parts.
First, the agent must perceive something external to itself. A static lookup table is not an agent; it has no sensors. A language model that reads the current date from a system clock, scans a live web page, or observes the output of its own previous action is perceiving its environment.
Second, the agent must reason or decide. Russell and Norvig describe a spectrum from simple reflex agents (if X then do Y) up through goal-based and utility-maximising agents. Modern LLM-based agents sit at the goal-based tier: they are given an objective, generate a plan, and attempt to execute it.
Third, the agent must act — produce outputs that change state in the world, not just text for a human to read. Running a shell command, committing code to a repository, sending an email, calling an API: these are actions. Returning a string to a chat window is borderline — it acts on a human, but not directly on an external system.
The word "autonomous" is not in the formal definition — but persistence across time is implied. An agent that acts, observes the result, and then acts again is exhibiting the perception–action loop. A system that produces one response and stops is better described as a tool or a completion endpoint.
In November 2023, Microsoft announced "Copilot" — described in press releases as an "AI agent embedded in Microsoft 365." At launch, Copilot summarised emails and drafted documents on request. It did not autonomously monitor an inbox, decide which emails needed follow-up, or send replies without a human click. By the formal definition it was an assistant with access to user data — not an agent. Microsoft used the word to signal ambition, not current capability.
By contrast, when Cognition AI shipped Devin in March 2024 — their software-engineering system — independent evaluators at Uplevel Data confirmed it could receive a GitHub issue, write code across multiple files, run tests, read the failure output, and iterate until tests passed, all without human intervention between steps. Devin was behaving as an agent by the formal definition: multi-step perception–action loops, persistent memory across a task, and real-world effects (committed code).
The distinction matters because it determines how you design, deploy, and audit a system. If you believe your "agent" is actually an assistant, you will over-trust its outputs. If you believe your "assistant" is an agent, you will add unnecessary guardrails and slow it down unnecessarily.
The AESOP AI Academy uses "agent" only in the formal sense throughout this course. When a real product blurs the line, we will say so explicitly — and explain which parts of that product are agentic and which are not.
3 questions — free, untracked, retake anytime.
Apply the formal three-part definition to real AI products announced in 2023–2024.
The AI below has been briefed on the formal agent definition (perceive → decide → act in a loop). Pick any real AI product from 2023–2024 — ChatGPT, Devin, AutoGPT, Gemini, Claude, Perplexity, GitHub Copilot, or another — and ask the AI to classify it. Challenge its reasoning. Push it to explain exactly which of the three components are or aren't present.
How real agentic systems are built — the four components that transform a language model into something that can act in the world.
In May 2023, a team at Significant Gravitas released AutoGPT on GitHub. Within two weeks it had over 100,000 stars — the fastest-growing open-source repository at that point in GitHub's history. AutoGPT accepted a high-level goal from the user ("Increase Twitter followers for @username by 20%"), then entered a loop: it used GPT-4 to generate a task list, executed tasks one at a time using web-search and file-write tools, stored results in a text file it called its "memory," and re-read that file at the start of each new reasoning step. It didn't always succeed — but its architecture was a direct implementation of the four-component agent design: profile (goal + persona), memory, tools, and action.
Researchers at Renmin University published a comprehensive survey in 2023 titled "A Survey on Large Language Model based Autonomous Agents" (Wang et al., arXiv:2308.11432). They reviewed over 100 agent papers and found that virtually every system decomposed into four components.
Profile is the agent's identity and objective. It is typically injected via a system prompt and defines what the agent is trying to accomplish and what role it occupies. Without a clear profile, the agent has no selection criterion for which actions to take when multiple options are available.
Memory encompasses how the agent retains information across steps. There are two types. In-context memory is everything currently in the model's context window — fast but limited. External memory is a database, file, or vector store that the agent can read and write — slower but unlimited. AutoGPT used a text file; production systems like Cognition's Devin use a persistent workspace.
Tools are the actuators — the interfaces through which the agent changes external state. Common tools include web search, code execution sandboxes, email APIs, calendar APIs, and file systems. A language model without tools can only produce text; with tools, it can produce real-world effects.
Action is the execution layer — how the agent translates a reasoning step into a concrete tool call, and how it handles the result. This includes error handling: what does the agent do when a tool call returns an error? A well-designed agent treats errors as new observations and revises its plan.
Wang et al. (2023) found that memory was the most frequently under-specified component in early agent papers. Systems often described tool use in detail but left memory architecture vague — which explains why early agents like AutoGPT frequently "forgot" previous steps and repeated work.
In practice, an LLM-based agent runs what researchers call a ReAct loop — Reason + Act — first described by Yao et al. in a 2022 paper (arXiv:2210.03629). Each iteration follows the same structure: the model receives the current context (goal + memory + last observation), generates a thought (a reasoning trace), generates an action (a specific tool call with parameters), the tool executes, and the tool's output becomes the next observation, which is added to context. The loop repeats until the agent decides it has completed the goal or a step limit is reached.
OpenAI formalised a close variant of this in their Function Calling API (released June 2023): the model outputs a JSON object specifying which function to call and with which arguments, the application executes the function, and returns the result as a new message. This is architecturally a constrained ReAct loop — the "thought" is implicit in the model's internal reasoning, and the "action" is always a structured function call.
Understanding the loop architecture tells you where agents fail. The three most common failure modes are: context-window overflow (too much history to fit), tool-call hallucination (the model invents parameters that don't exist), and goal drift (the agent pursues a sub-goal so deeply it forgets the top-level objective). Each failure maps directly onto one of the four components.
3 questions — free, untracked, retake anytime.
Use the four-component framework to explain why a specific agent broke down.
Below is an AI briefed on the Wang et al. four-component framework and the three common failure modes. Describe a scenario — real or hypothetical — where an agent fails, and ask it to diagnose which component broke down and why. Then push it to suggest a concrete architectural fix.
Why autonomy is a spectrum, how real deployments choose their level, and the consequences of choosing wrong.
In February 2024, Air Canada lost a civil court case in British Columbia. The airline's chatbot had told a passenger — Jake Moffatt — that he could apply for a bereavement discount after travel and receive a retroactive refund. Air Canada argued in court that the chatbot was a "separate legal entity" and that the airline wasn't responsible for its outputs. The tribunal rejected this argument and ordered Air Canada to pay the discount. The chatbot was an assistant operating without human review of individual responses. It had no tool that could verify current policy before replying, and no human-in-the-loop step before customer-facing output. The cost was not just the refund — Air Canada's legal team fees and reputational damage exceeded the original $812 claim by orders of magnitude.
Researchers at MIT's Computer Science and AI Lab and at Anthropic have both described autonomy in AI systems as a spectrum rather than a binary state. The spectrum typically has five levels, analogous — deliberately — to the SAE levels of vehicle automation.
Level 0 — Fully manual: The AI suggests; a human decides and acts. Spell-check is at this level. So is a language model generating a draft that a human rewrites before sending.
Level 1 — Assisted action: The AI acts on narrow, pre-approved tasks with no ambiguity. A rule-based autoresponder falls here. The action space is completely enumerated in advance.
Level 2 — Supervised autonomy: The AI acts, but a human reviews before real-world effect. GitHub Copilot suggesting a code block that an engineer must accept with a keypress is Level 2. Air Canada's chatbot should have been at Level 2 for policy-sensitive claims — it was not.
Level 3 — Conditional autonomy: The AI acts without human review for routine cases, but escalates to a human when it detects uncertainty or when stakes exceed a threshold. This requires the agent to have a well-calibrated confidence estimator and a reliable escalation path.
Level 4 — High autonomy: The AI acts across long multi-step tasks with minimal checkpoints. Devin operating on a contained development environment is close to Level 4. Failures are contained within the sandbox.
The appropriate autonomy level for a deployment is determined by two axes: the reversibility of actions (can the agent undo what it did?) and the blast radius of errors (how many people or systems are affected by a wrong action?). High reversibility and low blast radius permit higher autonomy levels. Irreversible actions with large blast radius require human-in-the-loop at Level 2 or below.
Anthropic published a model specification in 2024 describing how they train Claude to calibrate autonomy. Key passages describe "minimal footprint" as a default: the model should request only the permissions it needs, prefer reversible over irreversible actions, and err on the side of doing less and confirming with users when uncertain about intended scope. This is not timidity — it is a formal design choice about where on the autonomy spectrum the default should sit.
In contrast, Cognition AI's Devin was designed to operate at the high-autonomy end for a specific, sandboxed domain: software development. The key constraint that allowed this was domain specificity and physical isolation. Devin's actions — writing and running code — were contained inside a virtual machine. A bug in Devin's code couldn't directly affect a production system without a human deploying it. The sandbox substituted for human-in-the-loop review.
Air Canada's chatbot failure was not an AI failure — it was a deployment design failure. The team set the chatbot to Level 0 input but Level 4 output authority on policy questions. Matching autonomy level to stakes is the practitioner's first responsibility when deploying any AI system.
3 questions — free, untracked, retake anytime.
Map a real AI use case to the correct autonomy level using reversibility and blast-radius analysis.
The AI below is briefed on the five autonomy levels and the two design axes (reversibility, blast radius). Describe a real business scenario where you'd want to deploy an AI agent — customer service, code review, data analysis, anything — and ask it to recommend the correct autonomy level with a full justification. Challenge its recommendation if you disagree.
This lesson explores lesson 4 — examining the key principles, real-world applications, and implications for practitioners working in this domain.
Understanding this topic requires both theoretical grounding and practical awareness of how these concepts manifest in deployed systems. The frameworks covered in earlier lessons provide the foundation; this lesson connects them to implementation reality.
The transition from theory to practice reveals challenges that pure conceptual frameworks don't capture. Real-world deployment introduces constraints, trade-offs, and edge cases that demand nuanced judgment rather than rigid rule-following.
Effective practitioners in this space develop the ability to reason across multiple frameworks simultaneously, recognizing when different perspectives apply and how to resolve conflicts between competing priorities.
As this field continues to evolve, the principles covered in this module will remain foundational even as specific technologies and implementations change. The ability to think critically about these topics — rather than simply memorizing current best practices — is what separates effective practitioners from those who merely follow checklists.
Use the AI below to explore the concepts from Lesson 4 in depth. Ask questions, challenge assumptions, and work through practical scenarios related to lesson 4.