Before We Talk About Agents...

There are a few words that seem to appear everywhere once we enter the world of modern AI:

LLM. Generative AI. Tokens. Context window. Memory. Tools. Agents. MCP.

At first, they can start sounding like members of a very exclusive club that forgot to explain the membership rules.

The good news: we don't need to understand all of it at once. Before agents, orchestration, or architecture, we need to understand the thing sitting underneath all of it — the Large Language Model itself.

We'll start with the big picture and progressively zoom in:

Grab a coffee. This one's worth reading slowly — everything later in this cert leans on it. By the end of this article, we should have a mental model that we can carry into everything that follows.

---

1. First, What Exactly Is Generative AI?

Let's start with the broadest concept.

Generative AI refers to AI systems (or type of AI) that can generate new content in response to an input.

That content might be:

• text
• code
• images
• audio
• video
• structured data

We're focused on text-generating models like Claude.

Traditional Software vs. Generative AI

Consider a calculator.

We give it:

2 + 2

It gives us:

4

If we ask it again:

2 + 2

we expect:

4

There isn't much mystery involved.

We can think of traditional software roughly like this:

The developer defines the rules.

Now compare that with a generative model.

We might ask:

"Explain why the sky is blue."

The system doesn't have a simple rule saying:

IF user asks about sky
THEN return sentence #47291

Instead, the LLM generates a response based on patterns it learned during training.

A simplified picture is:

This difference is incredibly important:

• A calculator is designed around deterministic computation.
• An LLM is designed around probabilistic generation.

Think of it this way:

• Deterministic = Following a cake recipe exactly. We will always get the same cake.
• Probabilistic = Describing a delicious cake to a master chef who has baked thousands of cakes. The chef knows the general principles (flour, sugar, heat), but might add a pinch more vanilla or bake it a minute longer based on instinct. We get a slightly different cake each time, but it's always recognizably a cake.

Traditional software	Generative AI
2 + 2 always returns 4	Ask twice, get slightly different wording both times
Behavior is explicitly coded	Behavior emerges from learned patterns
A bug is reproducible	A "wrong answer" might not reproduce the same way twice
We can trace exactly why	We can only reason about likely why

We'll come back to that distinction later because it becomes one of the most important architectural ideas in this entire certification.

---

2. AI → Machine Learning → Deep Learning → Generative AI → LLM

These terms get used interchangeably in casual conversation, but they aren't the same thing. A simple nesting picture:

• AI — the broad field of building systems that do "intelligent" tasks
• Machine Learning — systems that learn patterns from data instead of having every rule hand-coded
• Deep Learning — ML using neural networks with many layers
• Generative AI — systems that generate new content, rather than just classify or select
• Large Language Models — models trained specifically to process and generate language

Claude is a large language model, accessed through Anthropic's products and APIs. We don't need this taxonomy memorized word-for-word — we need it so that when someone says "well, technically that's deep learning, not an LLM," we're not lost.

---

3. So... What Is an LLM?

An LLM is a learned system that generates language based on the patterns it has learned and the information available to it at the time of generation.

Let's make that concrete.

Suppose we ask:

"Complete this sentence: The sun rises in the..."

We'd expect:

"...east."

Why?

Because the LLM has learned strong patterns connecting those words and concepts.

Now give it:

"The customer requested a refund because..."

The LLM can generate a reasonable continuation based on language patterns and the context we provide.

Suppose we ask:

"Explain why our application is returning a 500 error."

Here's the catch: The LLM only has access to what's in that interaction. If we send just that sentence, the LLM does not magically know our logs, our database, or our deployment history. It doesn't automatically know:

• our database state
• today's inventory
• our internal business rules
• what happened in a previous conversation
• what our application considers a valid transaction

If instead we send:

"Here is the relevant log:
ERROR: database connection timeout

Explain why our application is returning a 500 error."

Now the LLM has something to reason with. Later, if we give LLM a tool that can fetch logs itself, the architecture changes again (much more on that in a later stage).

The LLM can only work with the information available to it in the current interaction, plus whatever capabilities the surrounding system provides.

The Surrounding System

The surrounding system is everything outside the LLM that helps it be useful—the context we feed it, the memory we give it, the tools we let it use, and the guardrails we place around it.

What the LLM alone can't do:

• Know our database state
• Know today's inventory
• Know our internal business rules
• Remember previous conversations (unless we give it memory)
• Take actions in the real world (unless we give it tools)

