Why Did AI Agents Become Necessary?

A calculator can follow a fixed rule. A photo classifier can recognize a pattern. A chatbot can explain an answer. But what if the correct next step changes after every new result?

That is the problem agents were created to handle.

Known steps every time          Steps discovered while working
Input → fixed workflow → output Goal → act → observe → decide again

What You Will Learn

• Which limitation pushed software from rules to machine learning, LLMs, tools, and finally agents.
• Why flexible language generation alone cannot safely change a real system.
• How tool calling gives a model controlled access to data and actions.
• Why an agent is useful when later steps depend on earlier results.
• Why traditional software remains the better choice for predictable tasks.

A Real Engineering Rule

Anthropic’s production guidance makes the same trade-off concrete: begin with the simplest solution, use predefined workflows when the path is known, and add agents when the model needs to direct its own process and tool use. More autonomy usually buys flexibility by spending additional time and money. (Anthropic, Building Effective Agents)

This gives us a useful test throughout the course: Does the system need to discover its next step, or can normal code already know the step?

Module 1 gave you the mental model: an agent is a loop, not a smarter prompt. But there’s a question worth asking honestly before we go any further, because the answer changes how you think about everything else in this course: why didn’t we just start here? If a loop that lets a model take action and decide its own next step is so useful, why wasn’t it the first thing anyone built?

The honest answer is that it couldn’t have been the first thing. Every layer in this chain existed because the layer before it hit a real, specific wall — and agents are the most recent layer precisely because they depend on every capability that came before them already being solved. This module walks through that chain properly, not as trivia, but because understanding exactly what problem each stage solved — and what new problem it introduced — is what will let you reason clearly about agents instead of treating them as a black box that showed up recently and happens to be powerful.

Traditional Software
        ↓
Machine Learning
        ↓
Deep Learning
        ↓
LLMs
        ↓
LLM Applications
        ↓
Tool Calling
        ↓
AI Agents

Let’s go through this one link at a time.

Traditional software: rules and their real limit

The earliest approach to getting a computer to behave “intelligently” was to write down the rules yourself. This is worth taking seriously rather than dismissing as primitive, because it’s still exactly the right tool for an enormous number of real tasks: if account balance < 0, decline the transaction. if the invoice total doesn't match the line items, flag it for review. Deterministic, explicit, predictable — and when the rule captures the logic of the task, this is faster, cheaper, and more reliable than any AI system you could build instead.

Rules → Actions

The real limitation shows up the moment the pattern you’re trying to capture is too complex, too subtle, or too full of exceptions to write down by hand. Fraud detection is the classic example: you can write a rule like “flag transactions over $10,000,” but real fraud patterns involve dozens of interacting signals — location, timing, merchant category, device fingerprint, spending history — combined in ways that shift constantly as fraudsters adapt. Nobody can hand-write that rule set and keep it current.

This exact problem is what drove serious investment into so-called “expert systems” through the 1980s — large, hand-built rule bases meant to encode expert human judgment — and it’s also,, why that era of AI investment eventually stalled: the rules were brittle, expensive to maintain, and fell apart the moment reality drifted even slightly from what the rule-writer had anticipated.

That period is often referred to as an “AI winter” precisely because enthusiasm and funding cooled sharply once the limits of hand-coded rules became impossible to ignore.

The lesson that carried forward, and that still matters today: when a task is deterministic and its logic can be fully specified in advance, write the rules. Don’t reach for a more sophisticated approach out of habit. We’ll come back to this exact principle in the very last module of this course, because it applies to agents just as much as it applied to expert systems forty years ago.

Machine learning: learning the pattern instead of writing it

The next real shift was letting the system learn the pattern from data instead of a human specifying it directly. Rather than writing “flag transactions with these specific characteristics,” you show the system thousands of examples of fraudulent and legitimate transactions, and it learns the statistical pattern that distinguishes them — including patterns a human might never have thought to write down as an explicit rule.

