The Prompt Is Not the Whole Context
For prompts.chat, the next design problem after structured prompt construction is context: what surrounds the current instruction, who owns it, and in what order does an AI client receive it? This chapter examines the project’s chat builder and its teaching about context engineering so the reader can distinguish a rendered prompt from a complete message package. That distinction matters whenever a task depends on system guidance, conversation history, retrieved information, tools, memory, or a specific output contract.
A conversation is an ordered object
A single string is a convenient starting point, but it collapses several different kinds of information. “Summarize this report” could be a user request, a system instruction, an example of the desired behavior, or a task embedded inside a larger workflow. Those roles are not interchangeable. A system message establishes behavior. A user message supplies a request or input. An assistant message can represent an earlier turn or an example. Treating them as one undifferentiated paragraph makes it harder to see who is speaking, what should persist, and what should change on the next run.
The chat builder in prompts.chat represents these distinctions directly. Its model includes explicit system, user, and assistant messages, alongside typed descriptions of persona, context, task, output, reasoning, examples, and memory. That is a different abstraction from the basic builder’s rendered prompt. The basic builder asks, “What sections should this instruction contain?” The chat builder asks, “What complete conversation package should a client send, and what should each part mean?”
This representation also gives state a clearer owner. The builder owns the instructions and message sequence it is constructing. A memory object can hold a summary, facts, preferences, or history, but it is still input to the build rather than an invisible property of the model. The model does not acquire durable memory merely because an application has a memory field. The application must decide what to preserve, what to summarize, and what to send again.
That is the practical meaning of the project’s statement that AI systems are stateless. Each request needs the relevant context supplied again. A chat interface can make this feel like memory because it resends conversation history; the model itself only sees the messages included in the current call. Once this is understood, context management becomes an engineering decision rather than a mysterious property of the assistant.
How the chat builder assembles a request
The chat builder starts with the persona layer. A persona can include a name, role, tone, expertise, personality, background, language, and desired verbosity. These values are rendered as system guidance such as who the assistant is, what it knows, and how it should communicate. A role is not a new model identity; it is an instruction intended to focus the model’s behavior.
Context is assembled separately. It can include background, domain, audience, purpose, known facts, assumptions, and constraints. The separation is useful because “what the assistant should be” and “what situation it is operating in” are different decisions. A code-review assistant might have a stable role while receiving a changing project background, target audience, and set of assumptions about the code under review.
The task layer then states the instruction and can add steps, deliverables, success criteria, anti-patterns, and a priority such as accuracy, speed, creativity, or thoroughness. These fields make a task more than a verb. They describe what completion means and what the assistant should avoid. A prompt that says “analyze this data” leaves the outcome open; a task with deliverables and criteria gives the surrounding workflow something to inspect.
The builder’s output layer adds another contract. It can request text, JSON, Markdown, code, or a table; specify a JSON schema; constrain length and style; and ask for explanations, examples, sources, or confidence. These instructions do not create a formal type guarantee at the model boundary, but they make the desired response legible. If a downstream program expects JSON, recording that expectation as an output setting is more maintainable than burying it in a paragraph.
Examples and reasoning settings complete the package. Examples provide input-output patterns. Reasoning settings can ask for step-by-step work, alternatives, verification, or explicit assumptions. The source is careful, in effect, about what this means: these are instructions emitted into the prompt. They are not a guarantee that the model’s reasoning is correct, private, or even exposed in the requested form. An application should judge the answer it receives, not treat the presence of a reasoning instruction as proof that the underlying process was sound.
The build operation then reconciles generated system guidance with explicit messages. If there is no system message, the generated guidance is placed first. If one already exists, the builder prepends its generated content to that system message. User and assistant messages remain in the conversation. If memory history is present, it is inserted after the system message. The order is consequential: a summary placed as a user turn is not the same as a system constraint, and a prior assistant answer is not the same as a fresh instruction.
Consider a code-review workflow. The persona can establish the reviewer's role and tone; the context can state the project's language, audience, and assumptions; the task can request an analysis with specific deliverables; and the output settings can ask for a structured list with severity and suggested fixes. The current code belongs in a user message or a bound variable, not in the stable identity of the reviewer. A previous review summary may be useful memory, but it should not silently override the current code or task. Keeping these inputs separate makes it possible to replace the code while preserving the review policy, or to change the audience without rewriting the entire conversation.
The separation also clarifies failure. If the model returns a response in the wrong format, the output contract was expressed but not enforced at the model boundary. If it makes a claim unsupported by the retrieved material, the problem may be in retrieval, context selection, or evaluation rather than in the persona. If an old preference persists after it should have expired, the memory policy—not the wording of the current task—is the likely place to inspect. A message package does not prevent these failures, but it gives the surrounding system distinct places to look.
The diagram describes the boundary that matters: prompts.chat can assemble the package, while the surrounding workflow owns what happens after the model responds. The builder does not secretly retrieve documents, verify facts, or decide whether a response is safe. Those responsibilities require additional application logic, human review, or another tool.
Context adds information and action
The interactive book expands the idea of context beyond the fields inside a chat prompt. It identifies system instructions, conversation history, retrieved information, the current query, and the response as competing occupants of a limited context window. This is why adding more text is not automatically helpful. Context has a capacity, and irrelevant material can crowd out the evidence or instruction that matters.
Retrieval-augmented generation, or RAG, is presented as a way to supply domain-specific information at request time. Documents are stored in a searchable system, relevant pieces are retrieved, and those pieces are added to the prompt before the model generates an answer. The important relationship to prompts.chat is conceptual: a reusable prompt can specify how to use supplied information, but it does not become a knowledge base merely by asking the model to be accurate. The retrieval system owns the documents and search step; the prompt owns the instructions for interpreting them.
Embeddings change how relevance can be found. Instead of relying only on exact words, a system can represent text as vectors and search for related meaning. Again, this is a context supply mechanism, not a replacement for prompt structure. A retrieved passage may be relevant in topic but wrong for the question, outdated, or insufficiently authoritative. The prompt can request citations or a stated uncertainty, but the application still needs to choose the documents and decide how to handle weak matches.
Tools add another boundary. The book describes a pattern in which the model decides that it needs a tool, emits a structured request, the application runs that tool, and the result is returned to the model. A weather lookup, database search, or calculation therefore becomes part of the conversation’s context. prompts.chat’s MCP teaching places resources, tools, and prompt templates behind a common interface, but the practical ownership remains divided: the AI client chooses or requests an action, the integration executes it, and the model receives the result as new context.
Long conversations introduce a persistence problem. Resending every turn eventually consumes the available context window. The book presents summarization as a way to preserve key decisions, facts, preferences, current goals, and pending questions while reducing the amount of history sent. The chat builder can carry a summary, facts, preferences, and history, but it cannot know which details are important for a particular domain unless the application defines that policy. A compressed history is more efficient, but it may omit a detail that later turns need.
These mechanisms show why context engineering is not simply a more elaborate prompt. It is a coordination problem among stored knowledge, message order, retrieval, tools, memory, and output handling. prompts.chat’s educational material gives readers a vocabulary for those pieces, while the chat builder gives developers a way to represent several of them consistently. The surrounding application still owns the data, timing, permissions, and evaluation.
Model-agnostic does not mean behavior-identical
The package describes the chat builder as model-agnostic because it emits a common conversation representation for GPT, Claude, Gemini, Llama, and other chat systems. That portability is useful. A team can preserve its role, context, task, examples, and output intent while changing the client that sends the messages. It reduces the cost of rewriting the application’s conceptual model for every provider.
But a common representation is not a common execution environment. Providers differ in message APIs, context limits, tool conventions, safety policies, output-format support, and how strongly they follow competing instructions. A JSON request may still produce invalid JSON. A request for concise output may conflict with a task that requires nuance. A role may focus vocabulary without supplying genuine expertise. A step-by-step instruction may change the response style without making the reasoning reliable.
Portability therefore works best when the shared representation contains intent rather than provider-specific promises. The builder can express that the output should be JSON, that sources should be included, or that assumptions should be stated. A client may need to translate those intentions into a provider’s native API, and a test should verify the result in that environment. The more a prompt depends on a particular model’s behavior, the less portable it is, even if the surrounding TypeScript compiles everywhere.
This is also why the project’s conceptual language about agents and skills should be read carefully. A skill can package prompts, references, scripts, and configuration for an agent, and a chat builder can supply planning or tool-use instructions. Neither representation by itself creates persistence, observation, adaptation, or safe action. Those properties emerge from the runtime loop around the prompt: what state is stored, which tools are available, what feedback is returned, and who can intervene when the result is wrong.
A message package is more informative than a string because it preserves those distinctions. It tells a maintainer which instructions are stable, which facts are supplied at runtime, which history is carried forward, what output is expected, and where the model’s responsibility ends. The next step is to combine this construction and context model with checking: decide how much structure a task needs, what can be detected before execution, and where human or task-specific evaluation must begin.