What the surrounding system can provide:

• A retrieval system that fetches relevant documents or logs
• A memory store that remembers past conversations
• Tools that query databases, call APIs, or take actions
• Guardrails that enforce safety and business rules
• Structured prompts that guide the LLM effectively

The LLM can only work with the information available to it in the current interaction, plus whatever capabilities the surrounding system provides.

This single sentence is the seed of everything we're about to cover: tokens, context, memory, and eventually tools and agents.

---

4. Tokens — The Actual Unit of "Reading" and "Writing"

We think in words. LLMs don't. They works with tokens — chunks of text, often smaller than a full word.

A token might be:

• part of a word
• a whole word
• punctuation
• whitespace-related text
• or another piece of the input representation

The important thing to know is:

Text goes into the model as tokens, not as human-level words.

4.1 Why Should We Care About Tokens?

Tokens have practical consequences.

4.1.1 Tokens Affect Context

Every piece of information we put into a model consumes part of the available context.

• More input means more tokens.
• More conversation history means more tokens.
• Large documents mean more tokens.
• Tool results mean more tokens.
• And the model's response also uses tokens.

4.1.2 Tokens Affect Cost

For API-based applications, usage is generally measured in tokens. In other words, API usage is priced by tokens, not words or characters.

So this:

can be very different from:

4.1.3 Tokens Affect Latency

More information generally means more work for the system. In other words, larger inputs/outputs generally take longer.

So:

This isn't an absolute rule for every system configuration, but it is an important architectural consideration.

So we don't study tokens to manually count them.

We study tokens because they determine:

• What fits — context window limits
• What we pay — API pricing
• How fast it runs — latency

Tokens are the fundamental unit that ties all of these together.

We're not learning tokenization to memorize a definition. We're learning it because the amount of information we send has real, practical consequences — and that idea leads straight into the next topic.

---

5. The Context Window — LLM's Working Desk

If there is one analogy to remember from this entire section, let's make it this:

The context window is the LLM's working desk.

The context window is everything the LLM can "see" while generating its next response — nothing more, nothing less. Every word we send, every instruction we give, every document we attach, and every bit of conversation history we include all sit on this desk. If it's not on the desk, the LLM cannot use it.

The Desk Analogy

Let's imagine we're solving a complex problem at a desk. Spread out in front of us are:

- instructions
- notes
- reference documents
- previous discussion
- data
- relevant evidence
- calculations

Everything on the desk is immediately available. We can glance at any piece of information in a split second. That's our working memory — the information we can access without getting up, without opening a drawer, and without interrupting our flow.

Now let's imagine the desk has a physical limit. We can only fit so much on its surface. Every new document we add means something else has to move.

What happens when the desk is full?

If we bring in a new document, we have to push something off the edge. That information is no longer available to us while we're working. We've forgotten it, or at least we've lost immediate access to it.

The same is true for an LLM's context window. When we exceed the limit, the system either:

What Happens	Explanation
Drops older information	The system truncates the oldest content to make room for new input
Rejects the request entirely	The API enforces a hard limit and returns an error

Either way, not everything can stay on the desk at once.

This is why token limits matter. Let's remember: 1 token ≈ ¾ of an English word — and every token takes up space on that desk. It's a rough guide, not a formula — this varies by language and how common the words are

What Actually Fills the Context Window?

When we say "context," we don't just mean the user's latest question. In a real application, the context window contains a mix of many things:

System instructions
        +
Conversation history
        +
Current user request
        +
Relevant documents
        +
Retrieved information
        +
Tool definitions
        +
Tool results
        +
Other application-provided information

Here's a concrete example of what a full context might look like for a customer support application:

The LLM can use all of this information to generate a relevant, accurate response.

But here's the catch: everything in that diagram consumes tokens. The system instructions, the history, the customer profile, the policy document — they all take up space on the desk. If we add too much, the oldest items start falling off.

Context vs. Memory — They Are Not the Same Thing

This is probably one of the easiest concepts to confuse, so let's be clear about it from the start.

Let's go back to our desk analogy:

Desk = Context

But where do all our other documents live when they're not on the desk?

In a filing cabinet.

Filing cabinet = Memory

So our mental model looks like this:

What's the Difference?

