Building Production AI Agents · Agent foundations and architectures · lesson 1 of 18 · 14 min

What an AI agent really is (and when not to build one)

The one-sentence definition

An AI agent is a system in which a language model decides, step by step, which actions to take (usually by calling tools), observes the results, and keeps going until it judges the goal is met or a limit is reached. The defining feature is model-directed control flow: the model, not your code, chooses the next step.

Contrast that with a workflow, where your code fixes the sequence ("summarize, then translate, then post") and the model fills in each step. Both are useful. Most production value today still comes from workflows and single calls; agents earn their place when the path genuinely cannot be written down in advance.

The agent loop

Every agent, whatever the framework, runs the same loop:

Perceive — the model receives the goal, instructions, available tools and everything that has happened so far (the context).
Decide — it either answers or emits one or more tool calls (name + JSON arguments).
Act — your runtime (not the model) executes those tool calls.
Observe — results are appended to the context.
Repeat until the model stops calling tools, a budget runs out, or a guardrail halts it.

The model never touches your systems directly. It proposes; your code disposes. That single fact is the foundation of agent safety, cost control and debugging.

The four questions before you build an agent

Anthropic's engineering guidance (and hard experience across the industry) suggests checking four things before choosing an agent over a workflow:

| Question | If "no" | |---|---| | Complexity — is the task multi-step and hard to specify in advance? | Write a workflow or a single call | | Value — does the outcome justify extra tokens, latency and engineering? | Use a cheaper deterministic path | | Viability — can current models actually do this task type well? | Narrow scope or keep a human doing it | | Cost of error — can mistakes be caught and reversed (tests, review, rollback)? | Add approvals or don't automate yet |

A good agent candidate: "Investigate why last week's paid-social leads dropped, pull data from the ad platform and CRM, and draft a findings memo." The path depends on what the data shows. A poor candidate: "Every morning, export yesterday's leads to a sheet." That is a scheduled job.

Autonomy is a dial, not a switch

Think of five levels:

Single call — one prompt, one answer.
Workflow — fixed steps, model inside each.
Tool-using assistant — model picks tools within one user turn; human reviews every result.
Supervised agent — multi-step, but risky actions pause for approval.
Autonomous agent — runs to completion inside strict budgets and permissions, with after-the-fact review.

Move up only when evaluations prove the lower level cannot hit your quality bar. Each level up multiplies the ways things can fail.

Worked example: a lead-research assistant for a Dubai agency

An agency in Dubai wants help preparing for sales calls. The brief: "Given a company name, find what they sell, recent news, likely decision-makers and a suggested opening angle."

Workflow version: search → fetch top three pages → summarize into a template. Fast and cheap, but brittle when the company name is ambiguous ("Noon" the retailer vs a café called Noon).
Agent version: the model can search, notice ambiguity, refine the query with the city, fetch the right pages, and stop when it has enough. Better quality on messy inputs, at higher cost per run.

The pragmatic answer is often a hybrid: a workflow skeleton with one agentic step ("research until confident, max 8 tool calls") inside it.

Hands-on: map your candidate tasks

Use this template to score three tasks from your own work before writing any code.

Task: ______________________________
Inputs available: ___________________
Steps known in advance? (yes/partly/no)
Tools needed (read-only / write / irreversible): ________
Worst realistic mistake and its cost: ________________
How would we detect that mistake? ___________________
Human approval needed for: _________________________
Autonomy level to start at (1-5): ___
Success metric (e.g., % tasks accepted without edits): ____

Then write the smallest version at the chosen level. For many teams the first "agent" is a level-3 assistant with read-only tools, which is safe to ship quickly and teaches you what users really ask for.

Common failure modes to design for from day one

Looping: the model repeats the same search. Fix with iteration caps and tools that return "no new results" clearly.
Premature stopping: it answers after one weak result. Fix with explicit completion criteria in the instructions.
Tool misuse: wrong arguments or the wrong tool. Fix with clearer tool names, descriptions and schemas (module 2).
Context bloat: long tool outputs crowd out the goal. Fix with concise tool outputs and context management (module 3).
Unsafe actions: sending, deleting, paying. Fix with permissions and approvals (module 4).

How to measure success

Decide before building: task success rate on a fixed test set, median and 95th-percentile cost per task, latency, and the rate of human corrections. An agent that is 5% more accurate but three times the cost and twice as slow may be the wrong choice; the numbers, not the novelty, should decide.

Video lecture: What an AI agent really is (and when not to build one)

Lecture coming soon · 13 chapters · about 9 minutes. Read the full transcript below.

What an AI agent really is
Why it matters
Agent vs workflow
The agent loop
Four questions before you build
Simple example: one bakery, two tasks
Autonomy is a dial
Example: sales-call research
Five failure modes
Deeper: the Dubai call-prep numbers
Watch me do it: scoring a task
Try this now
Recap

Lecture transcript

What an AI agent really is

Imagine giving a new hire a goal instead of a checklist. Find out why leads dropped last week, and tell me what to do. They would search, look at data, ask a question, try another angle, and stop when they are confident. That is exactly what an AI agent does. In this lesson you will learn what an agent really is, how the agent loop works, and, just as important, how to decide when you should not build one.

Why it matters

Why does this matter so much right now? Because agents are the most over promised idea in AI. Teams burn months building autonomous systems for tasks a ten line script could handle, then conclude that AI doesn't work. Here's an analogy. Hiring an agent is like hiring a contractor instead of buying flat pack furniture. The contractor adapts when the wall isn't straight, but costs more, and you need to check their work. Flat pack, the workflow, is cheaper and predictable when the instructions fit. Your job is to know which situation you're in before you spend a single dollar.

