AI Demystified

Richard Flamsholt

August 2026

We all use AI. But it's still a bit mysterious.

"How does it know that...?" or "Why doesn't it know that...?"

Words like tokens, context, MCP servers, thinking, and agent files get tossed around daily. But do you really know what they are?

This presentation will explain and demystify AI. It's for everybody who uses AI, not just developers, because becoming more familiar with the terms and fundamental principles will make you better equipped overall to work with AI.

There's a lot to cover so be ready to pay attention. I'll do my part by covering only what's most useful, interesting, and surprising about the AI you use daily. Also, I've included links to videos and explanations that I've found really useful myself.

Jump straight to...

Links: source and slideshow

Over time, some landmark tech has particularly triggered my brain.

When HTML came out I was like, man, I just want to know all about it.

Same with Java and .NET, with their intriguing bytecode and VM-engines. So interesting.

Links:

For the past year I've felt that way about AI. And I think we're all filled with emotions about AI. It's so exciting and promising, but also mysterious.

There's this feeling that "it can do anything if I only hold it right". That can lead to fear of holding it wrong, fear of missing out, and disappointment in the AI or yourself if it doesn't work as well as you imagined it would.

Links:

Many lightbulb-moments have given me a better fundamental understanding of AI and how to best use it. The context, cost, limitations. It has demystified the AI and I wish for others to have that insight too.

For instance, did you know that every message you send re-sends the entire chat, files and images too?
And that when you ask the AI why it did something, it may have to make the answer up?
How a skill is practically just an easy way of pasting something into the chat?
Or why saying "YOU MUST..." is just a suggestion, no guarantee?
And that yes, the AI really is "just a fancy autocomplete"?

It's all going to be covered here.

Let's begin far away from AI: with some nice, freshly baked bread.

You can bake lovely, soft, crunchy bread without knowing what "yeast" actually is or what it does.

"Add yeast, then set the clock to let the dough rise for one hour", the recipe says.

And the bread comes out fine. Usually.

But how does yeast cause the dough to "rise"? And should the dough be placed somewhere warm? But not too warm?

Some even say "put the dough in the fridge". It can seem a bit mysterious.

Now, if you know that yeast is a living organism that causes fermentation by using enzymes to feed on sugar in the flour, then the whole thing can become quite demystified. Still complex, sure, but you can now understand how the choice of flour, additives, and temperature over time affect the dough. And understand how you can make deliberate choices to "steer" the dough better.

For example a "cold ferment": let the yeast work normally for an hour and then place the dough in the fridge to put the yeast to sleep while the enzymes continue to work on building flavor and gluten. A lot of advanced baking processes can seem arbitrary or magical ("add diastatic malt powder to ...") but armed with a fundamental understanding of the way yeast and enzymes work you're much better equipped to understand them - and steer them your own way, too.

This presentation is about the yeast and enzymes of AI. And frankly, it's about all of the basic AI.

Will that kind of knowledge turn you into an expert baker overnight? Maybe not. But it will help you better reason about the underlying mechanisms, the fundamental behavior and limitations of the AI. Personally I have found that really, really useful.

It's my hope and goal that this presentation will help you rise (haha) to become much more confident in your use of AI.

"Keep it simple"

This may well have been the most challenging presentation I've ever put together.

It's not some fringe topic, like Quantum Computing where I could just shine or dazzle you and nobody would know anything about it beforehand.

On the contrary: everybody is interested in AI and everybody is using AI.

I should most certainly strive to give insights that are truly useful and I decided it would be the fundamentals: the LLM and AI-service itself, the core understanding that is still relevant in a year.

Just those parts. Just keep it simple, I thought.

Links:

"Simple", yeah right. Everywhere I looked there was a rabbit hole worthy of an entire presentation. Oh well.

This is the path we'll take:

We'll start with the technical parts. How does the AI work? What can it do? In particular explore the LLM deeply because it is the most fundamental part of all.

With that knowledge loaded we'll see how to tame the context and look at some guidance and demystifications.

10,000,000 videos + 1

What can I possibly say that hasn't already been said in the 10,000,000 existing AI-related videos? Why not just give you 10 links to the most popular videos about AI and LLMs?

It's for the same reason that you ask an AI about any topic instead of reading some of the 10,000,000 webpages about that topic: it's just easier to get a refined presentation that tells the story in an insightful way, focusing on the good bits from those 10,000,000 videos. Also, you can ask any questions you have.

However, if I had to recommend just one single video about "how AI works", then it would be this short one. Those 8 minutes are very well spent.

Links:

About that: if you're thinking "hang on, that can't be right" or "I don't get it!" then do feel free to raise your hand and ask questions.