Aspect	Context	Memory
What it is	Information currently on the desk	Information stored in the filing cabinet
When it's available	Immediately available to the LLM right now	Available only when we retrieve and place it on the desk
How long it lasts	Only for the current interaction (or until it falls off)	Persists across sessions, days, or even years
Size limit	Limited by the context window (e.g., 200K tokens)	Effectively unlimited (database, vector store, etc.)
Access speed	Instant	Slower (requires retrieval)

Why This Distinction Matters

Let's walk through a real scenario to see context and memory in action.

Conversation 1 — the user says:

"I'm looking for running shoes. I usually prefer lightweight ones."

Our application stores this as a preference, separate from the raw chat conversation:

User preferences
----------------
Preferred category: Running shoes
Preference: Lightweight

Now the information lives in our filing cabinet (memory) — not on the desk.

Conversation 2 (the next day) — the user returns and says:

"What do you recommend?"

Here's what happens:

1. Our application (our orchestration code) looks in the filing cabinet and retrieves the saved preference
2. Our application places it on the desk (injects it into the new context)
3. Our application sends everything to the LLM along with the current question

Notice what happened. The LLM didn't need the entire conversation from yesterday. It needed the relevant information from yesterday. That's a much better architecture.

The LLM doesn't need to carry the entire original conversation forever — our application decides what's relevant enough to bring back from memory into the current context.

Who Decides What?

Let's be crystal clear about this:

Decision	Who Makes It
What to store in memory	We do (the application)
When to retrieve from memory	We do (the application)
What's relevant enough to bring back	We do (the application)
How to format it for the context	We do (the application)
How to generate a response using that information	The LLM does

The LLM doesn't decide what to retrieve. The LLM doesn't know the filing cabinet exists. We build the retrieval system. We decide what information belongs on the desk. We curate the context.

The LLM is the engine. We build the surrounding system that feeds it the right fuel at the right time.

How We Bridge the Gap

This is where techniques like Retrieval-Augmented Generation (RAG) come in. When the customer asks a question, our system:

1. Looks in the filing cabinet (memory/database)
2. Finds relevant information (past tickets, preferences, etc.)
3. Places it on the desk (injects it into the context window)
4. Now the LLM can use it to generate a response

We'll dive much deeper into these techniques later in the certification. For now, the key insight is:

Context is what the LLM can see right now. Memory is everything else. Our job as architects is to build systems that bring the right information from memory into context at the right time.

More Context Does NOT Automatically Mean Better Context

This is one of the most important lessons in our entire certification.

Scenario:

We ask the LLM:

"Where is my order?"

Useful context:

Customer name
Order ID
Current order status
Shipping status
Relevant policy

That's focused. Every piece of information is directly relevant to the question. The LLM can find what it needs quickly and generate an accurate response.

Now let's imagine we decide:

"Let's give the LLM everything. More information must be better!"

So we cram the desk with:

Entire company handbook
Entire product catalogue
Five years of customer conversations
All previous API responses
Every shipping policy ever written
Every order ever placed

Question: Did we give the model more information?

Yes.

Question: Did we give it better information?

Probably not.

We created noise. The relevant order status is buried somewhere in that pile, but the LLM now has to work through thousands of tokens of irrelevant content to find it. The useful signal is drowned out by the noise.

This is our core insight:

Relevance matters more than volume.

Our goal is never to "fill the context window." Our goal is to put the right information into the context at the right time.

Context Rot — When the Desk Gets Too Messy

Here's where the desk analogy becomes especially useful.

Let's compare these two desks:

Desk A (Focused)

Everything is relevant and easy to find. The LLM can quickly identify the key facts and generate a response.

Desk B (Overstuffed)

The important information is still there — it's just buried. Finding it and correctly using it becomes harder. The model might get distracted by irrelevant policies, outdated information, or conflicting examples.

This is our intuition behind context rot:

As context grows, irrelevant or poorly organized information can make it harder for the model to use the information that actually matters.

Context rot manifests in a few ways:

Symptom	What It Looks Like
Distraction	The model pulls from irrelevant sections of a large document
Omission	The model misses the key fact buried in the noise
Confusion	The model tries to reconcile conflicting information from old policies
Hallucination	The model guesses instead of finding the needle in the haystack

So What Do We Do About This?

We can't expand the desk indefinitely. Even models with 1M+ token context windows still have limits. And even when we stay within those limits, context rot can degrade performance.

