From Autocomplete to Autonomy

Ask ten engineers what an AI agent is and you will get ten answers, most of them describing whatever their employer is selling. That is not a good place to start a course. So before anything else, we need a definition precise enough to argue with - one that lets you look at a system and say "that is an agent" or "that is a chatbot with a database" and defend the answer.

Here is the one this course uses:

Four clauses. Every one of them is load-bearing, and a system that drops any one of them is something else. Let us take them apart.

Clause 1: a language model

Obvious, but worth stating because it rules things out. A rules engine that walks a decision tree is not an agent, no matter how sophisticated the tree. A workflow engine that routes work between queues is not an agent. Both make "decisions", but their decision function is written by a human in advance and is fully enumerable.

What the model brings is the ability to handle inputs nobody enumerated. That is the entire value proposition, and it is also the entire source of difficulty: you cannot enumerate the behaviour either.

Clause 2: in a loop

A single request-response call to a model is not an agent. You send text, you get text, you are done. That is a completion.

The loop is what changes the character of the system. Once the model's output can cause something to happen, and the result of that something is fed back into the model, you have a feedback cycle. The model's second decision depends on the consequences of its first. It can course-correct. It can also spiral.

This is the single most important structural fact about agents, and most of the engineering in this course exists because of it. Loops accumulate: they accumulate context, they accumulate cost, they accumulate error.

Clause 3: with tools

A model that loops but cannot affect anything is just talking to itself. Tools are the interface between the model's text output and the world - reading a file, querying a database, calling an API, sending a message.

Tools are also where the risk lives. A model that produces wrong text produces a wrong answer. A model with a delete_records tool that produces wrong text produces a wrong action, and actions are much harder to take back than words.

Clause 4: deciding which step to take next

This is the clause that does the real work, and it is the one people skip.

Consider two systems that both call a model several times and both use tools:

System A - the code says: extract the customer's intent, then look up their order, then draft a reply, then send it. The model is called at each step. The sequence is fixed.

System B - the code says: here is the goal and here are eleven tools, keep going until you are done. The model chooses whether to look up the order at all, whether to check the returns policy first, whether to escalate.

System A is a workflow with model-powered steps. System B is an agent. The difference is not sophistication or quality - System A is very often the better engineering choice - it is who holds the control flow. In A, the control flow lives in your source code and you can read it. In B, the control flow lives in the model's weights and you cannot.

Why the distinction matters practically

It determines what you can promise.

For a workflow, you can enumerate paths, unit-test each, and tell your stakeholder exactly what the system will do. For an agent, you cannot. You can describe tendencies, bound the blast radius, and measure success rates on a sample. When someone asks "will it ever do X?", the honest workflow answer is "no, here is the code" and the honest agent answer is "we have not observed it in N runs, and here is the control that would stop it".

That difference propagates into everything: testing becomes evaluation (Section 24), monitoring becomes trace analysis (Section 25), and safety becomes containment rather than prevention (Sections 27–28).

The autocomplete lineage

It helps to remember what the underlying machine actually does. A language model predicts likely continuations of text. That is it. Everything agentic is built on top of that one capability by arranging for the "text" to include descriptions of available tools, and by having a program interpret certain continuations as instructions to call them.

There is no planning module. There is no goal representation. When we say "the agent decided to search the codebase first", what physically happened is that the token sequence describing a search call was the most likely continuation given the context. This is not a reason to dismiss agents - the behaviour is genuinely useful - but it explains a great deal about how they fail, and it is why Section 10 treats the context window as the primary engineering surface.

What we are not going to do

We are not going to argue about whether this is "real" agency, or whether the model "understands". Those arguments produce no code. The definition above is useful because it is operational: given a system, you can determine whether it fits, and the answer changes how you build, test, and secure it.

Try it yourself

Take three systems you have used or read about and classify them:

1. An IDE feature that suggests the next line of code.
2. A customer-support bot that answers from a knowledge base, and can escalate to a human if confidence is low.
3. A tool you give a bug report to, which reads the repository, edits files, runs the test suite, and opens a pull request.

The first is a completion. The second is a workflow with a branch - the escalate decision is one if in someone's code. The third is an agent: nobody wrote down which files it would read.

In the next lesson we will make this less binary, because in practice autonomy is a dial rather than a switch - and knowing which setting your problem needs is most of the design work.

Cut through the marketing and arrive at a definition of "agent" you can actually test a system against: a model in a loop, with tools, and a stop condition.