Agent vs workflow

Here is the core definition. An agent is a system where a language model decides, step by step, which action to take next, usually by calling a tool. It looks at the result, then decides again. The key phrase is model-directed control flow. In a workflow, your code decides the order: summarize, then translate, then post. In an agent, the model decides. Both use the same models. The difference is who holds the steering wheel.

The agent loop

Let's walk the loop. First, perceive: the model receives the goal, its instructions, the tools it may use, and everything that has happened so far. Second, decide: it either answers or asks to call a tool with specific arguments. Third, act: your code runs that tool. The model never touches your database or inbox directly. Fourth, observe: the result goes back into the context. Then it repeats, until the model stops asking for tools, a budget runs out, or a guardrail stops it. Remember this: the model proposes, your code disposes. That one idea is the basis of safety, cost control and debugging.

Four questions before you build

So when is an agent worth it? Ask four questions. Complexity: is the task multi-step and hard to write down in advance? Value: does the result justify more tokens, time and engineering? Viability: can today's models actually do this well? And cost of error: if it makes a mistake, will you catch it and can you undo it? If any answer is no, drop down to a workflow or a single call. Most production value today still comes from those simpler designs.

Simple example: one bakery, two tasks

Let's make that concrete with a simple example. Say you want a weekly social post for a bakery. The steps never change: pick this week's special, write a caption, add a hashtag, schedule it. That's a workflow. Now change the task: find out why weekend orders dropped and suggest a fix. You don't know the steps. Maybe it's reviews, maybe a competitor opened nearby, maybe the delivery app changed its fees. The model needs to look, decide, and look again. That's where an agent earns its cost. Same bakery, two very different designs.

Autonomy is a dial

Think of autonomy as a dial with five settings. One: a single call. Two: a fixed workflow. Three: an assistant that picks tools within one turn while a human checks every result. Four: a supervised agent that runs many steps but pauses before risky actions. Five: an autonomous agent that runs to completion inside strict budgets and permissions. Start low. Only turn the dial up when your evaluations show the lower setting cannot meet the quality bar.

Example: sales-call research

A worked example. A Dubai marketing agency wants call prep: given a company name, find what it sells, recent news, likely decision makers and an opening angle. A workflow version searches, fetches three pages and summarizes. It's cheap, but it breaks on ambiguous names, like a big retailer and a local café sharing a name. The agent version notices the ambiguity, adds the city to its search, fetches the right pages and stops when it's confident. The winning design is often a hybrid: a workflow skeleton with one agentic research step capped at, say, eight tool calls.

Five failure modes

Plan for failure from day one. Agents loop, repeating the same search. They stop too early after one weak result. They call the wrong tool with the wrong arguments. They drown the goal in long tool outputs. And, worst of all, they may take unsafe actions like sending or deleting. Each has a fix you'll learn in this course: iteration caps, clear completion criteria, better tool design, context management, and permissions with approvals.

Deeper: the Dubai call-prep numbers

Let's go deeper on the Dubai agency example, with illustrative numbers. They prepare for about forty sales calls a week. The pure workflow version costs a few cents per company and takes ten seconds, but on ambiguous names, roughly one in five briefs describes the wrong business, and the salesperson wastes their preparation time. The agent version costs several times more per brief and takes about a minute, but wrong company briefs almost disappear because the agent adds the city and industry to its searches. The team's decision rule was simple: the cost of one embarrassing call with the wrong facts is far higher than the extra cents. So they kept the workflow for obvious names, and switched to the agentic research step only when the first search returned more than one plausible company.

Watch me do it: scoring a task

Watch me do it. I'll score one real task on screen using the template from the lesson text. The task: every Monday, summarize last week's ad performance for each client and flag anything unusual. First question: are the steps known in advance? Mostly: pull numbers, compare with the previous week, write a summary. So I write, partly. Tools needed: read only analytics access. Worst realistic mistake: a wrong number in a client email. How would we detect it? The numbers come straight from the analytics tool, so I can check them in code. Human approval: before anything is sent to a client. Autonomy level: I pick three, an assistant that drafts while a person reviews. And my success metric: the share of summaries sent without edits. Notice I haven't written a single line of agent code yet, and I already know what to build, what to avoid, and how to measure it.

Try this now

Here's your try this now. Open a blank document and list three tasks you'd love to automate. For each one, answer four questions in one line each: can I write the steps down in advance, is the result worth extra cost, can today's models do it, and can I catch and undo a mistake? Then pick a starting level on the autonomy dial, from one to five. Most people discover that two of their three tasks are workflows, and that's a great result. It means you can ship something useful this week and save the agent for the task that truly needs it.

Recap

Let's recap. An agent is a model choosing its next action in a loop, while your code executes every action. Use the four questions to decide whether an agent is justified, and treat autonomy as a dial you turn up slowly. Before you write code, define success rate, cost per task and latency. Your next step: open the lesson text and fill in the task template for three tasks from your own work. Pick one to carry through the rest of this course.

Key takeaways

An agent is a model choosing its next action in a loop; a workflow is code choosing the sequence.
The runtime executes tools, never the model, which is the root of safety and control.
Check complexity, value, viability and cost of error before choosing an agent.
Treat autonomy as a dial and move up only when evals show the lower level falls short.
Define success, cost and latency metrics before writing the first line of agent code.

Try it

Score three tasks from your job with the template in this lesson and pick the autonomy level for each. Share the one you would build first and the metric you would use.