The solution isn't bigger desks. It's smarter desk management.

As we progress through this certification, we'll learn practical strategies for managing the context window:

Strategy	What It Does
Context pruning	Removing irrelevant or outdated information before it reaches the model
Summarization	Compressing long content into concise summaries that preserve key facts
Retrieval (RAG)	Fetching only the most relevant documents instead of dumping everything in
Memory systems	Storing long-term information outside the context and retrieving it on demand
Tool use	Letting the model call out to external systems instead of keeping everything in memory
Agentic architectures	Breaking complex tasks into smaller steps with focused context windows

These are the architectural patterns that separate toy demos from production-grade systems.

Key Takeaways

Let's recap what we've learned:

Concept	Takeaway
Context window	The LLM's working desk — everything it can "see" at generation time
Context limit	When exceeded, the system either truncates or rejects the request
Token awareness	Every token consumes space on the desk; 1 token ≈ ¾ of an English word
Context vs. Memory	Context is what's on the desk; memory is what's in the filing cabinet
Quality over quantity	More context is not automatically better context
Context rot	Too much irrelevant information degrades performance
Solution	Smart context management, not bigger context windows

Now that we understand the context window — its limits, its challenges, the distinction between context and memory, and the concept of context rot — we're ready to explore practical techniques for managing it.

---

6. Model Limitations — The Part We Must Respect

Now we arrive at an uncomfortable truth. LLMs are incredibly capable. LLMs can summarize, explain, classify, write code, extract information, and reason over what they're given — genuinely well.

But none of these capabilities means:

"The model is guaranteed to be correct."

It's a big part of why AI-application architecture differs from traditional deterministic software.

Hallucination - When a Fluent Answer Is Wrong

What it is: The model generates information that sounds plausible but isn't actually supported by reliable information.

Example:

Imagine we ask:

"Who approved Project Phoenix?"

But we never provided any information about Project Phoenix.

The model may still generate:

"Project Phoenix was approved by Sarah in the architecture review meeting."

That sentence sounds completely reasonable. But where did Sarah come from? Maybe nowhere. It's completely made up. That's the problem.

The LLM didn't know the answer, so it invented one. Not out of malice — because it was trained to always produce a response, and "I don't know" wasn't reinforced as strongly as generating a coherent completion.

This leads to a rule worth remembering:

Fluency is not proof of accuracy.

Why this matters for us:

When we build applications, we must assume that the LLM might invent facts when it lacks information. Our surrounding system needs to validate, retrieve, or prompt in ways that discourage hallucination.

Nondeterminism / Variability

What it is: Same or similar input, not guaranteed to produce identical output each time — sometimes just phrasing differs, sometimes the substance does too.

Example:

We ask the LLM three times (with the same temperature setting):

"Summarize the benefits of regular exercise."

Attempt 1:

"Regular exercise improves cardiovascular health, strengthens muscles, and supports mental wellbeing."

Attempt 2:

"Exercising regularly can boost your heart health, build muscle strength, and improve your mood."

Attempt 3:

"Physical activity on a consistent basis benefits your heart, muscles, and mental state."

All three are accurate. All three say roughly the same thing. But the wording is different each time.

Now consider a more dangerous scenario:

We ask:

"What's the refund policy for our Premium tier?"

Attempt 1:

"Premium tier customers can request a refund within 30 days of purchase."

Attempt 2:

"Refunds for Premium tier are available for 30 days from the date of purchase."

Fine. Both are accurate.

But what about:

"Based on our conversation history, what did the customer say about the damaged item?"

If the conversation history is long and contains conflicting information, different runs might surface different details. One run might mention the shipping damage. Another might focus on the packaging. A third might combine them in unpredictable ways.

Why this matters for us:

We can't rely on the LLM giving us the exact same output every time. Our application needs to handle variability gracefully — and for critical decisions, we might need multiple passes or deterministic fallbacks.

Instruction-Following Limits

What it is: Complex, multi-part, or conflicting instructions — especially buried deep in a long prompt — can get partially ignored.

Example:

We give the LLM this prompt:

"You are a customer support agent. Follow these rules:

1. Always greet the customer by name.
2. Never mention competitor products.
3. If the customer asks about pricing, provide the standard pricing table.
4. If the customer mentions a complaint, apologize within the first sentence.
5. Keep responses under 50 words.
6. End every response with a follow-up question.
7. Never use the word 'unfortunately.'
8. Offer a discount only if the customer has been with us for over a year.
9. Use a warm, friendly tone.
10. Always reference the customer's order history."