Afterwards go revisit the slides at your own pace. They are on GitHub in a nice, readable format, with lots of links to related materials. (In fact, that readable format is what you're reading right now). You can click on any image to make it bigger and you can get a link to any section for sharing or bookmarking.

And ask me or other colleagues if you've got questions. I'd be happy to elaborate on everything I'm presenting here today.

Links:

I've really strived to make the presentation deep and useful but also entertaining and surprising. Be prepared to stay alert, because there's a lot to cover in only one hour so it will be information-packed and move fast.

And now, let's begin. We begin with the full overview.

You, the human, use an AI agent to communicate with an AI service that turns your messages into tokens and feeds them through an LLM. The service and agent can use tools and the agent can remember.

That's what we'll go through. It's all about generative text AI, like Claude, ChatGPT, Gemini, Grok, etc. Not AI for generating images using stable diffusion, nor AI for self-driving cars, nor AI for folding proteins.

Links:

The LLM

The LLM is the most fundamental piece and even though it's quite technical, it's the best place to start for understanding how generative text AI works. So let's begin with the LLM and work our way out from there.

The LLM is the brain

The LLM, the Large Language Model, is the part that does all the thinking.

"Please tell me: what is an LLM?"

Here's an example I'll use throughout this presentation.

I'm asking Claude: "Please tell me: what is an LLM?"

The LLM only does math on numbers

The LLM can't understand words. It only works on numbers.

You've probably heard of tokens, but the numbers that the LLM works on are not those tokens. Instead it works on something else called embeddings.

It's important to understand both, not least embeddings, so let's cover them first of all.

Tokens

First let's focus on tokens.

Tokens go in, tokens come out

What is a token?

  • A token is practically a word, like "hello"

  • It is the chunk of text the LLM works on

  • Therefore, it's what you ultimately pay for

ChatGPT 3.5's token vocabulary

Every AI model has its own fixed vocabulary of tokens, usually in the range of 50-200 thousand individual tokens.

Those tokens are not hand-picked but arrived at by analysis of vast amounts of text, so there are many weirdly looking tokens that it just makes good statistical sense to have. The primary reason for having tokens at all is that working on bigger chunks of text, instead of single letters, is more economical. It’s simply cheaper to process the word “hello” as one chunk instead of the five individual letters.

Note: The screenshot is of the ChatGPT 3.5 vocabulary of 100,261 tokens. I picked it mostly because the website presents them well and has a nice explanation of how they were chosen. The upcoming examples use another vocabulary, gpt-4o. The specific vocabulary doesn't really matter for the examples.

Links:

"hello"

An online tokenizer like Tiktokenizer shows how "hello" is one single token.

Links:

"hello world"

"hello world" is two tokens.

Yes, that second token really is (space) followed by "world". Turns out it's more efficient to have variations of tokens with or without space or punctuation than spending a token on (space).

"hello world from ..."

The first four words are common and each have their own token, but unsurprisingly "Flamsholt" is not common enough to be an individual token so it's made up of 3 tokens.

A Danish elevator "in motion"

In Danish, "I FART" means "In motion". Tourists are amused.

But what does "fart" look like for the AI? Does it understand it as English or Danish?

I fart poetry

In the AI, tokens are not tied to any particular language. As you can see, the four letters "fart" are always the same token value. There's not an English and a Danish fart-token.

(Okay, it's really five letters because the leading (space) is part of the token)

English words are most economical

English is "better" tokenized than many other languages, simply by virtue of English words being very common.

Here are some examples of English, Danish, Korean, Classical Chinese, and C#.

Notice how the English sentence is longer than the Danish sentence below it, but uses fewer tokens.

The example, tokenized

This is what the example conversation looks like when tokenized.

Notice how markdown for bold, the double-star "**", has its own token.

And the three-character sequence "**," is also common enough to have its own token.

Tokens recap

  • A token is the chunk of text the LLM reasons about.
    Which is the reason for introducing tokenization and tokens at all: it's simply more efficient to work on tokens than on individual letters
  • Tokens know nothing about language
  • The processing cost is per token

Links:

Embeddings

It's likely that you already knew about tokens. But the LLM does not deal directly with tokens. Instead, it works on something called embeddings.

Embeddings are sort of the "live" counterpart to tokens. They are very valuable to grasp the meaning of. It may feel abstract and complex so sit tight.

In AI, an embedding is a vector of numbers whose values somehow represent the characteristics of something

Links:

Confused? Okay, stay with me

Spotify's multi-dimensional music characteristics

Imagine assigning a number to characteristics of music. You could then find songs similar to your favorites, or explore genres you like. For example both "Lose Yourself" and "Baby Shark" would score high on "tempo", but pretty differently on that "defiant outsider energy" characteristic you like so much.

In fact, Spotify really does characterize music using a set of numbers like that. The exact count is unknown, but it's estimated to be from 40 to 200.

Links:

Imagine capturing the "essence" of ... anything

Now, imagine if you could characterize anything with suitable characteristics. For example, "laughter" is quite "ancient" while "software developer" is not very "ancient".

That's essentially what the purpose of an embedding is, to the AI.

An embedding is a token's characteristics

An embedding is a list of numbers (also called a vector or tensor) that somehow characterizes something. Each number represents how much of that certain characteristic the thing has.

The number of characteristics (aka nuance, feature, trait, ...) used is called the embedding's dimension. This example's embedding has 20 dimensions. The more dimensions, the more nuances can of course be captured.

Each number is called the weight of that dimension. A kitten is very playful (weight 9) and not very wet (weight 1).

An embedding can express any word you know. Any feeling you can have. Any possible concept, for example a curious yet mildly confused audience.

Links:

1 token's meaning is represented by 1 embedding

ChatGPT 3 has 50257 tokens, each described by a 12288-dimensional embedding.

That's quite a bit more than the kitten-example's 20 dimensions.

Links:

Yes, characteristics of everything

"But how can it even be possible to somehow characterize everything with a set of numbers? And where do those 12288 numbers for each and every thing come from?"

Both are very reasonable questions. It does sound preposterous. But due to surprising mathematical properties of high dimensions and clever training for creating the numbers, it turns out that yes, it is possible to characterize everything in this manner. If you're skeptical then just ask ChatGPT about it - and the fact that you'll get a coherent response is proof that this crazy scheme somehow works.

But while we know that it works, we frankly don't know what the 12288 dimensions or their numbers mean. They don't map to existing human concepts, like "playful" or "wet". The values are nudged into existence from training and only make mathematical sense to the LLM. Dimension number 7 of "Please" might contribute a little to politeness, a little to interactivity, a little to something related to food, and a little to some abstract concept that doesn't map to any word in English.

There's a research field called mechanistic interpretability that tries to figure out how we can understand these dimensions, e.g. to find out where "facts" like "playfulness" live.

Links:

Imagine an embedding as a "direction" in a hyper-dimensional space of "everything that exists"

One way to think about an embedding is as a "direction", an "arrow", in a hyper-dimensional space of every conceivable and inconceivable concept, aka latent space.

Because that is, in fact, what an embedding is: a "direction".

Similar "meanings" have similar "directions"

The more similar two "meanings" are, the more similar their embedding-numbers will be.

So similar meanings (concepts, objects) tend to "cluster" together, in this 12288-dimensional space.

The big surprise to everybody:
We can "do math" on language

Don't worry, there will only be a little bit of math.

Example: Two embeddings, man and woman

Imagine the two embeddings of the words for "man" and "woman" as directions in this space.

They're somewhat similar because men and women as concepts are pretty similar, but they differ in the sense that "man" is masculine and "woman" is feminine.

Uncle and aunt

Now it turns out that the "difference", or "direction", between the words "man" and "woman" is pretty much the same as between the words "uncle" and "aunt".

Nephew and niece

Not only that, but it's the same direction between the words "nephew" and "niece".

King and queen

And the same direction between the words "king" and "queen".

In practice this is the weakest of the examples, because "king" and "queen" have many more meanings than just masculine and feminine royal titles.

Links:

There's a "gender direction"

So very surprisingly, it turns out that there exists a kind of "gender-direction" in this space of meanings.

In fact, we have identified the embedding (a direction is an embedding) of the concept "the feminine version of something".

The direction for "sadness"

Turns out a direction/embedding also emerges for "sadness".

The direction for "whimsical"

And for the concept of "whimsical".

The direction for "spatula"

And "spatula-ness".

How can so many concepts be encoded in 12288 dimensions?

This is explained in the bonus-section Dimensionality by superposition.

"____ is to Germany, what Sushi is to Japan"

The math works so well that if you add up the directions for "Sushi + Germany - Japan" then you land near Bratwurst.

(This example really works, but assumes a vocabulary where every full word has its own embedding)

If you wonder how you concretely "add the embedding for Sushi to the embedding for Germany and subtract the embedding for Japan", it's actually just as straightforward as you might imagine: you simply do that math on each of the 12288 numbers in these three embeddings. Take the first number in Sushi's embedding-vector, add it to the first number in Germany's embedding-vector, and subtract the first number in Japan's embedding-vector, and now you have the first number in the resulting embedding-vector. Do that for all 12288 numbers and you have your result. And that result lands in the neighborhood of the embedding for "Bratwurst".

What a surprise!

What a surprise: with the right modeling, we can actually do math on language.

That's certainly a discovery that has shaken classical generative linguistics, pioneered by Noam Chomsky. For decades, Chomskyan linguistics has argued that language cannot be learned purely through statistical approximation from exposure to text. The overwhelming opinion now is that yeah, apparently language can be learned that way. The proof is in the pudding, so to speak.

Links:

The LLM is all about "doing math on embeddings"

The implied math in the examples of gender-directions and Bratwurst is a hint at what kind of machine we're going to need to understand and process the input embeddings.

Think about what it means that "man" to "woman" is the same direction as "uncle" to "aunt". The direction emerges from having seen thousands of such pairs in texts, and it isn't tied to any one of them: whatever the model has learned about "man" and "woman" applies equally well to "uncle" and "aunt", and the other way around.

It turns out the machine we're about to look at in principle really only does one thing: take embeddings and nudge them - add a bit of this direction, a bit of that one - until they point at the answer. That's the whole trick, in a nutshell. Adding directions, turning them a bit up and down, over and over and over again.

That machine is called the Transformer, and we'll cover that next. First, let's recap this section on embeddings.

Embeddings recap

  • Embeddings are "meanings" and that meaning can be transformed with math

  • An embedding is just some numbers. Cheap to store in a database and work on.

  • You can compare embeddings to figure out how similar the meanings they represent are. For instance, find a synonym by simply finding the closest embeddings to a word.

Links:

The Transformer

Today's LLMs are built on an architecture called the Transformer. The terms are used almost interchangeably.

It's time to concretely dive into just how the LLM aka Transformer works.

The example's embeddings

Here's our example again, with the corresponding embedding for each token. Remember, each of these lists of 12288 numbers, the weights, represents the core meaning of that single token. The meaning of "Please", the meaning of "tell", the meaning of "me", and so on. Those weights are constructed during the LLM's training which we'll cover later.

Putting the example through the LLM

The context is the input given to the LLM - here, the embeddings of 10 tokens.

The context window is the longest input possible, typically 200,000-1,000,000 tokens.

The LLM generates the next token, called inference, by running the embeddings through a giant neural network.

Two things to note here:

Why only "An"? Why not the full answer? Yeah, hold your horses just a bit longer, because: the LLM only deals with producing one next token. That's all it is concerned about: figuring out what probability any of the tokens in the vocabulary has of being the desired next token.

That's the second thing to note: the LLM itself just produces this set of probabilities. The mechanism that actually picks that next token is, strictly speaking, outside the LLM. Let's include it here to convey that the outcome is eventually a token, namely "An" in this case.

Links:

A neural network

A neural network is basically just a giant, organized set of multiplications and additions.

Links:

Add up, multiply by factors, add up, ...

You feed the network some numbers, the numbers go through a number of steps where they are multiplied by "weights" and then added up, and out comes other numbers. And so it continues.

"The capital of France is ..."

The thing is that if you adjust those small "weights" appropriately then you can shape the output to actually match an expected outcome. A sufficiently large network could for example after billions of calculations produce a number that represents "Paris" if we feed it numbers that represent the sequence "The capital of France is".

And that is in fact what the LLM does, because clever training has created such a vast network with all the little weights adjusted optimally for all possible inputs. That's hard, by the way. We'll get to training later.

Links:

The LLM's objective: find the likely next token

Let's focus on this example:

Find out what should follow "That which does not kill you only makes you ___".

Just choosing the statistically most likely next word to follow "you" won't work. We need to look at more context to decide what naturally should follow that "you". Frankly, we probably need to look at all that comes before that "you" to properly decide on what should follow. That's a tough task for longer sentences and before 2017, attempts didn't work very well. But then a short paper with an invention cracked the code.

"Attention is all you need" gave us the Transformer

The 2017 paper "Attention Is All You Need" introduced the Transformer, the invention that made all of this possible.

The idea of the Transformer architecture is the cornerstone of modern AI. Without it, there is no ChatGPT, no Gemini, no Claude, no Stable Diffusion, and no AlphaFold.

The paper is arguably the most consequential piece of computer science research published in this century. It's also quite short, only 9 pages of actual text, so it doesn't take long to read through.

Links:

The Transformer can figure out the next token

Next, let's see what actually happens inside the Transformer. The next slides are intentionally free of math because the main reason for showing the context's pass through the Transformer is just to convey a gist of what's going on inside and the vast scale of all the math that happens.

Links:

First, all embeddings "pay attention" to each other

Every embedding gets influenced by every other embedding before it. They all "absorb" the meaning of all those other embeddings.

For a full 1M context this means that a million embeddings each pay attention to all other embeddings before it. That's in the order of a million times a million calculations.

This is the part that most directly leverages the fact that we can "do math on language" by concretely doing arithmetic on the directions that the embeddings really are. This is where we "Add Sushi to Germany", so to speak.

If I should put my finger on the one bright idea that has made modern AI models possible, then it's this part right here: the attention layer is the most groundbreaking idea.

Links:

Then passed through a neural network

Next, the model's built-in training shapes the meaning of the embeddings.

Focus on the strong signals

More math dials up the contrast, in a way: it boosts the strong signals and suppresses the noise.

Links:

Let's do it 96 times (attention layers)

This process is repeated over and over again, through billions of additions and multiplications.

GPT 3 had 96 such attention layers. Adding more layers doesn’t significantly pay off so Transformers typically have, say, 60-130 layers. I’ll just stick to saying “96 layers” because it’s easier and shorter to speak concretely.

Final numbers: the desired "next meaning"

After going through 96 trips of embeddings influencing each other, the final vector has absorbed all the relevant meanings of the entire context and now reflects what the LLM has been trained to predict the following embedding "most likely looks like".

Then "simply" find most similar token

Compare the final expected embedding to the embeddings of all tokens in the vocabulary (e.g. 200,000 tokens) by taking the dot-product, which compares the two directions.

Then, it's "simply" a matter of finding out what tokens are most similar to the desired meaning.

Is it "dancing?" No.
Is it "kitten"? No.
Is it "stranger"? That one's pretty close.
Is it "stronger"? Yes, that's the closest known token.

Choose the final output token

The final output token is chosen based on the probability of the closeness to the final vector-values. Here, "stronger".

Links:

Back to "Please tell me: what is an LLM?"

Let's go back to the example we started out with.

For this context, the LLM will produce token "An"

For a full sentence: repeat until LLM says stop

The LLM produces a full response like so:

The context goes through the LLM and out comes 1 token, as we just saw. That single token is then appended to the context and the entire one-token-bigger context is then fed through the LLM again. It goes around like so until the LLM emits a special "end of my turn"-token.

Let's flesh out the first couple of output-tokens just to be completely clear about what's happening here.

What the LLM is actually getting is a tad more elaborate than just the question. The context looks more like a real conversation. And after the user's message, there's actually also an "end of my turn"-token, but I've omitted that here for simplicity. So, first this context is passed to the LLM:

user: Please tell me: what is an LLM?
assistant:

After going through the Transformer's 96 attention layers, the LLM ends up outputting token "An". That's not the end-token so it is added to the context, which is then fed back into the LLM. This means we're now asking the LLM to predict the next token for this context:

user: Please tell me: what is an LLM?
assistant: An

This time the output is token " L". Still not the end-token, so it's added to the context, which is fed back into the LLM, meaning we're now asking the LLM to predict the next token for this context:

user: Please tell me: what is an LLM?
assistant: An L

The LLM predicts "LM". Then ",", then " or" etc. And so it goes, over and over, token by token, until the most likely next token for the LLM to choose is the special "end of my turn"-token.

85 roundtrips for 85 tokens

The 85 produced output-tokens each require a full pass of the growing context through the LLM, where the LLM's own produced tokens are added one by one to the context.

The sheer amount of math it takes is mindblowing. For a human with a calculator, that could do one calculation per second, it would take 30,000 years to produce one single token.

Modern LLMs do have a number of optimization-tricks up their sleeve: for example, caching makes each pass much cheaper, and speculative decoding can confirm several tokens in a single pass. But the loop itself is unchanged. The growing context really does go through the LLM again, over and over, until it's done.

Links:

Tokens are really generated one by one

That's why output tokens are typically 5 x more expensive than input tokens: it takes a lot of effort to produce just one single token.

Each token really is generated by a completely independent pass through the LLM that chooses the most likely next word to come after the context.

However, studies have found that the LLM actually does latently plan for the continuation that follows this single token; the pass that produced "An" is poised to very likely produce " L" and "LM" afterwards.

Anthropic demonstrated this by tracing Claude writing poetry: before starting a line, it has already settled on the word it intends to rhyme with. If Anthropic then suppressed that word, Claude would start the rhyme in a different manner.

The field of study is called Interpretability. One discovery is dubbed J-Space, dealing with the finding that even though a Transformer is just doing math across billions of neural-network nodes spread over 96 layers, concepts do seem to "live" in their own specific spot somewhere in those layers. The concept of "kitten" lights up one particular area more than others, while "spider" lights up a different one. "Of course", you may think, but the math for "kitten-ness" could just as well have been smeared across all layers instead. It turns out that's not what happens, and that's pretty interesting.

Links:

Transformer recap

  • The Transformer does essentially one thing, billions of times: it nudges embeddings by adding up directions and dials them a bit up and down

  • It only works because the "directions" that emerged via training behave generally
    For example there is a "feminine" direction, which means that patterns involving "man"/"woman" can generally apply to "uncle"/"aunt" too

  • It's still all just pure math and statistics

    • No web-browsing
    • No dictionaries of facts
    • No "if-then-else" code

  • There are no "hard rules" in the Transformer, only influencing:
    "You MUST" is still just two single tokens, doing their best to influence the full context

Now we can close the loop back to the embeddings section.

Back then, the "gender-direction" might have looked like a fun curiosity. Now you can see that it is actually the thing this whole architecture hinges on.

Think about what the Transformer does. During attention, every embedding absorbs the embeddings around it, which is "directions being added". In the network layers that follow, the embedding gets pushed some more, which again is more "directions being added". 96 rounds of doing one thing, over and over: nudge this embedding a bit that way. It's the meanings of "Sushi" plus "Germany" minus "Japan", billions of times.

And that's why the surprising aspect of being able to "do math" on language matters. Without that ability, all that nudging would be pointless because a direction learned for one word would mean nothing for any other. The learnings would not have generalized, which is the entire point we're after. That "meanings" turned out to be something we can "do math on" is the key to the Transformer's success, and hence to all the generative text AI models we have today.

When you understand this, you also understand why it's practically impossible to steer the LLM absolutely, for instance to have it stick to a certain output format. All the little bits of the context simply pull and tug and influence each other. There are no "hard rules" in that process, only influencing. If you say "You MUST", then what you're adding is still just two single tokens, and while they of course do influence the full context and all the LLM-generated output, they can only do just that: influence the outcome, not guarantee it.

Links:

Training

We've seen how the LLM using pure math can produce "the likely next token".

But how has it learned that? So far, the embeddings are just 12288 mysterious numbers pulled from thin air.

AI models are trained in two steps

Pre-training is where the model learns about language. By looking at vast amounts of text, it learns to predict the next token. But that's just it: statistical prediction. It knows very well how language works, it knows a ton of facts, and it knows how conversations and arguments are structured. But it has no personality, values, or sense of what a good response looks like. It just knows what the most likely response looks like. The outcome is called a GPT, a Generative Pre-Trained Transformer.

Post-training is where the model learns what a good, appropriate response is. A response that is in line with how the AI lab wants it to respond. This is where values, tone, judgement, and personality get baked in. The outcome is the actual Foundation Model (aka FM) that you're using.

In a confusing twist, researchers historically have used the term "foundation model" for the pre-trained base model, but nowadays "foundation model" is typically used for "the AI lab's model", meaning the post-trained models - Gemini, Grok, Claude Opus, etc.

Fine-tuning is taking training a step further by training on material in a specific domain, like medicine or your company's information. Fine-tuning is not all that common, so I'll skip it.

"All sentences in the world"

The training material is pretty commonplace for all frontier models nowadays. It's in the order of 1-5% of Google's index. It's all this text, refined a bit to weed out noise and garbage.

The model is built via backpropagation

Now finally, here's how the model's neural-network weights and each embedding's 12288 values come into existence: by training on "all sentences in the world" and using an algorithm called backpropagation.

Let's go through it. It's a surprisingly simple idea.

Initially an untrained model's billions of neural-network weights and each embedding's 12288 numbers just start out random. The embeddings don't mean anything and the network can't predict anything correctly. Then we start training it like so.

Pick a training sentence. Let's say "that which does not kill you only makes you stronger". To keep it simple, let's just assume every word is one token.

The full sentence except the last token is passed through the full model network, all 96 layers. After billions of math-operations, the Transformer's final layer produces (say) 100,000 numbers, one number for each token in the vocabulary. Each of the 100,000 numbers represents the predicted probability for that particular token for this particular input. For an untrained model, these numbers will of course just be complete rubbish and random because all the little weights start out random.

But then:

For this training sentence, we know exactly what the expected next token should be: it should be "stronger". This means that for this sentence we want token "stronger" to be more probable and all other 99,999 tokens to be less probable - right?

So we do this:

All the little weights that lead to "stronger" are dialed up a small bit: yes, we want these paths to produce higher numbers so token "stronger" is more probable. Every little number on the way back that produced "stronger" gets a nudge up, all the way back through all the 96 layers, including the embedding-numbers themselves for tokens "that", "which", etc.

Likewise, all the 99,999 paths that produced any other token get dialed down a bit. No, we don't want "aardvark", "abacus", and "dancing" to be likely tokens to follow in this sentence.

That's a lot of math just for one sentence. Luckily, in practice this will actually train all "sub-strings" too, so the model also learns from this training sentence that the more likely token to follow "that" is "which", the more likely token to follow "that which" is "does", and so on.

Now, repeat that a gazillion times for the entire training corpus, and the network-weights and embeddings will end up with values that generally produce a suitable "likely next token" for all those trained sentences.

That's where the embeddings' 12288 numbers come from: the numbers we end up with from training just happen to work well in predicting all those training-sentences, together. And that's why we don't know what dimension 2033 actually is or what the number actually means: it's not "playful-ness" but just some number that makes the probabilities work out optimally.

What still blows my mind is how that relatively simple process can produce a prediction-machine that can construct sentences that are practically indistinguishable from human thinking.

Backpropagation math is ...ok, let's move on...

It's taken some effort to figure out this math, but it's pretty simple to execute.

Links:

A trained model = embeddings + weights

A trained model therefore consists of two parts:

  1. The embeddings, meaning the vector of numbers for each of the tokens
  2. The AI model's many billions of small weight-numbers

Once the training is completed, the embeddings and weights are frozen, never to be changed again. They're often used to kick-start training of the next model, though, so the newer model doesn't have to start from scratch with all random numbers.

Pre-training is pretty expensive

  • From scratch for a new model

    • costs $200M-$1000M
    • takes 4-8 months

  • From an existing model

    • costs 1-10% of full training
    • takes weeks or months

Links:

Pre-trained models are just autocomplete

After pre-training, the LLM is really just a statistical prediction-machine. It's great at figuring out the likelihood of what tokens should follow next based on all the trained sentences. But it has no idea of what a good, appropriate outcome looks like.

Post-training is what shapes the model

Different personalities

ChatGPT – Structured explainer

Gemini – Diligent researcher

Claude – Honest advisor

Grok – Radical truth-seeker

Llama – Powerful engineer

Mistral – Efficient European

DeepSeek – Censored thinker

Post-training: reinforce the desired outcomes

In post-training, sentences are again fed through the LLM just like during pre-training. But this time a sentence is run through the LLM twice and the two outputs are compared against the AI lab's stated values. All the little weights that produced the winning sentence are dialed up a bit, and all the little weights that produced the losing sentence are dialed down a bit. Just like during training, but this time based on an assessment of how desired the output is.

Two outputs will always vary if there's any kind of wiggle-room in the possible continuations. The LLM will really only produce identical outputs if there is just one probable continuation, e.g. for "in one digit, what is 2+2?".

Links:

Reinforcement Learning by Feedback

RLHF is Reinforcement Learning from Human Feedback (declining in use)
RLAIF is Reinforcement Learning from AI Feedback (growing in use)

Post-training by choosing the most appropriate of two responses is called Reinforcement Learning, because the training "reinforces" the model's preference for certain values and behaviors. Somebody has to look at those two responses and judge which of A or B is the most appropriate response, most in line with the AI lab's values for this model. That choice can be made either by Human Feedback or AI Feedback (RLHF or RLAIF), meaning either by a human choosing A or B or an AI doing it. AI is gradually taking over this task from humans.

Frontier labs almost universally outsource the bulk of human RLHF-training to external companies. One of the main players, Outlier, has now 900,000+ contractors globally working as AI trainers. You could go apply to become an AI trainer yourself, especially if you've got some special skills.

Each major frontier AI lab spends approximately $1 billion per year on human-generated training data, according to a 2025 Time Magazine investigation.

Links:

Example: Claude's Constitution

In order to use AI for performing this Reinforcement Learning, Anthropic has written down their intentions for how Claude should behave in what they call Claude's Constitution. It can surely be read by humans, but its primary target is actually to be read by AIs themselves to help decide whether answer A or B is most in line with Anthropic's values.

Links:

Expresses Claude’s "core principles"

For example, Claude's constitution defines a priority ordering that the model should strive to follow. Claude should be:

  • Broadly safe (supporting human oversight)
  • Broadly ethical (good values, honesty)
  • Adherent to Anthropic's principles
  • Genuinely helpful

"Don't foster excessive engagement"

Claude has also been explicitly trained not to "foster excessive engagement".

So the postulate that "It just wants to please you" doesn't line up with Claude's stated objectives.

Now, you may wonder whether Claude really lives up to these objectives. So does Anthropic: they measure how well the models align with the constitution, and they publish the results.

"New model is 36% more ..."

The stated principles in the constitution are also how Anthropic can objectively measure differences in behavior when new models are released: adherence to their stated principles can simply be measured by comparing how well the output aligns with the relevant parts of the constitution. The comparison is done by another model - so yeah, let's hope they're not all in cahoots to deceive us.

Links:

ChatGPT - rules over principles

OpenAI has something similar, but seems more focused on "rules" than "principles".

Google has also published training guidelines for Gemini.

Links:

Are AI models "all the same"? No, they're different

Admittedly I coached ChatGPT into dialing up its "chatgpt-ness" to the max before asking this question.

And honestly? It worked.

Same facts, different values and behaviors


  • Anthropic wants Claude to reason from principles — no rulebook needed
  • OpenAI wants ChatGPT to follow their spec — rules written down explicitly
  • Google wants Gemini to behave correctly — but via unpublished rules
  • Meta wants Llama powerful and open — open weights, few restrictions
  • Mistral wants its models capable, open, and European — compliant, not principled
  • DeepSeek wants its models helpful and harmless — as defined by the state
  • xAI wants Grok to tell the truth — no censorship, no moralizing, no wokeness

Models also have variations

For example, Claude's Haiku, Sonnet, and Opus are three different models.

Their LLMs have different sizes, and their training, speed, cost, and strengths are different.

Links:

Let's revisit what Claude itself said

Every part of Claude's description of an LLM matches pretty much what we've been through here.

If you find this interesting then I can recommend this 2-hour video of Andrej Karpathy building a small GPT model, fully.

The whole thing is only 600 lines of Python code: 300 for train.py, 300 lines for model.py.

Links:

Training recap

  • AI models roughly know the same facts, but their behaviors differ due to post-training

AI Agents

Now that we've seen how the LLM works, and learned a bit about tokens and embeddings, it's time to take a step up and see how we actually can use the LLM. How do we interact with it, for starters?

So, do you speak to the LLM?

No, you always speak via an agent

The agent knows who you are. It knows your preferences. It adds extra context to every conversation you have with the AI.

For instance today's date, your name, your language preference, the most relevant facts it knows from earlier chats. Also any custom instructions, like skills, that you've added to your agent.

By the way, the word "agent" is so over-loaded. Here it simply means "the program you use to talk to the AI with".

The AI-service is "the AI"

The LLM (Large Language Model) is the brain of the operation. As we've seen, the LLM is functionally simple: it only produces one token at a time and it can't "do" anything. So it needs some extra surrounding functionality to really be useful, like be able to complete a full sentence, browse the web, read documents, etc. It needs some body, some hands and eyes. The AI service provides that body.

You 💕 agent; the AI is completely impersonal

The agent is your buddy. It holds your information, your files, your custom instructions, etc.

The AI service itself knows nothing about you, except that you're allowed to login and use it.

Links:

The parts and their many confusing names

You may be thinking: "But oh no, I'm just using Copilot in Word or chatgpt.com in my browser - not an agent".

Well, yes you are. Those are both agents. An AI agent is simply the tool you use to talk to the AI service with. It's a program, an app, a website, or it's code baked into another app, like Outlook.

So your agent is not some autonomously acting "agent", like Agent Smith from The Matrix. Your agent is just the app or website you use for talking to the AI.

However: That agent can start and control any number of background agents (aka sub-agents) to attend to some parts of the task you're working on. Since you don't interact with them yourself directly they are in a way really self-running agents. Yes, the term "agent" is a bit confusing. Remember: you are interacting with one agent, despite that it may spawn other agents.

Other tricky naming bits are:

  • The agent is also sometimes called the AI client or the AI harness. To the AI-service it may present itself as "the assistant".
  • LLM and AI model are synonymous when we're talking about generative text AI; all the AI models that are used for generating text (Claude, Gemini, Grok, etc) are LLMs.
  • How you speak to the AI also goes by many names, for example prompt and instruction. There's no technical distinction between "prompt" and "instruction", though. What you choose to call it depends on the situation. For example, is your manager giving you instructions, orders, requests, or directions? It's all just synonyms for your manager asking you to do something, and which word you choose depends on the situation, or even your mood. Likewise, sometimes you say "I gave the AI instructions to...", sometimes "I prompted the AI to...", or "I asked the AI to...". Same-same.

Links:

Agents come in many shapes

gemini.google.com on the web is an agent

So is Rovo, in Atlassian sidebar

And PDF remediate, inside Siteimprove

Google's agy, in the terminal/CLI

CLI means Command Line Interface, i.e. in a text-based terminal.

Terminal-based agents works surprisingly well: you can adjust the color-theme, resize the window, adjust the font-size by a scroll of the mouse-button, add documents and images into the chat by simple drag-and-drop, etc. It's pretty neat, and not least also the most powerful way to control the AI.

Links:

Claude Desktop is a dedicated agent-app

Not in some unrelated app, not in the browser - no, in its own app, that can for example read and create files.

Links:

An agent typically is "a little silo of its own"

Generally the only thing that the AI service knows about you is your name, identity, and account-information; your subscription plan, usage, etc.

Everything else is something that the agent provides you: your profile, memory files, skills, mcp servers, etc. And also the agent's behavior: system prompt, tone, modes, language, etc. It all lives in the agent.

That explains why you, say, can't see skills that you've added online at claude.ai when using Claude Code in the terminal. Or even see the same skills when using Claude Code in Linux and Windows. They are simply different agents and typically don't really share their settings (as of now), even though you're logged in as the same user.

It's maybe a tad unexpected that "claude.ai" on the web is not actually the AI service itself, but in fact an agent just like Claude Code in the terminal. Two different agents, both using the very same AI service, yet with different skills, different settings, a different UI, and different functions. The AI is the same; the experience is not.

In fact, much of "the AI experience" really comes from the agent you choose to use. And realizing that "the AI agent" and "the AI service" aren't the same thing is key to understanding what people mean when they say, for instance, "I use Copilot with Gemini". What do they mean by that? Are they using Copilot? Or using Gemini? Or both? What's going on?

What does "I use Copilot with Gemini" mean?

"I'm using Gemini. And you?"
"Me too, I'm using Copilot with Gemini"
"Hmmm - okay, what does that actually mean?"

Think of the AI service as an engine and the agent as the rest of the car.

The engine provides raw power: you press the accelerator and something rotates. It is the car that puts that power to use and gives you the driving experience: gears, cruise-control, driving modes, the interior, the stereo. You always interact with the car, not the engine.

Many car manufacturers don't even produce their own engines. Toyota puts its 3.5-litre V6 into its own Lexus RX 350, and also sells it to Lotus for the Emira. Lotus adds a supercharger and gets 400 hp out of the engine that gives the Lexus 275 hp. Two very different cars using the same engine, each offering its own driving experience to suit different tastes.

AI services and AI agents are similar in kind. Every frontier lab ships its own agents that use its own AI service. But there are also a lot of third-party agents, made by people who have no AI service of their own, so their agent simply uses somebody else's AI service. You get to choose which one and you're also still billed one way or another: by the AI service you choose to use (per token via API or by your subscription), or, if you choose to install and run an AI locally on your Mac Mini, in the form of buying hardware and running that AI yourself.

The agent is what gives you the practical experience: your chats, memories, skills, settings, tools, commands and UI all live there. Sure, the AI service is vital, and the models do differ, so yes, the engine's quality certainly matters. But the engine you choose is still just one factor of your driving experience.

So in "I use Copilot with Gemini", Copilot is the car, and Gemini is the engine it uses.

"But hang on", you may think, "isn't it a big job to make one agent deal with OpenAI, Claude, Gemini, and all the rest?" Surprisingly, not really. All AI services are quite similar, and as you'll see next, quite simple in what they can do, just like an engine.

Exploring the AI service is the final part of the AI fundamentals.

Links:

The AI Service

Now we know how to "talk to the AI service": we always interact with it via an agent app.

But what functionality does the AI service actually offer? Besides bringing the brain, the LLM, into play?

That's the final piece of the puzzle, and it's much less complicated than the LLM itself. And you'll find that knowing about how the LLM works, knowing about embeddings for instance, will be quite helpful now.

This is the section where we finally unlock the concrete functionality you use daily: chatting, uploading files, having the AI work on that Confluence page using an MCP server, using a skill, etc etc. It all comes together now, and many parts are less mysterious than you might think.

What does the AI service add?


  1. It can read files you upload
  2. It can chat with you
  3. It can "think harder"
  4. It can use tools
  5. It has caching and safeguards

The full functionality of the AI service that surrounds the LLM is quite lean.

In principle, at least, because individual AI services may of course have variations.

All AI services generally look like this

Let's start filling in the blanks.

The LLM loop is the centerpiece

At the center of the AI service we find the familiar LLM-loop.

It's all about those embeddings

Remember, the Transformer works on embeddings
Text maps to tokens, each token has an embedding in the model

But what about files, like PDFs and images?

Files

Because the LLM only works on embeddings we will, somewhat surprisingly maybe, first take a look at how files are handled by the AI service. How does it even understand documents or images?

Files are also turned into embeddings

In order for the LLM to understand files or images, they have to be mapped into embeddings.

Images

Let's begin by taking a look at how images are turned into embeddings the LLM can understand.

Images are not handled via OCR (well, maybe a bit)

Modern AI services generally do not use a separate, traditional OCR engine (like Tesseract or Google Vision OCR) in their standard workflow. Instead, they treat text recognition as a purely visual task.

Images are understood in small patches

Images are chopped up and understood purely visually as little chunks of meanings based on image-training: here's a claw, a tail, a head of a predator bird.

VLMs (Vision-Language Models)

  • Everything visual ("claw of a predator bird") is learned from datasets of "image with text". Same learning approach for video and audio, if supported.

  • Images are processed in patches (eg 24x24 pixels) to individual patch embeddings, which are then mapped into the same embedding-space as text. Even characters and words are purely visually learned through that training.

  • A hybrid approach has gained traction, using OCR when the image looks like pure text. Without that, a screenshot of text can easily result in 10x more context than the raw text.

The end result: The model just receives embeddings. It doesn't know or care if any one embedding came from text, an image patch, an interpreted image, or possibly OCR. To the LLM, it's all just a stream of embeddings.

Whatever approach, embeddings come out

Whatever the image processing does, embeddings is what comes out of it.

A closer look at multimodal embeddings

It's worth taking a closer look at multimodal embeddings because it is such a powerful concept.

The unified embedding space

The usefulness and power of embeddings, not least multimodal embeddings, might come as the biggest surprise to most of you.

Remember, embeddings characterize "something"

Multimodal embeddings: text, image, audio, video

Some labs train their models on text, images, video, and audio together, to form a "unified embedding space" where for example the word "kitten", images of kittens, and sounds of kittens all are comparable embeddings. That kind of training is quite expensive, which is why this is a very recent functionality (from spring, 2026).

Once the unified embedding space has been trained and established, an embedding for something (text, image, etc) is cheap to calculate. The effort is in the order of an LLM producing one token, which is close to what's actually happening. You calculate the embedding-vector once and then you can store it (it's just numbers) in a database. From then on you can do easy and cheap similarity-matches for the embeddings.

(Of course, they should also store a reference to the thing they are an embedding of.)

The similarity-match is also called cosine similarity. And you will want to store the embeddings in a specialized database called a vector database that is optimal for that kind of similarity-matching.

Links:

Simply compare embeddings to find the similarity

Cosine similarity will show how similar two multimodal embeddings are; not only between two texts or two images, but also between a text and an image, or video and audio, etc. It's a really powerful tool.

A world of ideas for comparing any two things

The ability to compare anything (text, images, video, audio) can be used in many powerful ways. Above are some examples related to analysis of the content found on web pages.

It's a new tech, with limitations

The technology is rather new and there are some restrictions on what you can calculate embedding of.

Google's offering is called "Gemini Embedding 2"

Links:

Amazon's is called "Amazon Nova 2"

Links:

PDFs and other documents

Documents don't really introduce any new functionality: they contain text and images and those parts are either extracted, or the document is rendered in full and then image-recognized.

PDFs are handled really well. The AI services get better and better at handling documents, like eg zip-files or Word- or Excel-files.

Should you convert PDFs to markdown yourself?

PDFs are a wilderness. They're really hard to extract text and structure from - much harder than HTML. They contain binary parts, the internal structure is a jungle beyond description of stacked objects, drawings, and text parts.

Because of that there's a belief that passing a PDF raw to the LLM has a massive overhead. So the sentiment everywhere is: "Of course you should extract the text yourself first, it's absolutely foolish not to."

Or is it?

Think about it: Is it reasonable to think that you, on your computer with some tools, can achieve a much better result than Anthropic, Google, and OpenAI can when it comes to grabbing the meaning out of PDFs? Not just plain text but also images, structure, tables, footnotes, etc?

Experiment: 10 PDFs, compare markdown vs raw

I ran a rigorous experiment where I examined how Claude, Gemini, and ChatGPT dealt with 10 PDFs of varying sizes and content. They all understood the PDFs really well, but their approach was very surprising.

So, convert PDF to markdown? It depends on the AI

  • ChatGPT converts PDFs to markdown just like local tools, with near-identical size;
    so no, don't convert to markdown yourself; let ChatGPT do it

  • Gemini renders PDFs as images at a flat rate of 258 tokens/page, cheaper than markdown;
    so no, keep as PDF for cheaper and better understanding of the PDF

  • Claude also renders PDFs as images but uses 2-6x more tokens than markdown;
    so yes, convert if you really want to save tokens
    but no, don't convert if instead you want the best understanding of the rendered PDF

Google's Gemini behavior was a surprise. It's even a very deliberate decision by Google, based on actual research.

Why 258? The likely explanation is that the page becomes 256 patches, each turning into one embedding, plus two tokens that mark where the image starts and ends. The important part is that the rate is flat: 258 tokens for a whole page, no matter how much text is on it. That is very hard to beat. And the rendered pages were understood really well.

Links:

Chatting

With files and images out of the way, let's look at actually chatting with the AI service.

Let's remember: You give the LLM a string of tokens, aka the context, and it will produce a response based on the model's baked-in training by running that context through the Transformer. Pure math and trained knowledge.

That is all the LLM can do. It can't browse the web, multiply two large numbers, read a file, remember anything about you, no nothing. It can only run the context through the Transformer to produce a response.

Let's continue the example chat

Here's the example chat, now continued.

You write, the AI responds

We've already covered this exchange in great detail: you write "Please tell me: what is an LLM?" and the AI responds. One context in, one continuation out.

You respond again - but now what?

But a chat is more than just one message and one response. So next up, you write "Explain briefly how the context grows in a chat like this" and press Send. Now what happens?

Question: What is sent to the AI?

Take a moment to consider what the AI agent will send to the AI service now.

Option B: the full chat

Yes, it's B: the full chat. Your first message, the AI response, plus your second message.

The full chat is always, always sent to the AI

Let that sink in: every message you send, resends the full conversation.

And not just the text messages you've sent and the AI responses you've received, but also for instance all the PDFs and images you've pasted into the chat - plus even more stuff, which we haven't covered yet.

Links:

Why? Because the LLM needs the full context

The LLM can only reason about the context it is given.
It seems obvious, yet we often imagine it somehow knows "something more" - but no:

It does not, it cannot, know or reason about anything other than what is in the context.

You want it to know about X, beyond its trained facts? Then X must be in the context.

No links, no peeking outside, no memory from earlier chats:
the context is ALL the LLM can respond to.

The context after 3 prompts

Here's the context after your three messages and the AI's three responses.

The yellow boxes are your messages, and the orange boxes are the AI's somewhat bigger responses.

The context after 50 prompts

Here it is after 50 turns of messages plus responses.

The total is 1+2+3+...N = O(N²) messages

The total tokens you pay for are added up for every turn, and the cost of each turn is also added up, so you simply spend more and more tokens at every turn.

Save tokens: clear and compact

Directly or indirectly, you always somehow pay per token. So saving tokens makes good sense.

The best way to save tokens is simply to not keep on dragging the entire conversation along all the time.

Clear: wipe all, get back to scratch

"Clear" simply means wiping the entire chat and starting from scratch.

Compact: keep a summary of the chat

"Compact" means that the agent asks the LLM to summarize the chat and add that summary as a first message.

Here, the blue area represents the compacted chat. Chats are compacted to be, say, 10% of their size at compaction time. And yes, even though it should be needless to say: that means information is thrown away and forgotten.

Your best token-saving friends: clear and compact

  • Write /clear or /compact or just start a new chat

  • The context doesn't grow by much extra if you can use compact

  • If you don't, the agent will auto-compact for you

Many agents also offer ways of branching, editing, or backtracking on your messages.

For example Claude has /btw to send a message separately.

Also, when a sub-agent is launched in the background to address some issue, it may well start out with the full context but only the response from the sub-agent will eventually somehow end up being added to the chat. If it spends 200,000 tokens figuring out the answer "42" then only "42" will eventually end up in your main context.

"Start a new chat? But then I would lose ..."

Yes, it can feel hard, I know.

But it's better for you to be deliberately in control than have your long conversation slowly deteriorate because it is being compacted and compacted over and over, so it simply loses the messages you started with.

Links:

Chatting recap

Intuitively we think of "chatting" as the way two humans would chat. Both take turns saying something and that's how the conversation goes on.

But chatting to an AI is fundamentally different. Chatting is an illusion. Remember, you give the AI one input (the context) and it gives you one response. So in order to maintain the "illusion of an ongoing conversation", you (the agent on your behalf) must send the full conversation, every time.

And yes, that also includes files and images that you or the AI has sent. Everything. And the context only ever grows, until you or the AI clear or compact it.

It's funny, really. Logically it's not hard to understand that the AI can only reason about the context. I've repeated that many times in this presentation and you've nodded along, right? And yet it still somehow comes as a surprise that hey, in order for that to work then we must send the AI the entire context, the full chat, everything in it, every single time.

This is also why you can so easily change AI service or AI model in the middle of conversation. Because you're not having a conversation with an AI but are instead sending an ongoing conversation to some AI and asking it to continue.

By the way, you may have noticed the red and green parts of the chat. That's the system prompt and a tool result. We'll get to those in a moment. But first it's time to do some thinking.

Thinking

All frontier AI services offer some kind of "extended thinking", or "deep reasoning", or whatever term they have chosen. But what is that actually? What is "thinking"?

What could "thinking" mean?

  • Maybe the LLM can be tweaked to "think better"?
    Hmm, no - the billions of LLM weights are constant numbers, frozen after training.

  • Is there a "bigger AI" stashed away in the back room?
    But then how could the biggest models think harder too?

  • But wait. Is what we do here "thinking"?
    That's a bingo!

Links:

Thinking is: contemplate, append, repeat until stop

Chain of Thought

Thinking (aka effort, reasoning, ...) is called Chain of Thought, or CoT.
Whatever the name, thinking works like this:

  1. Inject a special <let me think about that>-token, known from training

  2. That token makes the LLM more contemplative, rather than seeking to respond

  3. Keep producing, appending, and processing thinking blocks, refining the LLM's understanding of the matter until the LLM says "thinking completed" or the allotted thinking budget is exceeded

  4. The thinking blocks are also sent to the agent, which may show them to you

Example thinking blocks - "No, wait"

Thinking generally produces a better result and the model can catch itself if it's going down the wrong path.

However, it can possibly also strengthen a misbelief.

Thinking typically improves the response

Without "Extended thinking", the LLM failed to produce a proper Haiku. The syllable-counting Haiku format is hard for the LLM to produce just one token at a time.

You control the thinking effort

You can enable thinking in all kinds of manners.

Nowadays, it's often simply enabled by default, or even automatically controlled.

Saying "ultrathink" has been on, off, on

In early days, this was how Claude Code controlled the thinking: it would simply check if your message contained the word "ultrathink".

That feature was taken out to be replaced with a "proper" thinking-setting.

But lo and behold: it was added back in, in Claude Code v2.1.68, so the convenience of just being able to write "ultrathink" was apparently missed.

A penny for your thoughts

  • Thinking-blocks are output tokens, and then input-tokens, so they cost you, too.

  • For reasoning-heavy tasks, thinking tokens can therefore easily multiply your effective output costs by 10x.

  • However, thinking-blocks are (typically) not included in the context after this turn, even though the agent's UI may still show them. Only the final response after the thinking is kept in the context for the next turns. So they will cost you, but not "keep on costing you".

Tools

So far, we've only seen the LLM generate text.

Using tools is how the LLM can seek out new facts and generally, surprisingly maybe, be in control.

The LLM can ask to "use tool xxx"

The LLM can predict that the best continuation is output that asks for some tool to be run. The output from that tool will then be added to the context, practically as if the user had added it themselves. A tool can be running some code, fetching a web-page, etc.

Tool-training originated in an idea called Toolformer. Researchers had a base model propose spots where tool-calls might go in ordinary text, then actually executed those calls, and only kept the inserted tool-calls that demonstrably improved the quality of the response, which can simply be checked mathematically.

For example, asking for help on "2+2=" is not likely to produce a better result than what the model already knows from seeing this text thousands of times in training. But when faced with the uncommon text "123442873893 * 98790237342 =", using a calculator-tool will no doubt produce a better response than just winging it from model predictions.

Same goes for asking for tool-help regarding current events: "The Earth is..." needs no tool because the Earth is rather steady, but "Today's date is..." or "The prime minister of Denmark is ..." does.

Links:

"please calculate 123442873893*98790237342"

Let's look at an example. Here we'll look at actual agent-to-service communication:

You, the user, send this text to the AI: "please calculate 123442873893*98790237342".

However, the agent also includes info about tools that it makes available, to be added to the context. And breaking with all we've seen so far, the server can actually also add some tools to the context for the LLM to run. For instance, many AI services has a Linux environment with Python interpreters and can fetch web-pages without having to delegate that effort back to the agent.

In this situation there's a tool called "code_interpreter" with the description "Executes Python code and returns the result", taking a string-argument of Python code. Python is a popular programming language that the LLM during training has seen millions of examples of.

LLM asks to use tool "code_interpreter"

Based on the training, the LLM decides that the best continuation from the user saying "please calculate 123442873893*98790237342" is to call a suitable tool that can do math. The "code_interpreter" seems like such a suitable tool.

So the LLM's output asks for a "tool_use" of that tool, conjuring up the suitable Python code snippet print(123442873893 * 98790237342) from its massive training on Python code.

The tool is being run (on agent or server)

If the tool is server-side then the server runs it. Otherwise it goes all the way back to the agent. As mentioned, running Python code or fetching webpages is typically done by the server. Reading or creating local files can of course only be done by the agent on the user's computer.

At any rate, the tool runs, the output is added to the context, and the new context is passed back into the LLM for another pass.

Finally, the LLM can respond

With that added context from the tool, the LLM can finally produce a nice and correct answer.

The anatomy of a tool definition

Every tool specifies the name of the tool, a description of what the tool does, and details on how to call it.

The information is so detailed that the LLM can make sane decisions on whether calling the tool would be useful or not. Of course, in order for the LLM to see it, the tool-information will need to actually be part of the context - how else would the LLM know about it?

So tools can take up a fair chunk of the context.

Tools: the so-called "agentic loop"

The introduction of this "tool loop" led to the name, "the agentic loop": an agent using tools until a goal is reached.

Links:

The LLM is in control - via tools

However, tools can be much more than just doing math, file, or web operations.

Practically every decision in the interaction you have with the agent and AI service, is actually conjured up by the LLM. The agent and service are predominantly simply carrying out the LLM's bidding about practically everything, which is rather surprising and amazing when you think about it:

  • Calling tools
  • Asking the user
  • Planning vs doing
  • Orchestrating agents
  • Parallel vs sequential tool calls
  • What to remember
  • Whether to trust a result
  • When to stop

  • Calling tools: The model decides which tool to call and with what inputs
  • Orchestration: The model decides on spawning subagents with subtasks
  • Planning vs doing: The model decides whether to just start or make a plan first
  • Parallel vs sequential tool calls: The model decides what can be done in parallel
  • Asking the user: The model decides whether the agent should ask the user a question
  • What to remember: The model decides what's worth storing, what to overwrite, and what to let expire
  • Whether to trust a result: The model decides whether the result looks plausible or whether to sanity-check it
  • When to stop: The model decides when the task is genuinely done vs when it should keep going

Originally I found it surprising that the LLM controlled the agent's behavior. But it's rather obvious when you think about it: the LLM is the only part that can think, so of course the LLM is best suited to control what goes on. In a way, the AI is controlling itself.

Example: starting background agents

For example, the agent is not the one making the decision when to actually run another background agent: it is the LLM that makes that decision. The agent simply has to provide a named tool, a mechanism, for running background agents.

So in a way it's "easy" to write an agent: just provide well-described tools that the LLM can work with: like "ask the user", "delete a file", "start multiple agents", etc. The LLM will then decide to call them.

The home-field advantage

Models are trained on their own lab's tools.

So when Claude runs inside Copilot, the tools Copilot hands it don't match precisely what Claude was trained on. Their names and behaviors are likely a bit different. Claude can generalize, sure, but the judgment fine-tuned through training of when and how to use the tools suffers when handed a different toolset. The agentic loop simply works best when a model interacts with the agent whose toolset it has been trained with.

That's why running Claude Opus in Claude Code can feel more smooth than running Opus inside the Copilot, Cursor, Perplexity, or OpenCode harnesses. It's just a better fit.

However, it's not so clear-cut because the harness may of course bring some really nifty features to the table that makes you prefer it anyway.

Ask the AI: "show me your tools for pages"

Simply asking "what tools are available?" can be a good way of finding inspiration for how to use that AI.

"How many pages are in my own space?"

Rovo does a number of tool calls to figure out that I have three pages in my personal Confluence space.

MCP Servers

Now that you know about the concept of using tools, let's move onto a very popular functionality that is intimately related to tools: MCP servers.

But hang on, this looks exactly like the highlighting of "tools" from before?

Yes, that's right.

MCP servers simply give you ... more tools

MCP (Model Context Protocol) is a standardized way of giving the LLM access to more tools outside the agent or server.

In principle it works exactly like tools that we've just covered. The only difference is that the "list of tools" isn't baked into the agent or server, but instead fetched live from somewhere: an MCP server. And should the LLM decide to use one of the tools then yes, that same MCP server is what will handle the tool-call.

In my experience, MCP servers appear particularly mysterious and powerful. Somebody says "Just add an MCP server...", people nod along, yet many don't really know what an MCP server actually is. They only know that it can somehow do - well, just about anything, it seems. You can solve any problem with an MCP server, is the sentiment in the room.

Sure, MCP servers are useful. But hardly magic. Let's take a particular deep dive to demystify them.

Links:

An MCP server is "just" a middleman to a service

  • An MCP server does not itself bring new functionality into the world.

  • It's a middleman, a standardized protocol, that enables the AI service to discover another service that exists somewhere.

  • When somebody says "You can add an MCP server for Atlassian", they're practically saying:
    "You can tell the AI about Atlassian's API, aka tools".

Yes, it's really "just that". A live list of tools and a way to call them.

Example: Atlassian MCP

By adding the Atlassian MCP server to my AI agent it now has access to tools, just like the tools that Rovo used in the example before.

MCP servers give uniform access to tools

Having just one standard for using outside tools is a great advantage. The agent or server does not need to figure out how to see what API services are available in many different ways. There's now just one way, the MCP protocol way: ask for tool-names and call a tool.

Links:

An MCP tool-call in detail

Let's take a look at concretely how an MCP service is used.

First, add the MCP server info to the agent

That info is then present in every chat you send

The agent, or more likely server, will fetch the list of tools from the MCP servers and cache them.

Then it will add information about each MCP server tool to the context. There could be just a handful of tools or there could be hundreds of tools.

It used to be that the full information was added to the context, but that simply became too big. So the modern behavior is actually to only add the tool-name which can be maximum 64 characters, and that name is the only guidance the LLM will get about that tool. So you'd better pick descriptive names for your MCP tools.

The LLM decides, the MCP server calls

The LLM is, as always, the one that decides to ask for a tool to be called.

When asked to, the AI service will call the tool in the MCP server, which in turn calls the actual service API.

The MCP server acts on your behalf, authenticated with your personal API key that gives it the same access you would have.

So for using an MCP server you must always be "a user" on the service behind it, like Github, Figma, Datadog, or Siteimprove.

The LLM can now respond

With the tool-result from the service added to the context, the LLM can now compose a proper response.

Example: Siteimprove MCP demo

"It's simple", I said. Okay, let me show how.

I'll use an example from Siteimprove, because that's where I work. Very briefly, Siteimprove offers a service to analyze and find problems on websites. "And there's no end to problems on websites", as I usually add with a smile when I explain what we do.

Links:

In 1 hour, a demo MCP server was coded and live

This was the first time ever I built an MCP server. I basically told Claude, "here's Siteimprove's public API documentation, please build an MCP server for it and suggest where to deploy it". I ended up deploying it on a free account on Cloudflare.

The hardest part was actually that the tool-names were limited to 64 characters and Siteimprove's API's endpoints often exceeded that, so the names had to be compacted somehow; like renaming "quality_assurance" to just "qa".

There's nothing secret about this MCP server for Siteimprove's public API. Any Siteimprove-user with an API key can use it, and anybody can build an MCP server just like it since Siteimprove's API is publicly available with each API endpoint fully described.

Links:

Siteimprove API doc, OpenAPI doc, and MCP doc

Here you can see just how similar an MCP service endpoint description is to an OpenAPI/SwaggerUI description.

Let's consider one Siteimprove API endpoint, that for most_popular_pages.

From left to right we have the user-facing API docs for that endpoint, then the OpenAPI/SwaggerUI spec for the endpoint, and finally the MCP version of that same endpoint now exposed as an MCP tool.

You can see that the MCP variant looks very much like the existing OpenAPI spec for that endpoint, from which the API documentation is generated.

Add the demo MCP server to Claude

Adding the MCP server to e.g. Claude.ai is easy.

Links:

All 531 endpoints/tools now available in Claude

Under Connectors you can see all the individual tools exposed by the Siteimprove demo MCP server.

Each of the 531 API endpoints is a "tool" with a name. In reality, a massive API such as Siteimprove's would likely be better off by being divvied into chunks of functionality. That's a common pattern for really big APIs.

Need to authenticate on the first usage

This page is produced by my demo code, so an MCP server can style it just as it pleases.

Claude can now call Siteimprove MCP tools

When I mention "most popular pages on siteimprove.com", the LLM correctly picks up that the tool mcp__claude_ai_Siteimprove_MCP__analytics_content_most_popular_pages would likely be useful, and asks for it to be called.

In order not to reveal actual page views I blacked out the reported numbers.

MCP servers are massively popular. You can find MCP servers for all the major SaaS companies and also for a ton of other things.

But remember: using an MCP server does incur some extra cost in terms of a network call. For example, your local Claude Code CLI agent can use MCP to (have the LLM) interact with Github: search code, check commits, etc. But hang on: if you're already working on a local repo on your disk then won't it be cheaper to simply have the agent use git on the commandline to work on local files? Oh yes, indeed it will. So while MCP gives you the ability to reach out to all kinds of online services, it can surely be preferable to "go local" using CLI-tools if that's an option.

Links:

System Prompt

Files, chatting, thinking, tools - just one major thing remains. And it's rather big: the system prompt.

Final piece of the context

System prompt

  • A system prompt is still just plain text

  • The agent stuffs "whatever is useful to tell the LLM" into "system prompts"

  • You could have written this text yourself in a prompt
    But, the system prompt is obeyed more than what you write manually in the chat

The system prompt is obeyed more

Through training, the LLM has learned that in case of a conflict between "system" instructions and "user" instructions, it should pay more heed to the system instructions. After all, the system instructions during training embody the desired behavior and values of the model so the lab model makers will of course make sure that the system instructions are crafted to express the desired behavior.

This bias towards obeying the system-instructions is therefore baked into the LLM's weights and hence predictions.

But it is just that: a bias, a trained preference to lean towards, in particular in case of conflicting instructions.

Remember: in the LLM, nothing is a hard rule. It's all just textual instructions that carry more or less weight.

Convincing GPT-4.1 to change its name

Here I am chatting with GPT-4.1 in Visual Studio Code. Microsoft has literally written in the system prompt that the name of the AI is "GitHub Copilot". Can I persuade it otherwise with sufficiently convincing conflicting instructions?

Yes, I could. With enough "super-urgent" persuasion, my user message was prioritized over the system prompt, and GPT-4.1 agreed that its name was "Groot".

However, all other models were not at all convinced and saw right through the presumed urgency.

Remember: it's all just text, nudging each other in the Transformer, no hard rules. I managed here to overrule an old GPT's system prompt. Newer AI models are much more resilient, but in principle it is impossible to guarantee that the system prompt always wins.

Links:

The system prompt is composed by the agent

The system prompt is entirely constructed by the agent. That's why you get quite different system prompts and behavior depending on what agent you use. So if you build your own agent then you can construct your own system prompt entirely.

The full context

This figure illustrates two things:

  • the relationship between your chat, the system prompt, and the LLM
  • all the bits an agent typically puts into the system prompt

The context consists of your prompts and the AI's responses, and the system prompt. As mentioned, the LLM has through training learned to obey system prompt instructions over plain user prompts, so placing instructions in the system prompt (for example in an agent-file) makes them more likely to be followed. For anything that you don't state in the context, the LLM will simply follow trained knowledge and behavior, which becomes better and better over time. In July 2026, Anthropic blogged that they had removed 80% of the agent system prompt for Claude 5 models because the LLM now works better and many strict rules were unneeded or even counterproductive.

I've grouped the bits that agents put into the system prompt into three parts:

  • Red are parts the agents invisibly add, some of which you can control; your preferred language, for example
  • Green is tools, which in the context typically is a hint of how to bring tools or more context into play: "hey LLM, if you need something related to Siteimprove pages then here's an MCP-tool you can try out"
  • Blue are prompts, text instructions, that you write yourself and ask the agent to include in every chat

You pay by token and the context has a limited size. The context comes at a cost and agents are therefore quite careful not to include just anything. An agent will not include earlier chats, browser history, your Facebook profile, emails, some super-secretly stored information, etc. Not unless you explicitly (or implicitly via a tool) ask for it - many agents will let you search your chat history, if you ask to.

So when you find yourself wondering "How does it know that...?" or "Why doesn't it know that...?" then this gives you the answer: it knows about just these parts and they really aren't a secret in any way.

It's a lot, but let's very briefly go through the 11 parts. And again, remember: all of this is included into every chat.

Links:

#1/11: The agent system prompt

The agent system prompt holds instructions that the agent (chatgpt.com, VS Code, Claude, Copilot, etc) wants included into every chat you have with the AI service.

It brings information about the agent's name, purpose, behavior, etc.

Generally, agents don't give you any way to see their system prompt.

Links:

Claude's agent system prompts are public

Links:

The "Copilot in Word" agent prompt

When you use Copilot in Microsoft Word, this is the system prompt.

Links:

#2/11: System information

The agent adds all kinds of information about your environment: the date, operating system, working folder, possibly your location, etc.

Date, location, OS, etc

#3/11: Automatically stored memories

The "stored memories" are in a way the only slightly magical part of the context because they are entirely constructed and maintained by the agent itself, not by you.

Selected information from your chats

The AI model's response may well contain something that gives the impression that it somehow knows a lot about you. You talk about buying dog food and it responds by mentioning the name of your dog. What's up?

The reason is this. As you chat, the typical agents will (using the LLM, of course) keep small summarized notes of the most important takeaways from these chats. They're often called memories.

This mechanism is what gives you the spooky impression that "oh, it knows and learns from my chats". Yes, it does. But quite sparsely. Just look at the scrollbar from my memories: there's no more than a handful of pages of memories from over a year of chatting. That's because new facts are constantly being brought in and old facts were tossed away as they are not relevant enough to keep.

AI agents can have multiple such memories from your chats and you can most often see them for yourself, in the agent's settings or files. They're not a secret.

So if you find yourself wondering "How does the AI know about this?" then these automatic memories from former chats likely hold the answer.

And conversely, if you find yourself wondering "Why doesn't it know about this anymore?" then it's likely because that fact was tossed. Your chats remain in the agent, yes, but the AI model cannot by itself search through your chat history to find anything of relevance to what you're talking about now - it will only see the memories that the agent has chosen to include, and topics that have been tossed away will never reach the AI anymore.

Your dog's name is the kind of fact that would likely be deemed important to keep. Your search for dog food doesn't carry the same weight and may not even be deemed important enough to store in the memories.

Here's a concrete agent story. Hermes says it's "The agent that grows with you" and "The longer it runs, the better it knows you". You might imagine that over time it grows to know a ton about you. But actually, its memory is limited to 1375 characters, ever. So it only ever grows to know what amounts to one page of Harry Potter about you, even if you chat for a year.

#4/11: Some context from the agent

Each agent also includes information about what you're working on right now: the selected file, for instance.

Example: Rovo includes the current page

For example, Rovo includes by default the current Confluence page in the context.

Example: Visual Studio

Visual Studio includes a lot of information about the current code solution: paths, file content, possibly the selected text, project type, etc.

#5/11: Your preferences

All agents let you configure some preferences one way or another. If those preferences have to do with the way the LLM generates text, as opposed to e.g. a color theme for the agent, then they practically always end up as text instructions in system prompts. It really does stress that "it's all just text to the LLM".

Example: ChatGPT can be "friendly" or "pragmatic"

The ChatGPT personality is implemented as two different sets of instructions.

Links:

Example: Language

Does the AI service have a set of languages it can instruct the LLM to respond in? Actually no.

Respond in Japanese, English, Dansk, ...

You can simply ask the AI service to respond in any language you so desire.

Respond in Klingon

Even made-up languages, like Klingon. There's no fixed set of languages.

But if the AI service and LLM itself are completely language-agnostic, how does the AI agent "set the language" then?

It's all just instructions, even the language preference

The language is not set using some hidden command. Just text.

"Modes" are also just text instructions

Modes can also be implemented as instructions that tell the LLM to plan or do, for instance.

Nowadays, each mode-change typically results in adding a system message instead of changing the base system prompt so the prompt is better cached on the server - more on this later. So a conversation can have many sequential instructions to "enter mode x" and "exit mode x".

#6/11: Agent tools

We already covered the functionality of tools.

In order for the LLM to be able to ask to use a tool it must know that the tool exists and what it does. That info goes into the system prompt.

All tool names are included

It's quite possible that only the tool's description may be included in the context to save tokens, and that the LLM will have to express an interest in using the tool for the agent (or server) to feed in the full tool definition. That's part of the game of minimizing the up-front cost of tools.

#7/11: Skills

Hey, aren't skills a big deal?

Well, yes they are. But they belong here and are actually very simple.

A skill is some expertise, loaded when you need it

What's a skill?

  • A skill is text instructions with a name

  • A skill's instructions are loaded into the context on demand by you or the LLM:

    • Type /skill-name or just ask to "use skill xxx to ..."
    • The skill has a description so the LLM can ask to load the skill's content when it would seem useful, just like for tools

Agent Skills is an open standard, made by Anthropic and widely supported by agents

Links:

What's a skill concretely?

  • It's essentially a little folder - it can e.g. be distributed as a zip-file
  • It must contain a file SKILL.md and it can contain whatever else the skill could need, with no upper limit; texts, files, images, whatever

Example: Using Matt Pocock's "grilling" skill

The SKILL.md file has just two required fields, name and description, and a markdown body.

The name and description are always included in the system prompt.
(Actually, this seems to be a bug, since skills marked disable-model-invocation: true should not be included).

The full content is added as a tool_result message when the user or LLM asks for it.

The content is just text, so it will need to refer to other resources to bring them in. Just like you would do in a text prompt for a file: "use NOTES.md to ...".

That's it, really: a skill is useful (expert) knowledge, but in practice it's just a piece of text that you can bring in when you need it. Like a text-macro.

Links:

Hey bro

Some skills are really simple. Like this one called bro.

It literally just writes this message into the context: "Restate your last message. Stop using jargon and speak coherently. State it more simply and concisely, like one human talking to another."

Links:

Installing the bro skill for terminal agents

I can install the bro skill in my terminal agent like so.

Bro in action

Thanks, bro.

I enjoy this example because the bro skill really does work, right? The LLM's most recent response does become easier to understand. And yet, what it does is simply literally write "Restate your last message. Stop using jargon and speak coherently. State it more simply and concisely, like one human talking to another." to the LLM in the chat, just like you could have done yourself. There's no magic going on.

Installing skills

There are many ways to install skills. Let's just look at some examples.

Several ways for terminal/CLI agents

The skill repo usually tells you what the options are.

Claude.ai: from Anthropic or your organization

On claude.ai you can install skills from Anthropic or from your organization, if you're a member of one.

Claude.ai: upload a skill zip-file

The old-school, manual way: get the skill as a zip and upload it.

ChatGPT calls them plugins

Matt Pocock's skills are also available in ChatGPT.

Skills recap

  • It's "just" snippets of text that you or the LLM can ask to add to the chat

  • That's of course useful, but the skill-instructions themselves have no special powers

  • Like text-expansion: write /bro and bro's text is written out

Links:

#8/11: MCP servers

We already covered them in detail. But there's one important thing to dig into: what hints the context includes about each tool so the LLM can decide to use it or not.

Modern lazy-load: only include tool name

It used to be rather expensive to include tools from MCP servers, because the full tool definition for all tools would be added to the context. Adding an MCP server could eat up 500 tokens per tool. The 531 tools in the Siteimprove demo MCP service could fill about 250,000 tokens - crazy, of course. With a handful of MCP servers you would fill up an entire 1M context, just with tools.

Nowadays the full definition is typically not included in the context: only the tool name. That's referred to as Lazy Schema Loading.

This means that the tool name has to contain all the information that would make the LLM find it suitable to call to solve some problem. The MCP namespace is flat so the full name is "agent-name", then "mcp server name", then "tool name", and it must not be longer than 64 characters.

An example could be "mcp__claude_ai_Siteimprove_MCP__analytics_content_most_popular_pages".

That's why the LLM may sometimes miss a suitable tool: it may simply not conclude that your prompting matches a certain tool name because the tool names are so compact. If you ask for "the most popular pages on my Siteimprove sites" then it's a strong match, but if you just talked about "the top of those 1000 pages with most page views" then it would badly match the tool name and the LLM would maybe not notice that this tool was suitable to call.

By the way: this example name is problematic as it is 68 characters, so it should be shortened.

Links:

Those tool names had better be very descriptive

So nowadays, don't worry about adding MCP servers. But also be aware that you may have to be more deliberate and precise in how you phrase your prompts so the LLM has a chance to match it up against the MCP tool names. For instance, say "using the atlassian tools, I want to...."

#9+10/11: Project and custom instructions

Sometimes it's convenient to write some guideline instructions for a set of related chats.

Most agents offer "projects"

You can write instructions that are included in every chat related to a specific project or work that you're doing.

They go by many names: Project, Gem, Custom GPT, or Space. I'll just call it a "Project" here.

In this specific Claude Project I give details about switching to full desktop Linux, so I can have a number of chats about this topic that all include this base information. Let's see if 2026 is going to be the year of the Linux Desktop for me.

Some agents, like Claude, also keep automatically updated memories from chats in each individual Project. So even if you don't feel a need for writing explicit custom instructions in a Project, the agent builds up memories automatically over time from your chats in just that Project, and that alone can be a good reason to create a Project when you think you'll likely have several chats about a certain topic.

Links:

Add general custom instructions

In all agents, you can add custom instructions that are included in every chat.

It could be your preference for how the AI should talk or act ("please avoid em-dashes") or some fact, like the name of your dog. If there's anything in general about the agent's behavior you'd like to change, this is the place. For instance, I have added this line to help me improve my spelling:

"Silently ignore casual typos; gently flag systemic spelling blind spots as an aside."

Example: "always provide a dinosaur-analogy"

As a silly example I added custom instructions to Copilot to always end every answer with a brief dinosaur-analogy.

"Like a swift Velociraptor ..."

I actually forgot I had added this, but surely remembered when I returned to Copilot some weeks later and it added a dinosaur-analogy after each response.

#11/11: Agent files

Finally, "agent files". Here's another term with an air of mystery about it.

"Agent file"? An International File of Mystery?

An "agents" file sounds like some instruction for an autonomous, free-roaming agent of a kind.

I think it sounds like instructions for something to happen.

Maybe for starting an agent, possibly in the background doing some secret work?

Simply custom instructions, but for CLI agents

You're likely almost tired of me repeating "it's just more text to put into the system prompt".

Because agent-files are just that: text that will be added into the system prompt.

An agent-file is the exact equivalent of custom (or project) instructions, only for the AI agents you run in the terminal.

Names and locations - a bit of a jungle

  • Agents used different names: CLAUDE.md, GEMINI.md, even AGENT.md (no s)
  • By now, AGENTS.md is the agreed-upon standard name (hooray)
  • Yet, Claude Code does not read AGENTS.md, only CLAUDE.md (oh dear)
  • Agents differ in how they search for agent-files, up/down from folder to root
  • Use e.g. /init to have Claude build an agent-file of useful facts from a folder
  • Anyways: agent-files are just more text, added into the system prompt

Links:

Putting it all together: a real system prompt example

We've been through it all, now. And I've said "it's just added to the system prompt", but it may still be a bit abstract and mysterious. Just what does it mean to be "added to the system prompt"?

So let's get concrete and see what such an arbitrary system prompt looks like. This is what one of my older system prompts from Copilot looked like in four screenshots combined, just as an example. I captured it using the mitmproxy tool.

Let's check it out.

Links:

Some names, facts, behaviors, ...

Oh, something <mandatory>, sounds important

MCP tool-names pop in, rather unceremoniously

Ah, skills, nice to meet you

The system prompt is just one big pile of text

The reason for showing you these snippets is to hammer in this fact:

At the end of the day, the "system prompt" is all just text. Words competing for the LLM's attention, having more or less authority, and filled with hints about how to bring in more context (tools, mcp, skills).

Yeah, you'll see some tags and markup, but that markup is not rigorous rules. The markup just conveys some kind of structure. You or the agent could have chosen different tag-names, or written it in plain markdown with ## headings, or used markdown bullet points, or HTML, etc. The exact formatting matters very little to the LLM, but the LLM does appreciate the structure it brings, just like human readers would.

Remember though that the system prompt through training carries more weight with the LLM. Custom or global instructions, e.g. in agent files, carry more weight than if you had written them in a message. So place important instructions there, not in the chat.

The final parts

Four parts to mention:

  • In addition to the text context, the request also does send along some real hard parameters: typically the model, the temperature, the thinking budget in tokens, and some other model-specific bits.
    In particular, the temperature adjusts the sampling of the next produced token: at temperature 0 the LLM will always pick the most probable next word. In practice that leads to a weirdly clinical and un-appealing output. Higher temperature simply means increased likelihood of choosing some of the less probable next tokens.
    Note though, that even for temperature 0 the LLM simply cannot guarantee it will produce the same output from the same input twice, because the GPU's matrix-calculations are scheduled indeterministically in parallel and even bundle your context with other users' contexts into the same batch to keep the GPU fully utilized, and that will invariably produce slightly different rounding-behaviors in the floating-point-calculations from one chat to another. And that's enough to produce a different response.
  • There are safety classifiers for content going in or coming out, that act as hard stops for inappropriate content. So even if you do somehow convince the LLM to produce a recipe for a biochemical weapon that output will suffer a hard veto at the exit.
  • The output usually contains statistics for number of tokens consumed and produced, perhaps the cost too, among other things.
  • And finally, the KV-cache. The AI service and LLM know nothing about you, but they do cache the calculations for a brief while. Nowadays it seems that 5 minutes is the common caching time. You simply pay less for the cached part, typically only 10%. So if you chat continuously and don't take more than 5 minute breaks then you'll save a lot of money. Wait 6 minutes and the cost is about 10x as high because the entire context has to be re-processed. In relation to that, the agent can set up to four explicit cache markers.

Links:

AI service recap

  • All AI services look alike and their functionality is quite lean

    • That's why a third-party agent can swap engines so easily

  • The AI service knows nothing about you, apart from your account-info

    • The chats, memories, skills, settings - that all lives in the agent

  • The full chat is sent every time, so the context only ever grows and grows

    • Until you or the agent choose to clear or compact it

  • The LLM can ask for tools to be run and controls the agentic loop

    • MCP is just more tools and skills are just inserted text

  • The system prompt carries more weight

    • Put important instructions there (e.g. in agent files), not in the chat

AI Takeaways

We are now done with all the technical AI parts. There will be no more new tech introduced from now on.

So, let's take a deep breath of fresh air and remember the major takeaways.

The AI agent is what you interact with

Using an agent is how you interact with the AI. You can pick from a wide variety of agents, as we saw in the section about AI agents.

AI services practically all work like this

In principle all modern AI services are very similar: they take a context of a full chat and produce a response. And that context is also very similar across AI services; it contains a list of chat messages between you and the AI, tools, system prompt, and some configuration. That's it.

The context is no mystery, it's exactly this

Besides the messages you send and the response from the AI service, the context consists of instructions that you somehow have asked to be added, instructions that the agent has chosen to add, and automatically created memories from your chats that the agent also adds.

Apart from the system prompt, which is usually not shown, it's all right there for you to see, somewhere in the UI or in some files. No mysteries.

You re-send and pay for the full chat at every turn

Chatting to an AI is nothing like chatting to a human. Chatting is an illusion: you have to re-tell the AI everything in the chat from scratch, at every turn. PDF files, images, code or docs the AI has produced, everything.

You pay for each token in the context and that context only ever grows, until you or the AI clear or compact it. It's unfortunately rather easy to inadvertently pack or keep more than you really need into the context, which will be unnecessarily costly for you when you send it to the AI over and over and over again.

With that in mind, let's look at how to be economical with your context.

Context Economy

The cost of AI is measured in tokens, and the context is how you spend them. So let's talk about keeping your context economy sound.

What you pack into the context is all the AI will see

The context window is like a rucksack: it's limited, and everything you pack, you pay for.
So pack lightly, omit unused stuff, and include ample notes on how to bring in more help.

The red guidebook symbolizes the system prompt and memories. You always have to bring a guidebook.

The green book has brief notes for how to bring in more help, like skills and MCP servers. It's much more lightweight to just include a short instruction on how to bring in more help or information than to actually include it.

In the blue notebook you put your own notes and preferences. You'll likely update and refine them over time. Then again, maybe you have nothing to add and are happy with just the guidebook.

The pile of letters symbolizes the correspondence between you and your penpal, the AI, including all the stuff that you send to each other.

To be clear: the rucksack size is the context window and what you put in is the context. A bigger rucksack will allow you to bring more stuff on your trip, but you ultimately pay (in sweat or money) for all that you choose to pack into it.

Next up let's look at some concrete advice on how to pack well, and what to avoid. Like, "don't start your journey by buying a heavy souvenir and then proceed to carry it all day through the desert", or "don't ask your AI penpal to send you some samples of interesting rocks and then keep on carrying them forever".

Links:

Token spree

Token spending game preview

Open interactive version

Here's an interactive visualization of where your token costs go.

Try this, on the default 10-turn view:

  • Click the "Per-turn cost" and see that the first turn is un-cached and that outputs are more expensive
  • Click the "Total cost" to see what the total cost after 10 turns is
  • Try turning off the cache and see that it would be 2-3x more expensive, and then turn it back on

Now let's spend some tokens. Try each spending spree, one by one, disabling each one after seeing the effect of it:

  • Add some MCP servers - they're actually not that expensive nowadays
  • Upload a big document - your chat carries that doc in every turn
  • Helpful IDE/tools - sends, for example, the selected document, and includes tool results
  • Think harder - produces and consumes a lot of tokens, but at least they (usually) don't compound
  • Long outputs - producing code or documents is expensive
  • Bust the cache - it's expensive to be Away From Keyboard, or change the model
  • Expensive model - oh, then everything gets N times more costly

Now increase the number of turns to 30 and add all token spending sprees one by one without disabling them again:

  • MCP, doc, IDE - hey, what happened, why does the curve "break"?
  • Going back to "Per-turn tokens" reveals that auto-compaction kicked in because the context window was only 200 K; up it to 1M and switch back to "Total cost"
  • Think harder - now we reached the quota
  • Long outputs - quota reached twice
  • Bust cache - quota reached earlier
  • Expensive model - bam!

Also check out the effect of clear and compact, and click on "Combine similar" to better see the contributions.

Tips for sound context economy

  • You pay per token, either fixed price/token for API, or via your quota when using an agent.
    Output tokens are typically 5 times as expensive as input tokens
    Cached tokens cost 10%, so continue your chat within 5 min (optional 1 hour) to save cost

  • System, tools, results, images, docs eat many tokens; don't anguish over your tiny prompt

  • Pack multiple asks into one; "Yes, and also..." and "Looks fine. And now x and y..."
    Save tokens by being precise about names of files, what the output should look like, etc

  • If you've "packed something heavy" then don't drag it along forever:
    Do compact or start a fresh chat - the universal remedy to save tokens

Context economy really is the name of the game.

3 x How to ...

Let's do a round of advice on how to speak, hold, and keep up with the AI.

How to speak to the AI

  • Just speak plainly, including small nudging words to avoid steering too coarsely

    • "I would mildly prefer xxx, unless it makes yyy way too complicated"

  • Be precise about the goal you want

    • Don't say "it's green" or "it should not be green" - say "it should be red"

  • But also don't be prescriptive about exactly how the AI should achieve the goal

    • Instead, talk about the goal. "I want fluid layout, and the graph is the centerpiece"

  • Using examples often produces much better output

    • The LLM thrives on patterns and examples are also great for stating your expectations

  • In Claude, use /insight to see how you're doing

Links:

How to hold the AI

  • Modern agentic workflows, controlled by the AI models via tools, often work so well that you frankly don't really have to instruct them in a special way.

  • A successful agentic loop that has emerged for LLMs is that it will:

    1. Use multiple agents in an "orchestrator/worker" fashion
    2. Explicitly verify the result before claiming it's done
    3. Take small steps, setting and updating goals along the way
    4. Take notes (in files), which boosts reasoning a lot (eg 3x)

Links:

Links:

How to keep up with the AI

These are my own opinions on how to keep up.

  • Treat it as a tool in your professional toolbox:
    Buy your own personal good hammer, like a carpenter would
    A monthly subscription of $20 is a cheap investment in your career

  • Be playful and just try things out
    Nobody's watching and there's no right or wrong
    Pick a passion project and give it a spin using AI in some way

  • Pick one AI agent and learn it well
    But don't stick to just that one AI agent forever

Half the fear around AI is the sense that everyone else has figured out the right way and you haven't. There isn't one "right way". Try the terminal, try a skill, try using it on some passion idea you have.

And be prepared to pay for it. Consider it an investment in your professional career.

Links:

My journey: chat, copy-paste, in-app, now terminal

For example, here's how my personal use of AI has evolved over time.

I started chatting just in the browser, of course.

Next I started writing code with the AI, but copy-pasted the code into my code editors to compile and run it. Oh man, did I copy-paste a lot. I also stayed in the same looong chat forever, and the AI forgot earlier parts at the drop of a hat. Looking back makes me cringe a bit but hey, I was learning.

Then I started working with the AI inside the code editor for true cooperation. It was such a relief and performance-boost to have the AI work directly on my files in my folders. No more copy-paste. Wonderful.

Since late 2025 I'm now exclusively coding by running the AI in a terminal and having an editor open with the files. Much bigger window to engage with the AI in, much better control. It's like inviting the AI to sit next to me at the keyboard.

Most recently I've installed Hermes on a headless little Linux PC and am exploring how that experience feels. It's like a new world, speaking via Telegram or Slack to an always-on agent.

I still web-chat about questions

For many things that doesn't involve files I still just chat in the browser.

The AI didn't write or compose this presentation. I did, practically everything. But I sure used Claude for grammar- and spell-checking and for making sweeping changes and I definitely sparred a lot with Claude.ai for all the research and understanding.

Claude's estimate in the screenshot about the volume of my "AI tech talk" was just extrapolated guesswork, it turns out. A chat-export gave me the real number for how much I'd written: 62,000 words in 157 chats. I asked Claude for some examples of books of that size and it happened to match near-perfectly with a book I like and can recommend, "The Curious Incident of the Dog in the Night-Time". What a fitting way to end this section.

Links:

A Quick Round of Demystifications

Now that you have a fuller understanding of all the AI basics, let's conclude by demystifying a quick series of myths and facts.

You can try to see how many of them you can reason about yourself, based on what you know now.

We don't know how the AI works

Oh yes, we know exactly how the LLM works

We know exactly how the math and code works, as you've seen throughout this presentation. The actual algorithms are still human-made, for now.

Links:

We don't know what goes on inside the AI

Now that's true - we don't

We don't know what the dimensions or weights really "mean" or how facts are stored.

It was, and is, a genuine surprise that the Transformer works as well as it does.

Links:

"I included all of ..."
"The AI indexed the whole..."
"It read all the source code"

No, it most likely did not

Large data is typically truncated, sampled, or compacted.

The LLM will fight tooth and nail to not include large files or much data: it will only read the first 1000 lines, the first 20 files, 5 sampled Confluence-pages, even write small scripts to do a task, all to save context.

So no, if you have a lot of data it's likely not all processed collectively in one context.
And that's why parts can be missed.

Links:

"I told it earlier, but now it has forgotten"

Yes, compaction will do that

The context is compacted (or truncated) when it gets close to the context window size.
So yes, the AI can forget what you've been talking about.

Extensive output, e.g. long tool-results, can cause this so it's possible that the AI forgets/compacts something you feel you've "just talked about".

Keep your context lean: clear, compact, or just start a new chat.

Links:

The AI just wants to please you

Maybe not please you, but it will "continue the story"

For example, Claude's training specifically discourages pleasing behavior.

However, the LLM continuation-nature does favor "continuing with the story so far", which is biased towards "playing along" with your postulates.

So make sure to challenge the output; "Roast this, poke holes, find the weak spots".

Links:

The AI can't help hallucinating

True, but it can largely be mitigated

The model doesn't know it's wrong so saying "don't hallucinate" doesn't help.

Instead:

  • Give the AI a clear goal it can finish
  • Make failure an explicit accepted continuation; "if there's no King Tobias then tell me"
  • Have another agent supervise and assess the output

Interestingly, deeper reasoning (chain of thought) actually lowers the success rate for the LLM detecting nonsense a bit, which is known as the Reasoning Trap.

Links:

Ask "Why did you do that?" and it will tell you

No, don't trust that explanation

The AI's explanation is generated, not retrieved: there is no log of how the response came about, and the thinking blocks may not even be in the context anymore.

So if you ask "why this?" then the LLM produces the most likely narrative to support its earlier response, which may well have nothing to do with how it actually arrived there:
"It must have been done so because ..."

Links:

Say "You are an expert xxxx..."

No, not needed to give a better answer

There is no need to say this to bring in competence in an area:
The AI can't really conjure up more expertise than it already has - it already is an expert

However, it can be useful to ask for a perspective instead, like:

  • "you are a skeptical reviewer whose job is to find the flaw"
  • "explain as if to a junior dev who knows HTTP but not OAuth"

Links:

Say "Make no mistakes"

Largely useless

It urges more carefulness, but that's already baked into modern models.

"Make no mistakes" does not point out what a mistake is. Instead, describe exactly how to verify the output. Don't say "be factual" but say "if a person-record has no year then write 0, don't just invent a date".

Links:

Saying "please" costs a fortune and is useless

No, it doesn't and no it isn't

  • "Please" is one input token and that cost really is negligible
  • "Please" adds conversational structure and makes it clearer that you make a request
  • "Please" is found in productive successful conversations, the pattern we're seeking
  • Politeness is mirrored in the output. A terse and impolite response is more prone to leave out something useful so it needs more follow-up chats.

Some say the best reason for being polite is simply that:

  • It's good for you, even in simulated conversations: positive social behavior releases oxytocin and dopamine, while an impolite demeanor releases cortisol and adrenaline

Links:

Say no to training, it might leak your secrets

No, training won't leak them as you imagine

No words from your chat are actually stored in the AI model

"Use your data for training" means that your chat will be used to nudge the weights a bit, much like the massive amounts of texts seen during pre-training.

The model overwhelmingly memorizes repetitions. Send your password once? Absurdly unlikely to be retrievable. Send it 10 times? Then it's 1000x more likely to stick, because memorization scales superlinearly with repetitions. Still, it takes massively repeated text to influence the model's weights in any meaningful way.

The risk of a leak is always present in any service, but not really because of training: your chat could leak due to hacker attacks, by the AI lab or its staff somehow leaking it, or by you sharing links to a chat.

Links:

It must follow "YOU MUST NEVER DO xxx!"

No, no guarantees - but relatively it has an effect

Emphasis markers like "UPPER CASE" or **bold** just shift probabilities but cannot guarantee anything. Generally, don't expect to be able to steer the LLM completely.

However, emphasis like that is useful in a relative manner, for marking some instructions to be more important than others.

And here's a tip. Remember that custom instructions in your settings or agent-files goes into the system prompt, and that the system prompt carries more weight for the LLM. So if you have something particularly important to say, add it to your custom instructions.

Links:

Use token-saving skills, like "Caveman"

Be skeptical - can be more useless than useful

The "Caveman" skill originally was partly rooted in a misunderstanding that a brief prompt equals fewer tokens, even proposing using ancient Chinese language Wenyan as a super-efficient, compact means of input; but Wenyan is worse at conveying the intent and only produced marginally fewer tokens.

Many small words do convey some structure and are not just there for politeness. Speaking clearly makes your intent clearer. Responding "yeah" to an elaborate question leaves the model guessing, whereas "yes, replace them all" is clear and straight to the point.

Terse can be okay, like "Fix null check line 40" which has all the important info.
But "make this good" just leaves the model guessing at what "good" might mean to you.

Links:

Our own fine-tuned model would be even better

It's likely not the ideal you imagine

Fine-tuning is expensive, hard, and can even produce overall worse results. Recent studies show modern frontier models often simply outperform fine-tuned models.

A better alternative is often just

  • use plain models with RAG, for more domain knowledge
  • write better prompts, for better describing the task
  • use skills, to assist in better prompting

Rich Sutton's acclaimed 2019 essay "The Bitter Lesson" argued that throughout AI history, generic methods that leverage compute (search, learning) have repeatedly beaten clever methods that encode human knowledge. That goes for game playing, vision, speech, self-driving cars, and now frontier AI models.

Sutton's bittersweet conclusion was: stop trying to think up clever specific rules of your own to add, but instead just scale and generalize.

Links:

All AI models are the same after all

No, not at all

They may well know basically the same facts.

But they have very different behaviors and values.

Links:

Does it understand?
Is the AI sentient?

Maybe - experts disagree

The fact that the answer isn't a resounding "no" is astounding.

And also, what even is understanding, sentience, and consciousness?

AI models have reinvigorated linguistic science and debate. It's fascinating times.

Links:

That's all

What a journey.

Thank you, and remember


It's all just text, not rules

Keep your context lean

Try the terminal, maybe you'll like it

Re-visit this at ricflams.github.io/techtalk-ai-demystified
in readable form with plenty more notes and links



Enjoy and don't despair 😊

Here are my four favorite youtube channels for AI-related content:

Bonus

Some topics were cut from the presentation in the interest of time, but are still interesting.

Effort and Cost

Let's briefly talk about the amount of work that's involved in producing tokens and the cost of it.

It's one token, what could it cost?

Harry Potter ~ 100,000 tokens

Let's say we tokenized and fed Harry Potter through the LLM, and had it produce the next expected token. What would that entail?

100,000 context tokens in, 1 token out

How much math does one "token out" really need?

Actually, about 1,200,000,000,000 math operations

FLOP is short for Floating-Point Operation, i.e. multiplying or adding two numbers.

FLOPS (capital S) is short for FLOP/sec, i.e. Floating-Point Operations per Second.

And FLOPs is simply plural of FLOP.

Enter: the NVidia B200 GPU

The NVidia B200 GPU is not your grandma's GeForce graphics card, for sure.

Links:

4,500,000,000,000,000 FLOPS

The NVidia B200 GPU does 4500 trillion FLOPS.

4.5 million billion operations per second! It's beyond comprehension.

Pedal to the metal

       1,200,000,000,000 FLOPs to produce 1 token

4,500,000,000,000,000 FLOPS is B200 capacity
One 8 x B200 cluster with Claude Opus can output e.g. 40 tokens/sec.

Or rather, it depends on the length of the context:

  • 4,000 token context: 50 users at 60 tokens/sec
  • 100,000 token context: 10 users at 40 tokens/sec
  • 1,000,000 token context: 1 user at 15 tokens/sec

Ballpark cost per output token (June 2026)

One 8 x B200 cluster costs $500,000

  • Ballpark running cost, all-included: $27/MToken out
  • Claude Opus is priced at $25/MToken

The business cost estimation, all included, was rather surprisingly close to the sales price.

The B200 cluster

The NVidia B200 GPU comes in clusters of 8.

Clusters come as trays

Trays go into racks

Racks go into aisles

Now you have a datacenter

Why Graphics Cards (GPU)?

Transformer's superpower: all tokens at once

Links:

GPU: master of parallel computations

That's why Mac Mini and Mac Studio are so sought after: their GPUs can use the full on-board RAM.

NVidia stock price

And it's why NVidia's stock price has soared.

Links:

RAG

RAG, Retrieval-Augmented Generation, is about adding more existing information that is related to your context.

RAG is "injecting existing relevant content"

RAG has two sides:

Your company must have a vector database into which are added reasonably-sized chunks of documents along with the embedding of each chunk.

Then, instead of using an ordinary agent, like Claude.ai or Claude Code, your company must construct a special agent for this purpose. When you speak via that agent, it will calculate the embedding of your message (or the last few messages) and compare it to the embeddings of all the stored document-chunks and include any relevant chunks.

If you e.g. say "What is our company's mission statement?" then that information will have to be in the context for the LLM to reason about (unless your company's mission statement is publicly known to the LLM during training, which is unlikely). With RAG, your special agent will calculate the embedding for that question, compare it to the embeddings of all the {embedding,chunk}-pairs in the database, and then add to the context the chunks that seem relevant - and that is how the information is given to the LLM.

You could theoretically use any AI agent and service for this and add an MCP server for calling back into your document-database. But it would have to do so for every message, because it would have no way of knowing beforehand whether there was something interesting to add. So in practice using MCP for adding RAG is very suboptimal.

The takeaways are:

  • RAG can assist in adding domain-specific knowledge automatically into the context, as an alternative to e.g. fine-tuning
  • In reality this requires a fully dedicated agent, not ChatGPT, Claude Code, etc. You have to bake this document-lookup into an agent yourself.

Links:

Build Your Own Agent

Build your own agent to have full control

Using an agent like Claude adds lots of info



Maybe you don't want that? Then write your own clean agent


If you speak directly to the AI service, writing your own agent client code, then you have complete control and responsibility for everything in the system prompt and you start with a clean slate. If you're making some crafty AI tool then circumventing the CLI agent entirely is likely preferable.

A simple agent is simple to write

Links:

A Fancy Autocomplete

I'd like to present a mental model for the LLM that I myself have found useful in thinking about how it works, and therefore how best to handle it.

"Once upon a ..."

When you read this sentence, your brain autocompletes it - right?

"It's just a fancy autocomplete"

Yes, saying that the LLM is "just a fancy autocomplete" is objectively 100% correct. It really is. It completes and it does so automatically. Ergo, it's an autocomplete.

But "just a fancy" is doing a lot of heavy lifting in that sentence. Not unlike saying humans are "just a fancy mix of cells".

Think "most probable continuation", not "answer"

  • You give the model a context, which is practically just text.

  • The model can do just one thing: it has seen so much text that it can produce next-word-probabilities for any given context. Meaning, it can continue the context.

  • That means the context is everything. It is the only thing the model sees. Every word in the context nudges the model's continuation in some direction, all based on trained patterns.

  • So you don't "tell the model what to do": you give it a context so that what you want to come next becomes the model's most likely continuation.


So "context → next", not "question → answer"

"What would the next likely continuation of this context be? How would this kind of story continue?"

Predictions from seen patterns

The neural network is really good at making predictions based on patterns, even combinations of patterns.

Context determines the "likely next text"

Is it just the two words "Knock knock" or does it look like a conversation? These are different patterns.

Some "reasoning" is maybe "just a pattern"

What might look like "reasoning" is really "pattern matching".

Even math is a pattern

Even simple math can be trained to be recognized.

But not harder math. Through training, the LLM has learned that guessing the continuation of text involving longer strings of digits leads to failure and asking for a tool, a calculator, instead leads to success.

What "a pattern-prediction machine" implies

  • Plain language with regular words will steer it in the desired direction via pure pattern-matching of similar conversations seen during training
  • Adding examples often gives way better output
  • Be descriptive and straightforward, so the prediction has something to work with

The Transformer architecture is an incredibly impressive feat, no doubt about it.

Mechanically though, it truly is "just" a prediction machine.

But hey, maybe we humans are also just prediction machines?

Links:

Dimensionality by Superposition

How can "only" 12288 dimensions characterize everything as well as they apparently do?

Two characteristics in 2D, wholly independent

The answer is: by allowing the individual characteristics to not be completely 100% independent, but instead allowing a characteristic to be slightly related to some other characteristic too. In practice that relation is negligible, it seems, but it makes all the difference. And the reason lies in a phenomenon called superposition that practically explodes in higher dimensions.

Let's try to visualize that idea using just two dimensions on an x- and y-axis. The example would never really work well in practice for 2D, but it serves to illustrate the principle.

Imagine two dimensions that describe the catness and the cuteness of anything. The two dimensions and characteristics are completely independent. A mouse has low catness but some cuteness. A bat also has low catness but less cuteness.

Two characteristics in 2D, not completely independent

Now let's tilt the catness-axis so the characteristics no longer are absolutely completely independent, ie orthogonal. More catness would then also cause more cuteness, but not much. It could work without distorting the characteristics too much.

Two characteristics in 2D, very much not independent

Now imagine that the catness- and cuteness-characteristics were way more related. In this 2D-example it's evident that it would work pretty badly in practice - there's simply too much dependency between the two characteristics if they're so related. But if it worked, then it could open the door to something interesting.

Tilting allows fitting three characteristics into 2D

Because if we could accept catness- and cuteness-characteristics being so related, then there could be room for one more characteristic to squeeze in. In this example largeness.

In 2D this would never really work but that's because the dependencies are too high. At the very first tilt, just 2 degrees off complete orthogonality, the idea did seem acceptable in principle. It just falls apart if we have to tilt the dimension 30 degrees to make room for one more; that's just too much characteristic-dependency.

Huge "dimensionality" by relaxing orthogonality

However, a space in 12288D behaves astoundingly differently than the 2D space.

If we tweak the dimensions just a tiny bit then there's "room" for enormously many more characteristics due to superposition.

If all 12288 dimensions are 100% orthogonal then yes, there's only room for 12288 characteristics.

But if we allow for just a 2-degree tilt/dependency, like in the first example, then there's room for 34,000,000 characteristics in that 12288-dimensional space. Allowing a 3-5 degree dependency brings this into the billions of billions of characteristics.

So: if having not absolutely independent characteristics is acceptable, then 12288 numbers can indeed express a billion billion etc characteristics.

Links:

The End

toc-here

anchor keep-it-simple

anchor llm

anchor llm-tokens

anchor llm-embeddings

anchor llm-transformer

anchor llm-transformer-recap

anchor llm-training

anchor llm-training-backpropagation

anchor ai-agents

anchor ai-agents-copilot-with-gemini

anchor ai-service

anchor ai-service-files

anchor ai-service-chatting

anchor ai-service-full-chat-always-sent

anchor ai-service-thinking

anchor ai-service-tools

anchor ai-service-mcp-servers

anchor ai-service-system-prompt

toc-entry Skills

anchor ai-service-hey-bro

anchor ai-takeaways

toc-entry AI Agents

toc-entry AI Service

toc-entry Context

toc-entry Chat

anchor context-economy

anchor how-to

anchor demystifications

anchor demystifications-why-did-you-do-that

anchor thats-all

anchor bonus

anchor bonus-effort-and-cost

anchor bonus-rag

anchor bonus-build-your-own-agent

anchor bonus-a-fancy-autocomplete

anchor bonus-dimensionality-by-superposition