How LLMs Became Agents

Strip an agent back to its core and you find a large language model whose entire trained skill is predicting the next chunk of text - the next token, roughly a word or word-fragment - given everything it has been shown so far. You hand it a stretch of text; it returns the most plausible continuation, one token at a time, each new token appended and fed back in to predict the next. From this single mechanism, trained on an enormous corpus, comes the fluent, apparently knowledgeable, often genuinely reasoned text these models produce. It is astonishing what next-token prediction can do - but it is worth being precise about what it is, because the limits follow directly from it.

Three properties of the raw model shape everything an agent does. First, it is stateless: the model has no memory of its own between calls. Everything it 'knows' about your task in this moment is the text you put in front of it right now - the conversation so far, the instructions, whatever context you supplied. Close the window and the model retains nothing; it did not 'learn' your project. Second, it only emits text. It cannot, on its own, open a file, run a calculation, query a database or click a button - it can only produce words describing what it would do. Third, it is fluent whether or not it is right: because it is optimised to produce plausible-sounding text, it will confidently continue a sentence with an invented code clause or a wrong dimension exactly as readily as with a correct one. This is the root of what people call hallucination, and it never fully goes away.

Hold onto this picture, because it explains the division of labour to come. The model is where language and reasoning live - it is the part that can read a messy brief, weigh options, draft a specification, or work out what to do next. But it cannot act, cannot remember on its own, and cannot be trusted to be correct without checking. Every one of those gaps is filled not by a smarter model but by the code wrapped around it. The model is the engine; on its own it is a very powerful engine sitting on a bench, running but connected to nothing.

If the model can only produce text, how does an agent search the web, edit a drawing schedule or run an analysis? The answer is that the scaffolding gives the model's text a way to *mean* an action, and then carries it out. The trick is beautifully simple. The harness tells the model, in its instructions, that it has a set of tools it can use, and that to use one it should emit text in an agreed format - effectively, 'I want to call the search tool with this query.' The model, being a next-token predictor that has been trained to follow such instructions, emits exactly that text when it decides a search would help. The scaffolding is watching the model's output; when it sees a properly formatted tool request, it does not just display it - it actually runs the search, captures the result, and pastes that result back into the text the model sees next. On the model's side this is all still just text in, text out. On the world's side, a real action happened. (Lesson 1.2 opens up tools in full.)

The scaffolding does three jobs the model cannot do for itself. It executes tools - turning the model's text requests into real calls to search engines, file systems, software APIs, calculators, other programs - and returns the results. It manages memory and context - deciding what text to keep in front of the model each turn, what to summarise, what to store and retrieve later, so the model can hold the state of a long job despite being stateless (Lesson 1.3). And it runs the loop - repeatedly calling the model, executing whatever it asks for, feeding the outcome back, and continuing until the goal is met or a stopping condition is hit (the next section). None of this is intelligent in the way the model is; it is ordinary, testable, deterministic software - which is precisely why it is where an agent's *reliability* is engineered.

This is why two agents built on the very same underlying model can feel wildly different: one careful, well-behaved and useful, another erratic and unsafe. The model is the same; the scaffolding - the instructions, the tools it is given, the checks, the guardrails, the way memory is handled, where a human is asked to confirm - is different. A large part of the craft you are learning in this course lives in that layer, not in the model. When you configure an agent, choose its tools, write its instructions or decide where it must pause for your approval, you are shaping the scaffolding, and that is where you exercise control.

Put the model and the scaffolding together and you get the beating heart of every agent: the loop. It runs, in essence, like this. The scaffolding assembles the current context - your goal, the instructions, the tools available, and whatever has happened so far - and calls the model. The model produces text: either a step of reasoning and a request to use a tool, or a signal that it is finished. If it asked for a tool, the scaffolding executes that tool, captures the result, adds it to the context, and calls the model again with this new information. The model observes what came back, decides the next step, and the cycle continues - think, act, observe, adjust - until the model judges the goal met, or the harness stops it for hitting a limit, a budget, or a checkpoint where a human must approve.

This loop is what makes an agent qualitatively different from a chatbot. A chatbot is one turn: prompt in, answer out, done. An agent is that same model call placed inside a loop that can run many times, each iteration able to gather new information and act on it, so a single goal you hand over becomes dozens of internal steps you never individually issued. 'Research the precedents for a mid-size civic library and summarise what makes them work' becomes: search, read a result, search again with a refined query, read more, note a pattern, check a figure, draft a summary, review it - many think-act-observe cycles, driven by the model's own decisions within the frame the scaffolding sets. That is the autonomy people mean by 'agentic': not a smarter answer, but a *loop* that keeps going without you steering each step.

Seeing the loop clearly changes how you work with agents. It tells you why an agent can recover from a dead end - a failed search, a tool error - by observing the failure and trying something else, the way a one-shot answer never could. It also tells you where things go wrong: a loop can wander, repeat itself, pursue a bad plan with great persistence, or burn time and money going in circles, because nothing in the mechanism guarantees the steps are *good* - only that they keep happening. And it shows you exactly where your control points are: the goal and instructions you set at the start, the tools you allow, the limits and checkpoints the scaffolding enforces, and the verification you apply to what comes out. The loop does the work; you design its edges and judge its result.

Once you can see the seam between model and scaffolding, a lot of agent behaviour stops being mysterious and becomes diagnosable - which is exactly the practical skill a professional needs. When an agent produces something wrong, ask *which layer* failed. Did the model reason badly - misread the brief, invent a code clause, draw a faulty conclusion from good information? That is a reasoning or knowledge failure, addressed by better instructions, better context, a stronger model, or - always - your verification. Or did the scaffolding fail - the wrong tool was available or missing, a tool returned bad data, the context got too full and important information fell out, the loop ran away without a checkpoint? That is an engineering failure, addressed by changing the setup, not by arguing with the model. Blaming the model for a scaffolding problem (or vice versa) wastes your time; naming the layer points you at the fix.

The division also tells you where capability and where reliability come from, and they come from different places. Capability - how well the agent reasons, writes, weighs options, understands your intent - rides mostly on the model, and improves as models improve, largely outside your control. Reliability - whether the agent stays on task, uses the right tools, keeps the necessary information in view, stops to check, and does not act beyond its remit - rides mostly on the scaffolding, which is very much in your control and is where good agent design earns its keep. For a designer this is liberating: you do not need to build or understand the model to use agents well, but you do need to understand and shape the scaffolding - the instructions, tools, memory and checkpoints - because that is the part you actually configure and the part that keeps the work safe.

And it keeps the through-line of the course sharp. Neither layer carries professional responsibility. The model is a text predictor that is sometimes confidently wrong; the scaffolding is deterministic code that does exactly and only what it was built to do. Between them they can do a remarkable amount of the multi-step work around design - but the judgement about whether the result is good, safe and right for this project, and the accountability for it, sit with you. Understanding the machine is not so you can trust it more blindly; it is so you can direct it precisely and verify it intelligently, as the human who remains the author and the architect of record.