This solved the brittleness problem. A learned model can generalize to new, unseen transactions that share statistical similarity with what it was trained on, without anyone hand-writing a rule for that specific case. Spam filters, credit scoring, early recommendation systems — this is the era that made statistical machine learning a serious, production-grade engineering discipline rather than a research curiosity.

But it introduced its own real, specific limitation: most classical machine learning needed hand-engineered features. You couldn’t just hand a model raw pixels or raw text and expect it to work well — someone had to first decide which characteristics of the data mattered and manually extract them (transaction amount, time since last purchase, merchant category, whatever). That feature engineering was a full engineering discipline in itself, and it meant a model was only as good as a human’s ability to guess which signals mattered in advance — which is precisely the wall that stood between this era and the next one.

Deep learning: learning the features too

Deep learning’s actual contribution — and it’s worth being precise about this, because “deep learning” gets used loosely — was removing the need for a human to hand-engineer those features. A deep neural network, given enough raw data (pixels, audio waveforms, text) and enough layers, can learn its own internal representation of what matters, without anyone specifying it in advance.

The moment this became undeniable to the field was 2012, when a deep convolutional network called AlexNet dramatically outperformed every traditional computer vision approach on the ImageNet image classification benchmark — a result concrete and public enough that it’s widely cited as the turning point that pulled deep learning from an academic niche into the mainstream of AI engineering. From there, the same underlying idea — let the network learn its own representations directly from raw data — spread into speech recognition, and eventually into language.

The new problem this introduced was, again, specific and real: deep learning is data-hungry and compute-hungry in a way classical ML mostly wasn’t, and — this is the part that matters most for where we’re headed — a deep learning model trained for one task was still just for that task. A model trained to classify images couldn’t suddenly write an email.

A model trained for one company’s fraud patterns couldn’t be repurposed for a different company’s customer support without being retrained essentially from scratch. Every new use case meant a new model, new labeled data, and a new training run. This is exactly the wall that the next stage broke through.

LLMs: one model, generalized across tasks

Natural language processing went through its own internal evolution before arriving at large language models — word embeddings like word2vec captured some meaning in vector form, and recurrent architectures like LSTMs could process text sequentially and handle short-range dependencies reasonably well. But these approaches struggled with long-range context (an LSTM reading a long document tends to “forget” things from many steps earlier) and were slow to train, because they had to process a sequence one step at a time.

The 2017 paper “Attention Is All You Need” introduced the transformer architecture, which processes an entire sequence in parallel using an attention mechanism instead of stepping through it token by token — a architectural breakthrough that solved both the long-range dependency problem and the training-speed problem at once.

You’ve already studied transformers in depth, so we won’t re-derive the mechanism here — the point relevant to this module is what happened next: once you could train transformer models at massive scale on enormous amounts of text, something new emerged that nobody had explicitly trained for. The resulting models could follow instructions, answer questions on topics never specifically trained for, and adapt to a new task just from a description in the prompt — what’s usually called in-context learning.

This was the moment the “one model, one task” limitation from the deep learning era broke. A single LLM could draft an email, summarize a document, translate text, and write code, without being retrained for any of those individually.

This is a real capability leap, and it’s also exactly where the next limitation sits, and it’s the one that this entire course exists to address: an LLM’s knowledge is frozen at training time, and it has no way to reach outside itself. It doesn’t know about your company’s current data. It doesn’t know what happened yesterday. And it has no mechanism whatsoever to check an account, call an API, or take any action in the real world. It can only generate text based on what it learned during training and whatever’s in the prompt in front of it right now.

LLM applications and tool calling: reaching outward, once

The next two stages address that limitation, piece by piece, and it’s worth treating them as separate steps, because conflating them is a common source of confusion.

