How Claude Actually Reads Context

Part 2: The Mental Model Every QE Engineer Needs

In the last article, we established that prompting alone does not scale.

Before we can fix that, we need to understand something more fundamental. How does Claude actually read information in the first place?

Many engineers treat AI systems as if they work like humans. You explain something once. You assume it remembers. You start a new conversation. And then you wonder why the answers suddenly feel different.

At some point, almost everyone says:

Claude forgot.

But that’s usually not what happened.

To understand why, we need to stop thinking about AI as a person and start thinking about it as a system. And that starts with understanding context.

The Biggest Misconception About AI

Let’s begin with a simple question.

When you ask Claude to review your Playwright framework, what information do you think it can actually see? Many people assume the answer includes their project, their repository, their previous conversations, their standards, and their architecture.

The reality is much simpler.

Claude can only work with the information that is currently available to it.

Nothing more.

Nothing less.

This sounds obvious.

But it changes everything.

Because once you understand this principle, you suddenly understand why Claude appears to forget things, why prompts become repetitive, why skills exist, why MCP exists, and why context engineering is becoming such an important discipline.

All of them are fundamentally context problems.

Imagine Claude Has a Desk

Let’s use an analogy.

Imagine you join a new project. You sit down at a desk. Throughout the day, people bring documents to you. Some documents contain architecture diagrams, coding standards, sprint requirements, test reports, and defect details.

Your desk has limited space. You can only work with the documents currently sitting on it. Documents stored somewhere else in the building still exist. But they cannot influence your decisions unless someone brings them to your desk.

Claude works in a very similar way.

The desk represents Claude’s context window. Everything currently on the desk is context. Everything outside the desk is invisible.

What Is a Context Window?

Think of a context window as working memory. It is the information Claude can actively use while generating a response. When you ask a question, Claude builds a temporary workspace containing the information available at that moment.

That workspace becomes the basis for every decision it makes.

No context : No understanding.

Better context : Better understanding.

The quality of AI output is often a direct reflection of the quality of the context it receives.

What Claude Actually Sees

When Claude responds to a request, it doesn’t magically scan your laptop, your GitHub repositories, or your company documentation. Instead, it works with a collection of information that has been made available during the conversation.

A simplified view looks like this:

User Message
      +
Attached Files
      +
Loaded Skills
      +
System Instructions
      +
Tool Results
      =
Current Context

This entire collection becomes Claude’s working memory. Everything outside this context is effectively invisible. This is one of the most important concepts in modern AI engineering.

Why Claude Appears to Forget

Let’s revisit a scenario most engineers have experienced. You spend fifteen minutes explaining your framework. You describe your Page Object Models, fixtures, reporting integrations, naming conventions, and test architecture.

Claude gives excellent recommendations. The next day you open a new conversation.

You ask:

Generate a login test.

The response is generic. The framework standards are missing. The reporting integration is missing. The fixture usage is missing.

It feels like Claude forgot everything. But from Claude’s perspective, nothing was forgotten. The new conversation simply has a different desk. The documents from yesterday are not sitting there.

The context changed. Therefore the output changed.

Understanding this distinction is incredibly important because it shifts the problem from memory to context management.

A Playwright Framework Example

This is where our running framework example becomes useful. If you haven’t seen it yet, the link is in Article 1.

The framework contains eight architectural layers:

Config Layer
Fixture Layer
Page Layer
Helper Layer
Assertion Layer
Reporting Layer
Database Layer
Runtime Layer

Now imagine asking Claude:

Generate a login test.

How would Claude know which fixture to use, which page object to instantiate, which assertion library to apply, which reporting annotations are required, or which coding standards the team follows?

The answer is simple. It doesn’t. At least not automatically.

That information exists inside the framework. But unless it reaches Claude’s context window, it remains outside the desk. This realization is the foundation for everything we will build later in the series.

The First Mistake Most Engineers Make

Once engineers understand context, they often make a new mistake.

The reasoning usually sounds like this:

If more context helps, I’ll provide everything.

So they paste entire frameworks, hundreds of files, thousands of lines of code, and massive documentation sets.

The result is usually disappointing.

Why?

Because context is not just about quantity.

It is about relevance.

Imagine someone dumps every project document onto your desk at once.

Requirements, architecture diagrams, meeting notes, sprint plans, release documentation, and historical reports.

You now have more information. But finding the right information becomes harder. The same principle applies to AI systems. Too little context creates poor understanding. Too much context creates noise.

Both are problems.

The Real Goal Is Relevant Context

This is one of the most important lessons in modern AI engineering.

The goal is not maximizing context. The goal is optimizing it.

The question is not:

How much information can I provide?

The better question is:

What information is actually needed for this task?

This is where context engineering begins. Context engineering is the practice of ensuring the right information reaches the model at the right time.

Not too little.

Not too much.

Just enough.

Quality Engineers already solve similar problems every day. Think about test execution. We don't execute every test in every situation. We choose the right tests for the right moment.

A smoke suite for a quick deployment check.

A regression suite for a full release.

A feature suite for a targeted change.

The goal isn't maximum execution. The goal is relevant execution.

Context works exactly the same way.

The best AI systems are not the ones with the most information. They are the ones with the most relevant information. This is one of the reasons Quality Engineering professionals are uniquely positioned to become effective AI architects.

We already think in terms of optimization, relevance, coverage, and validation.

Hands-On Exercise

Let’s make this practical.

Take the Context column from your Article 1 exercise, the list of framework standards and conventions you identified.

Open a completely new Claude conversation.

Paste only that context.

Then ask:

Generate a login test.

Now open another new conversation.

Ask the exact same question without providing any context.

Compare the two responses.

What changed is not Claude’s intelligence. What changed is what was sitting on the desk. This is the first practical experience of context engineering.

And it connects directly to why the Context column you identified in Article 1 matters. Those are not just repeated instructions. They are the information your framework needs to place on Claude’s desk before any task begins.

In upcoming article, we will turn that list into our first real skill.

Common Mistakes

Mistake #1: Assuming Claude Can See Your Repository

If information is not available in the current context, Claude cannot use it.

Your project files, framework standards, and coding conventions are invisible unless they are explicitly placed into the conversation.

Mistake #2: Dumping Entire Projects into Context

More information does not automatically produce better results. Relevant information matters far more than volume. Loading everything creates noise that reduces the quality of responses rather than improving it.

Mistake #3: Treating Context Management as an AI Problem

Context management is an engineering problem. The same discipline used to design good software systems applies here.

Deciding what information to include, when to include it, and how to structure it is an engineering decision, not something the model handles on its own.

The Mental Model to Remember

Before moving to the next article, remember one thing. Claude is not reading your project. Claude is reading its desk.

The quality of its answers depends entirely on what is currently sitting there. Everything we will discuss in the rest of this series builds on this idea.

Skills are not magic.

Agents are not magic.

MCP is not magic.

Claude CLI is not magic.

They are all different strategies for ensuring the right information reaches the right place at the right time. And that place is the context window.

Once we understand that, the rest of Agentic AI starts making a lot more sense.

What Comes Next

Now that we understand how context works, we can tackle one of the most misunderstood topics in AI today.

People often use the terms prompt, skill, and agent as if they mean the same thing.

They don't.

And the differences between them are not just technical. They reflect a completely different way of thinking about how AI should participate in engineering workflows.

In the next article, we will break down each concept clearly, compare them side by side using our Playwright framework, and learn when to use each one.

Next Article

Article 3: Prompts vs Skills vs Agents: Understanding the Building Blocks of Agentic QE

Part of The Complete Agentic AI for Quality Engineering Series