Now the customer asks:

"Can I get a refund for this item?"

The LLM has to juggle ten distinct instructions simultaneously. What's likely to happen?

• It might apologize (rule 4)
• It might forget to ask a follow-up question (rule 6)
• It might use "unfortunately" (rule 7) without noticing
• It might completely miss the order history check (rule 10)
• It might exceed 50 words (rule 5)

Why this matters for us:

We can't assume the LLM will follow every instruction perfectly, especially as the prompt grows. We need to:

• Keep instructions clear and prioritized
• Test complex prompts systematically
• Use system-level guardrails (not just prompt instructions) for critical rules
• Break complex tasks into smaller steps (which we'll cover in the tools and agents sections)

Knowledge and Context Limitations

What it is: The LLM may lack the information needed, or the right information might be present but poorly surfaced in a bloated context (see: context rot).

Example — Missing Information:

We ask:

"What was our total revenue in Q3 2024?"

The LLM has never seen our financial data. It doesn't know our revenue. It was trained on public internet data, not our internal systems.

What does it do?

It might say:

"I don't have access to your company's financial data. To get this information, I would need access to your internal systems or relevant reports."

Good. That's a responsible response.

But what if the information is present, just poorly surfaced?

Example — Buried Information:

We give the LLM a 500-page document containing:

• 495 pages of general company policies
• 1 sentence on page 398 that says: "Premium tier customers are eligible for 30-day refunds."
• 4 pages of unrelated content

Then we ask:

"What's the refund policy for Premium tier customers?"

The LLM has the answer. It's in the context. But it's buried in noise.

Will the LLM find it consistently?

Maybe. Maybe not. It might pull from an earlier, outdated policy elsewhere in the document. It might miss the relevant sentence entirely. It might hallucinate a policy that sounds reasonable.

Why this matters for us:

We can't just dump every document into the context and hope for the best. We need to retrieve and surface the most relevant information — not overwhelm the LLM with everything we have.

This is where techniques like RAG (Retrieval-Augmented Generation) and smart context pruning become essential.

Tool-Selection Mistakes

What it is: Given several similar tools, the LLM can pick the wrong one — especially with vague or overlapping descriptions.

Example:

We give the LLM two tools:

Tool A: get_user_profile(user_id) — Returns user name, email, and preferences.

Tool B: get_user_account(user_id) — Returns user account status, billing info, and subscription tier.

Now the user asks:

"Can you tell me my email address?"

Both tools could retrieve the email. Tool A is the better choice (it returns it directly). Tool B doesn't return email at all.

Which one does the LLM pick?

If the descriptions are clear, it might pick Tool A. But if the descriptions are vague, it might pick Tool B — and then have to apologize that it can't find the email.

More subtle example:

"What plan am I on?"

Tool A returns the subscription plan. Tool B returns the user's preferences (which don't include the plan).

If the tool descriptions aren't crystal clear, the LLM might call Tool B first, fail, and then try Tool A. That's extra latency, extra cost, and a worse user experience.

Why this matters for us:

We need to design tools with clear, distinct, and specific descriptions. Vague or overlapping tool definitions confuse the LLM and lead to unnecessary calls — or worse, the wrong action.

We'll cover this in much more detail in the tools and agents section.

False Confidence

What it is: The model sounding certain is not evidence that it's correct.

Example:

We ask the LLM:

"What's the capital of Australia?"

It says confidently:

"The capital of Australia is Sydney."

It sounds certain. But it's wrong. (It's Canberra.)

Now let's increase the stakes:

"Is this transaction fraudulent?"

The LLM says:

"Yes, this transaction shows clear signs of fraud."

It sounds certain. But we have no idea how confident it actually is. The LLM doesn't have a "confidence dial." It doesn't output "I'm 72% sure." It just produces the most likely completion — and sometimes that completion is wrong.

The problem:

When an LLM is wrong, it doesn't say:

"I'm not sure, but I think it might be..."

It says:

"The answer is X."

And it says it with the same tone whether it's right or wrong.

Here's a classic example:

