How to think
about LLMs
& AI agents.

There's a lot of mystique around AI agents. There shouldn't be. Underneath the buzzwords, the whole field rests on a small number of simple ideas stacked together - the five layers shown to the right of the title above.

This guide builds those ideas one at a time. Each module assumes only what came before it.

Mechanically, a Large Language Model does exactly one thing: given some text, it predicts what text most plausibly comes next. Surprisingly, doing that at huge scale can produce behaviour that looks like reasoning, writing, coding, and planning.

Think of it as autocomplete on steroids. Your phone's keyboard suggests the next word based on a few patterns; an LLM is the same idea trained on a library's worth of text, so its suggestions can stretch into whole paragraphs, code, or arguments.

During training, the model plays a guessing game billions of times: hide the next word, guess it, check, adjust. Each tiny adjustment makes it slightly less wrong. Repeat at vast scale, and the patterns it absorbs end up encoding grammar, facts, reasoning styles, and tone - without anyone ever programming a rule for them.

The finished model is, mechanically, a function: text goes in, and out comes a ranked list of likely next tokens with probabilities. To write a sentence it picks one, appends it, and feeds the whole thing back in to predict the next one. Word by word. This is called autoregressive generation.

Models don't read letters or whole words. They read tokens - chunks of text, roughly word-sized or smaller.

Common words are usually one token; longer or rarer words get split into pieces. As a rough rule, one token ≈ 4 characters of English, or about ¾ of a word. Try the live tokenizer:

The context window is the maximum amount of text - measured in tokens - the model can consider at once. Think of it as the model's entire field of view. If something isn't in the context window, the model genuinely cannot see it.

Critically, everything shares this one space: the system prompt, the conversation so far, any documents you've pasted in, the descriptions of the model's tools, and the answer it's currently writing. They all compete for the same fixed budget.

Forget the chat bubble for a moment. At the engineering level, an LLM is a plain function: you hand it text, it hands you text back.

If "function" is a new word - it just means a repeatable input-output box. Give it the same text, you get a similar response back. No state, no memory, no surprises hidden inside.

So how does a chatbot "remember" your earlier messages? It doesn't, really. The application re-sends the entire conversation history with every single turn. The "conversation" is an illusion stitched together by replaying the whole transcript each time. Concretely, the input is a list of role-tagged messages - this whole list is what people mean when they say "prompt":

This reframing is powerful. Once you see the model as a stateless text-to-text function, the path forward is obvious: if you want it to do more than chat, you change what you put in and what you do with what comes out. That is the entire job of building an agent.

Both "workflows" and "agents" combine LLM calls, tools and code. The difference is one thing: who decides what happens next.

In a workflow, you - the developer - wrote the steps in advance. The path is fixed in code. In an agent, the model itself decides the path at runtime: which tool to use, in what order, and when the job is done.

A model on its own can only produce text. A tool is a function you let the model ask you to run on its behalf - the way it reaches outside its own head to do something real.

Think of the model as a brilliant consultant in a sealed room. It can think and write, but it can't open a door. A tool is a bell the consultant can ring: ring this bell to look something up on the web; ring that one to send an email; ring the third to run a calculation. The consultant doesn't leave the room - it just describes what it wants done, and an assistant outside the room actually does it.

Some everyday tools an agent might have:

Here's the part that surprises people: the model never actually runs anything itself. You give it a list of tool definitions - each with a name, a plain-English description, and a schema for its inputs. When the model wants to use one, it doesn't execute code; it just outputs a structured message that says "please call web_search with query = …". Your surrounding program - the harness - reads that request, actually runs the function, and feeds the result back into context as a new message. Then the model continues with that fresh information in view.

Take a model. Give it tools. Put it in a loop. That loop is the agent. Everything else is engineering around it.

The harness keeps calling the model. Each time, the model either asks for a tool or declares it's finished. As long as it asks for tools, the loop continues - running them, feeding results back, calling the model again.

Once you accept that agents need tools, the next question is: where do the tools come from? Two approaches dominate. Both end up giving the model abilities it didn't have on its own - they just package them differently.

Here's where toy demos and production agents part ways. An agent that runs for many loop steps keeps piling things into its context - every tool result, every observation, every intermediate thought.

Picture the model's context as a desk. It can only fit so many papers before things start sliding off and the important sheet gets buried under the noise. Remember Module 02: this desk is finite and it's the model's only working memory. Two bad things happen as it fills.

1. Hard limit. You run out of room. The request fails or older messages get silently dropped.
2. Context rot. Long before the limit, the desk gets so cluttered that the model can't find what's relevant. Answer quality quietly degrades. This insidious decay is nicknamed context rot.

So the core skill is treating context like a tight budget. The mindset: keep the desk clean. Anything not needed right now goes back in a drawer (a file, a summary, an external store) where it can be fetched on demand. Try the visualiser below - each technique frees up working space.

The throughline behind every technique below: keep what's relevant in context; keep everything else retrievable outside it; load on demand. The six techniques fall into three families:

You rarely jump straight to a free-roaming agent. There's a ladder of patterns - climb it only as far as the problem demands.

The foundational building block is the augmented LLM: a single model call given tools, retrieval, and memory. Most patterns are just clever arrangements of that block. Each card below names a pattern and gives one concrete example.

You now have the full mental model. Here's the shortest path from understanding to a working agent - keep the first one deliberately tiny.