What Is Context? Defining the Boundaries of Machine Awareness

What Is Context? Defining the Boundaries of Machine Awareness

Imagine you walk into a room and ask someone, "What is the capital of France?" They answer immediately: "Paris." Now ask them, "What did I ask you five minutes ago, and what did you answer?" They can tell you, because human memory works that way—we remember what just happened, what was said, what we were thinking. We do not have to consciously prepare a summary of the last few minutes and hand it to ourselves before we speak. The brain handles that automatically. But what if you asked a machine the same question, and then five minutes later asked, "What was my first question?" You might be surprised to find that the machine has no idea what you are talking about. This is not because the machine is stupid. It is because the machine has no biological memory. Everything a machine "knows" at any given moment must be present in a special workspace called its context. Understanding what context is, why it is limited, and why it must be carefully constructed is the foundation of Model Context Engineering, the discipline this book will teach you.

This opening chapter begins our investigation with a simple but profound question: when engineers say that a machine model is "aware" of something, what do they actually mean? More importantly, what determines the boundaries of that awareness? We will answer this question by moving from a concrete analogy to a formal definition, from a definition to a discipline, and from a discipline to a roadmap of the five sub-fields that structure the rest of this book. The chapter is meant to be read slowly. The ideas introduced here will be referenced, refined, and re-examined in every chapter that follows, so it is worth taking the time to understand them well.

1.1 The Workspace Problem: Why Machines Need Curated Inputs

To understand context, we must first understand a fundamental difference between humans and machines. A human brain is constantly receiving signals from the eyes, ears, skin, nose, and other senses. It is also constantly retrieving memories from long-term storage and combining those memories with current perception. We do not consciously choose which memories to load into our "workspace"—the brain does it automatically, based on attention, emotion, repetition, and habit. When you ask a friend "What did we do last summer?" the relevant memories surface on their own. Your friend did not have to manually search through a filing cabinet and pick out the right documents.

A machine language model has none of this. It does not have eyes. It does not have a continuous stream of sensory input. It does not have an autobiographical memory that spans its entire existence. What it has is much simpler and much more limited: a fixed-size window into which text is placed, and from which the model produces its next response. The window contains everything the model can "see" at the moment it generates an answer. We call the contents of that window the model's context. The window is small. It is also the entire world the model currently inhabits.

The word *context* comes from the Latin *contextus*, meaning "a weaving together." When we speak of a model's context, we mean the woven set of inputs, instructions, retrieved documents, conversation history, and tool outputs that together condition the model's next output. Context is the only world the model has access to during a single inference step. Outside the window, the model is, in a meaningful operational sense, blind. It cannot reach into the world and grab a fact. It cannot remember something from an earlier session. It cannot ask a follow-up question before generating. It must work with what is in front of it, and only with what is in front of it.

This creates a problem that has no clean human equivalent. A human asking "Where did I leave my keys?" can get up, walk around, and look. A human can also call a friend and ask, "Do you remember where we put the keys yesterday?" A machine cannot do either of these things in a flexible way. If the answer is not in the context window, the machine cannot retrieve it from anywhere else. It is as if the model is a brilliant scholar sitting at a desk in a locked library, and the only books it can read are the ones currently open in front of it. If you forget to open a book, the scholar cannot read it. If you open too many books, the scholar cannot fit them all on the desk and will have to set some aside. If you open the wrong books, the scholar will give wrong answers with great confidence.

This is why context is not a luxury or a feature. It is the substrate of machine intelligence. Every capability we associate with AI—answering questions, writing essays, debugging code, holding conversations, summarizing documents, planning trips—depends on the careful assembly of the right context at the right time. Strip away the context, and what remains is a general-purpose statistical engine with no specific task, no specific knowledge, and no specific behavior. Add the right context, and the same engine becomes a useful assistant, a creative partner, a careful analyst, or a patient tutor. Model Context Engineering is the discipline of doing this assembly well.

The discipline is young. For most of the history of artificial intelligence, engineers focused on the model itself: making it bigger, training it on more data, tuning its parameters. The context was an afterthought, treated as a passive string of text fed into the front of the model. Over the last several years, this attitude has changed. Practitioners have discovered that the same model, given different contexts, can behave in dramatically different ways. Some contexts produce accurate, helpful, on-topic responses. Other contexts, given to the same model, produce confused, off-topic, or even harmful responses. The difference is not in the model. The difference is in the context. This realization has given birth to a new engineering discipline, and this book is its first systematic textbook.

1.2 Three Layers: Data, Information, and Context

To make the concept of context precise, we need to distinguish it from two related but different concepts: data and information. These three words are often used interchangeably in casual conversation, but in the discipline of Model Context Engineering they refer to distinct things, and confusing them is one of the most common sources of error in the field.

Data is the raw, unprocessed material of the world. It includes every word ever written, every number ever recorded, every pixel ever captured, every sensor reading ever taken. Data is everywhere and always. Most of it is never seen by any model. The complete works of Shakespeare are data. The historical weather logs of every city on Earth are data. The grocery list your mother wrote on a napkin last Tuesday is data. The full text of every Wikipedia article in every language is data. None of these, in their raw form, are *context* for any particular model at any particular moment. Data is potential. It is the uncut gemstone before the jeweler has touched it.

Information is data that has been processed, structured, or organized so that it can answer a question or serve a purpose. When a meteorologist takes raw temperature readings, applies a formula, and produces a forecast of "70% chance of rain tomorrow," they have created information. When a librarian takes thousands of unindexed books and assigns them subject codes, they have created information. When a company takes millions of sales transactions and computes the average revenue per customer, they have created information. Information is data with a job: it is meant to be used, to answer questions, to support decisions. Information is the cut and polished gemstone, ready to be set.

Context is a further refinement. Context is the specific subset of information that is *selected* and *delivered* to a model at a specific moment,