Question	Correct Answer	LLM's Wrong Answer (with false confidence)
"Who invented the telephone?"	Alexander Graham Bell	"Thomas Edison invented the telephone."
"What's the tallest mountain in the world?"	Mount Everest	"Mount Kilimanjaro is the tallest."
"Which planet is closest to the Sun?"	Mercury	"Venus is closest to the Sun."

In each case, the LLM sounds just as confident as when it gives a correct answer.

Why this matters for us:

Wrong instinct: "It sounded so sure, it must be right."

Right instinct: "Confidence in tone tells me nothing about accuracy. I need validation, not vibes."

The mental model shouldn't be:

It should be:

As architects, we need to build validation layers:

• Cross-checking with known data
• Asking for citations or sources
• Running multiple passes and comparing results
• Using structured outputs with confidence indicators
• Designing workflows where humans review critical decisions

Summary of Model Limitations

Limitation	In One Sentence
Hallucination	The LLM can invent facts that sound plausible but aren't true.
Nondeterminism	The same input can produce different outputs each time.
Instruction-following limits	Complex instructions get partially ignored, especially in long prompts.
Knowledge limits	The LLM doesn't know our internal data unless we provide it — and even then, it might miss what's buried.
Tool-selection mistakes	Given similar tools, the LLM can pick the wrong one.
False confidence	Confident tone is not a signal of accuracy.

---

7. Deterministic vs. Probabilistic Systems — The Big Architectural Payoff

Once we accept that LLMs are probabilistic (variable, occasionally wrong, never 100% guaranteed), a critical design question falls out naturally:

For any given piece of the system, should this be decided by LLM, or enforced by code?

This is where LLM fundamentals turn into architecture.

Let's divide responsibilities.

Good candidates for an LLM

LLMs are particularly useful for tasks involving interpretation and flexible generation:

These tasks benefit from language understanding and flexibility.

---

Good candidates for deterministic code

Some things should not depend solely on probabilistic generation:

These tasks require guarantees.

Prompt-Only vs. Code-Enforced

Compare these two approaches to the same requirement:

Prompt-Only (Weak):

Please don't approve refunds over ₹50,000 without checking with a supervisor.

A prompt is a request or an instruction. It isn't necessarily a guarantee. Under unusual phrasing or a long, cluttered context, the model can still slip.

Code-Enforced (Strong):

The important decision is enforced by deterministic application logic — it's a wall.

A useful rule of thumb:

Prompt = guide. Code = guarantee.

Not every prompt is weak, and not every piece of code is perfect. But when something must always happen, we should not rely solely on a model instruction.

---

8. A Worked Example: Putting It All Together

A customer says:

"My order hasn't arrived and I'd like a refund."

Step 1 — The application receives the request.

Step 2 — The application gathers relevant context (not everything it has):

Customer ID · Order ID · Order status · Refund policy · Relevant prior conversation

Step 3 — That context is assembled and sent to LLM:

Step 4 — LLM interprets the request: "The customer is requesting a refund because the order is late."

Step 5 — Deterministic application logic checks the policy — the app doesn't just trust LLM's judgment on whether to actually process money:

Notice: LLM isn't the whole application — it's a powerful component inside one.

The surrounding application controls what context is provided, what's retrieved, what's allowed, what's validated, and what happens when the model gets it wrong. That's the beginning of thinking like an architect rather than just a prompt-writer.

---

9. The Six Things Worth Remembering

If everything else from this post is forgotten, keep these six:

1. LLMs generate responses — they aren't traditional rule-based programs.
2. Text is processed as tokens — token count has real cost, latency, and context consequences.
3. Context is the model's current working space — instructions, history, documents, retrieved info, tool results, all competing for the same limited space.
4. Context isn't memory — memory is persisted externally and pulled into context only when relevant.
5. Output isn't guaranteed correct — fluent ≠ correct, confident ≠ Correct, and detailed ≠ Correct
6. Use the right component for the right job — use deterministic code for rules, validation, and authorization. In other words, the code is better suited to guarantees.

---

10. The Mental Model I Want to Carry Forward

Let's compress the entire article into one picture.

And behind all of this:

That's the foundation.

---

11. Quick Self-Check

Before moving to the next topic, let's see if we can explain these without looking back:

1. What is an LLM?
2. Why do tokens matter?
3. What is a context window?
4. What is the difference between context and memory?
5. Why isn't a confident answer necessarily correct?
6. What is context rot?
7. Which should handle this?
8. Which should handle this?
9. Complete the rule