What is Context? A Formal Definition for the Curious Young Engineer

What is Context? A Formal Definition for the Curious Young Engineer

The morning train to the Institute of Computational Sciences was crowded, but Ada found an empty seat beside a tall man with silver hair and a velvet waistcoat embroidered with tiny gears. He introduced himself as Professor Erasmus Vector, and within three minutes he had asked Ada a question that would change the way she thought about machines for the rest of her life.

"If I handed you a machine that could answer any question — truly any question, from 'what is two plus two?' to 'write me a poem about the sea' — what would you give it first?"

Ada thought for a moment. "I would give it the question," she said.

"Ah," said the Professor, smiling in a way that suggested Ada had just opened a door onto a much larger room. "But that is only the beginning. You see, a machine of this kind does not simply answer questions. It *continues* whatever you give it. If you give it nothing, it invents. If you give it a question, it invents an answer. If you give it a question plus a thousand pages of carefully chosen background, it invents an answer that is, with high probability, the answer you actually wanted."

This chapter is the doorway through which Ada stepped that morning. It introduces a single, central idea — that the input to a thinking machine is not a passive thing that simply exists, but an object that must be *engineered* — and it gives that idea a formal shape. By the time you finish reading, you will be able to define context in a single sentence, name its parts, explain why it is scarce, and trace its lineage back to the early decades of computing. You will also be invited to begin a small experiment of your own: a seven-day diary in which you record, every day, the contexts you create when you speak with a machine.

1.1 Context as a Formal Object

Let us begin with a definition. In the language of computer science, a language model is a function — a rule that takes an input and produces an output. We can write this rule with the same kind of arrow you might draw in a mathematics textbook:

$$f : \mathcal{C} \rightarrow \mathcal{T}$$

Read aloud, this says: "f is a function from the set $\mathcal{C}$ to the set $\mathcal{T}$." The set $\mathcal{C}$ is the set of all possible contexts, and the set $\mathcal{T}$ is the set of all possible continuations (texts, in our case). Every time you type a message into a chat assistant, the assistant is computing $f(c)$ where $c$ is the context you have supplied.

This may seem abstract, so let us descend one level. A context $c$ is not a single string of text. It is a tuple — an ordered list of named pieces, like the parts of a recipe written on a card. We can write a typical context like this:

$$c = (p_{\text{system}},\ p_{\text{user}},\ p_{\text{retrieved}},\ p_{\text{history}})$$

Each symbol stands for a specific kind of input:

• $p_{\text{system}}$ is the **system prompt** — a hidden set of instructions written by the people who built the assistant. It usually tells the model how to behave: "be polite," "answer in English," "do not invent facts." You, the user, often do not see this piece directly, but it is the first thing the model reads, and it exerts a strong influence on everything that follows.
• $p_{\text{user}}$ is the **user prompt** — the question or instruction you typed. This is the part of the context that you control most directly.
• $p_{\text{retrieved}}$ is a collection of **retrieved documents** — pieces of text fetched from outside the model (a book, a database, a previous conversation, the open web) to help the model answer. Retrieval is one of the most important techniques in modern context engineering, and we will devote an entire later chapter to it.
• $p_{\text{history}}$ is the **conversation history** — every message that has been exchanged so far in the present dialogue, in the order it was exchanged. Each turn you take adds to this part of the tuple.

Each of these pieces is itself a sequence of small units called tokens, which are the model's alphabet. A token is roughly a syllable, a punctuation mark, or a short common word; the sentence "Context is finite" might be broken into six tokens: "Con", "text", " is", " fin", "ite". You do not need to know the exact boundaries to use the word, but you should remember that *everything* a model receives — every instruction, every document, every word you have ever typed in the present conversation — is measured in tokens, and the model has a fixed budget of them. We will return to this point in Section 1.3.

Ada raised her hand (metaphorically, since she was on a train). "Why call it a tuple? Why not just call it 'the text'?"

"Because order matters," Professor Vector replied. "If you put the system prompt at the bottom of the context instead of the top, the model pays less attention to it. If you put the question before the retrieved documents, the documents are read as evidence rather than as background. If you let the conversation history grow without bound, the early parts of the dialogue are pushed out of the model's working memory. In every case, the same set of pieces arranged differently produces a different output. That is why the word 'tuple' is honest: it admits that a context has *parts* and that those parts have *positions*."

This is the first formal commitment of our book:

> Definition 1.1 (Context). A *context* is a finite, ordered tuple of textual elements (system instructions, user prompts, retrieved documents, and conversation history) supplied to a language model in order to condition its output.

Three words in this definition do most of the work. *Finite* means there is a fixed maximum size — the model cannot read more than its window allows. *Ordered* means the sequence in which pieces appear changes their influence. *Condition* means the context does not *determine* the output (the model still has probabilistic freedom) but it *biases* the output toward text that is consistent with what it has just read.

A useful analogy: a context is to a language model what the lighting in a theatre is to an actor. The actor chooses her words and gestures, but the lighting determines whether she is visible, what mood she projects, and whether the audience leans forward or drifts off. Two actors saying the same line under different lights produce two different performances. So too does a model given the same question under two different contexts.

To make this less abstract, let us run a small experiment in our heads. Suppose you ask a chat assistant, "Tell me about elephants." With no further context, the assistant must guess. Is this question from a six-year-old who wants to know what elephants eat, a university student writing a biology essay, or a tourist planning a safari? Without information, the assistant splits its effort across all three, producing an answer that is, by design, mediocre for each. Now suppose you instead supply a context like this:

> *You are a museum educator speaking to a six-year-old. Use simple words, one short paragraph, and one surprising fact. The child has just learned that some animals are larger than others.*

The assistant now has a clear directive, a clear audience, a clear length, and even a hook (the surprise fact). The output it produces will, with high probability, be sharper, kinder, and more useful than the answer it would have produced to the bare question. The difference between the two cases is not the model — the model is the same — but the context.

This is the heart of context engineering: the model is a remarkable but unwritten instrument, and the context is the music it will play.

It is worth pausing on the word *formal* in the chapter's title. Why insist on a formal definition? Because informal definitions drift. If you ask ten people "what is context?", you will receive eleven answers, and several of them will be circular ("context is whatever the model needs to know"). A forma