An LLM application wraps the raw model with the surrounding engineering needed to make it useful for a specific, real task — a system prompt, formatting logic, and often a retrieval step that pulls in relevant, current, private information before the model generates its answer. This is RAG, which you’ve already studied in depth, and it’s the first real solution to “the model doesn’t know about our specific, current data” — by handing that data to the model as context, rather than expecting it to somehow already know it.

Prompt → LLM → Answer

This is enough for a huge range of production systems. But notice what it still can’t do: it can retrieve and read information, but it can’t act. A RAG-based support assistant can tell a customer what the refund policy says. It cannot issue the refund. That requires reaching into a real system and causing a real effect, which retrieval alone was never built to do.

Tool calling is what closed that specific gap. Rather than the model only ever generating plain text, providers built a structured mechanism into their APIs letting the model generate a request to call a specific function with specific arguments — “call get_payment_history with customer_id: C-4471” — which your application code then executes, feeding the real result back in.

OpenAI introduced this as “function calling” in mid-2023, and Anthropic and Google built equivalent “tool use” mechanisms into their own APIs shortly after — not as a novelty feature, but specifically because engineers building on these models kept running into the exact wall this module has been describing: a model that could talk about looking something up, with no reliable, structured way to do it.

With tool calling alone, here’s precisely what you get:

Input → LLM → Tool → Result → LLM → Output

One decision, one action, one result folded back into one final answer. This is a real, meaningful capability — the model can now check a single fact before responding — and it’s also still fundamentally a single-shot interaction. If that one tool result reveals something that requires a second, different lookup — exactly the situation in the refund scenario from Module 1, where “insufficient funds” on the payment history should trigger a follow-up check on the payment gateway — tool calling alone has no mechanism to continue. The interaction is already over.

Agents: closing the loop

This is the actual, final piece, and by the time you reach it, you can see clearly why it had to come last: an agent takes tool calling and wraps it in a loop, where each tool result feeds back into a new round of reasoning, which can trigger another tool call, which feeds back again — continuing until the model itself determines the goal is satisfied, or a limit is hit.

Goal
 ↓
Observe
 ↓
Reason
 ↓
Decide
 ↓
Act
 ↓
Observe result
 ↓
Continue / Stop

Lay all three shapes from this module side by side and the whole evolution compresses into three lines:

Traditional automation:   Rules → Actions

LLM application:          Prompt → LLM → Answer

Agent:                    Goal → Decide → Act → Observe → Decide again

Each one is a step up in flexibility over the one before it — and, as this whole module has been arguing, a step up in cost, unpredictability, and engineering difficulty too. That trade-off, not raw capability, is the actual throughline of everything you’ve just read.

The pattern became visible to the wider engineering community very publicly and very suddenly in early-to-mid 2023, when open-source projects like AutoGPT and BabyAGI demonstrated — in front of a large, watching audience — exactly what happens when you let a model call itself repeatedly, deciding its own next step each time, with access to tools and a stated goal.

It was exciting, and it was also rough: these early systems were prone to looping on unproductive actions, burning through enormous numbers of tokens, and occasionally wandering off in strange directions with no real way to stop them.

That roughness isn’t a footnote — it’s a direct preview of exactly the failure modes we’ll cover in real depth in Module 10, and it’s a big part of why the rest of this course spends so much time on reliability, guardrails, and evaluation rather than only on how impressive the loop itself is.

What followed was the major labs building this pattern into their own products with real engineering discipline behind it — OpenAI’s Assistants API, Anthropic’s tool use and later computer-use capabilities, and a wave of agent frameworks (which you’ll study properly later in this learning path) all emerged specifically to take the raw idea AutoGPT had demonstrated and make it something you could build a dependable, production system on top of.

What this evolution teaches you

Look back at the whole chain, and a pattern is visible across every single link: each stage solved one real, specific limitation of the stage before it, and each stage introduced its own new, real limitation in exchange. Rules were brittle, so we learned patterns from data. Learned patterns needed hand-engineered features, so we let deep networks learn their own representations. Deep networks were locked to one task each, so we built models general enough to handle many tasks through language alone.

