Applied AI Engineering
Chapter 1 · Inside a Language Model
AI Engineering30 June 20265 min readBerlin, Germany

What an LLM Actually Is

What an LLM Actually Is
Said Mustafa SaidAI/ML & Cloud Engineer

You can use a language model for months and never know what it does. You will still ship things. Then one day it invents a function that does not exist, contradicts itself, or ignores a plain instruction, and you have no idea why. So we start at the engine.

A large language model does one thing. It predicts the next token. Chat, code, agents, the whole field is that one trick run in a loop. There is no second mechanism hiding behind it.

In short: An LLM takes text, breaks it into tokens, and scores every token that could come next. A runtime picks one, adds it to the text, and runs the model again. A chat reply is that loop, a few hundred times over. The model is frozen and stateless, so everything else is something you build around it.

What It Is

To a researcher a model is an architecture and a training run. To you it is simpler. A model is a frozen function. Text goes in, probabilities come out. It does not learn while you use it. It does not remember your last call. You hand it text, it hands back a guess at what comes next, and it forgets you.

A token is a chunk of text, roughly a word or a piece of one. The model has a fixed vocabulary of them, maybe a hundred thousand. On every step it scores all of them and tells you how likely each one is to come next, given everything so far.

Try it
ThecapitalofFranceis
7 tokens24 characters3.4 characters per token
Approximate. Every model ships its own vocabulary, so the real cuts differ. The point holds either way: the model never sees your letters, only the chunks.

One thing is worth noticing while you play with that. Common short words survive whole, and a long or unusual word gets cut into pieces, which is why an invented word costs you more than a familiar one.

How It Works

Send it The capital of France is. The model does not look the answer up the way a database would. It scores every token in its vocabulary for how well it fits next. Paris scores high. A sampler picks it, adds it to the text, and the whole string runs through the model again for the token after that. It stops when it emits an end signal.

Rendering diagram…

That loop is the whole engine. A reply is not computed in one shot. It is this step run a few hundred times, each token drawn from a fresh score.

Three Things It Cannot Do

Read the definition again and the limits fall straight out of it. They are not flaws that a better model will fix. They are what a frozen function is.

It cannot learn from you. The weights were set before you arrived and they do not move while you chat. Correcting it in message four does not teach it anything. It only puts your correction in the text it reads on message five.

It cannot remember. Each call starts from nothing. The model that answers your tenth message is the same blank function that answered your first. What feels like memory is your application resending the whole conversation every time, and that is why a long chat gets slower and more expensive as it goes.

It cannot act. It emits tokens. It does not read your files, call your API or send your email. When a model appears to do those things, code around it read the tokens, recognised a request, and ran the real function.

Notice that all three sentences say the same thing from different sides. There is one function, it is frozen, and it only produces text.

Everything Else Is a Ring You Build

Here is the shape of the whole course, and it follows from the paragraph above.

If the model cannot remember, memory is something you build. If it cannot act, tools are something you build. If it does not know your data, retrieval is something you build. Every level from here adds a ring around a centre that never changes.

The model is a frozen core. Prompts, knowledge, tools, memory, guardrails and evaluation are rings you build around it, one per level of the course

This is worth saying plainly, because it decides how you debug. When an agent misbehaves, the instinct is to blame the model. Usually the model did exactly what a frozen next-token function does, and the bug is in a ring: the wrong text reached the context, the tool description was vague, nothing validated the output. The centre is rarely the problem. The rings are yours, so the bugs are yours too.

Why "Just Autocomplete" Misses It

The smart objection writes itself. So it is glorified autocomplete. Mechanically, yes. But look at what the word just is hiding. To predict the next token well across everything people have written, code, contracts, arguments, jokes, the model is forced to carry grammar, facts, and the shape of reasoning inside it. The rule is trivial. Meeting it is not. Simple rule, complex result.

So both things are true at once, and holding both is the point of this chapter. The mechanism is humble enough to describe in one sentence. What it produces is rich enough to build a career on. People who only believe the first half dismiss the field. People who only believe the second half expect the model to remember, learn and act, and are confused every time it does not.

Task: open any chat model and send it a line that stops partway, like The opposite of hot is. Watch it finish the token. You just ran the engine by hand.

Next we open the engine and look at how those probabilities are actually made, and at the knobs that decide which token gets picked.

Check what stuck

1What does a language model compute on each step?

2Why is calling an LLM 'just autocomplete' true but misleading?

3The model 'remembers' what you said three messages ago. What is really happening?