Language models couldn’t reach outside themselves, so we gave them retrieval and then tools. Tools only allowed one decision, so we wrapped them in a loop.

Agents are not the end of this chain because they’re somehow perfect — they’re the current frontier of it, and they carry their own real, specific new problems: they cost more, they’re slower, they’re harder to test than deterministic code, and giving a model the ability to take real action introduces security and reliability risk that a plain LLM application never had to worry about.

Every one of those new problems gets a dedicated, serious treatment later in this course — Module 10 on failure and reliability, Module 11 on security, Module 12 on evaluation. None of it is a footnote. It’s the direct continuation of the exact pattern this module just walked you through.

When This Evolution Matters

Use the agent step of this evolution when the system must adapt its path after receiving tool results. Stop earlier in the chain when rules, a classifier, retrieval, or one LLM call already meets the requirement.

Common Misconception

Incorrect idea: Every new AI architecture replaces the architecture before it.

Why it is incorrect: Agents still depend on ordinary code, databases, APIs, machine-learned models, and deterministic security controls. New layers add options; they do not make proven lower layers obsolete.

Key Takeaways

• Every stage in this evolution — rules, machine learning, deep learning, LLMs, LLM applications, tool calling, agents — solved one specific, real limitation of the stage before it, and introduced its own new, specific limitation in exchange. None of it is a strict upgrade; it’s a chain of trade-offs.
• Hand-written rules are brittle when the underlying pattern is too complex to specify in advance — and this same brittleness lesson from the 1980s “AI winter” era of expert systems still applies directly to deciding when NOT to reach for an agent today.
• Classical machine learning removed the need to hand-write rules but still required humans to hand-engineer which features mattered; deep learning (concretely demonstrated at scale by AlexNet in 2012) removed that requirement too, by learning representations directly from raw data.
• LLMs generalized a single model across many tasks through in-context learning, but their knowledge is frozen at training time and they have no native way to reach outside themselves — the exact gap the rest of this evolution exists to close.
• RAG and LLM applications solved the “doesn’t know current or private information” problem through retrieval; tool calling (introduced by OpenAI in mid-2023, followed by Anthropic and Google) solved “can’t take real action” — but only for a single decision at a time.
• Agents close that final gap by wrapping tool calling in a loop, where each real result feeds back into a new decision — a pattern made publicly visible by AutoGPT and BabyAGI in 2023, and since built into production-grade capabilities by the major model providers.
• Every new capability in this chain came with a new, real cost. Agents are not an exception — they’re currently the most expensive, least predictable, and highest-risk layer in the entire chain, which is exactly why the rest of this course treats reliability, security, and evaluation as core material rather than an afterthought.

Think Like an AI Engineer

• Pick any AI-powered feature you’ve used recently — a spam filter, a recommendation feed, a chatbot. Try to place it on this evolution chain. Is it closer to classical ML, deep learning, a plain LLM application, or a real agent? What evidence would you look for to tell the difference?

• The 1980s expert-systems era failed largely because hand-written rules couldn’t keep up with real-world complexity and drift. Can you think of a modern situation where a team might make the opposite mistake — reaching for an AI agent when the underlying task is stable and predictable enough that hand-written rules would have been the better, cheaper, more reliable choice?

• Tool calling alone gives a model exactly one decision before the interaction ends. Think of a real task from your own work that needs a second tool call whose necessity only becomes clear after seeing the result of the first one. What would that second call depend on?

• AutoGPT and BabyAGI were exciting and rough at the same time. If you were an engineer at a major lab watching those projects go viral in 2023, what specific reliability problems would you have prioritized solving before shipping something similar as an actual product feature?

Module 3 takes everything from this evolution and gives it proper architectural shape: what are the actual named components of an agent — goal, tools, state, memory, reasoning, feedback — and how do they fit together as a real system you could design and build?