Prompting Is No Longer Pretty Text

The word "prompt" still conjures a picture of a well-chosen phrase that makes the model start answering correctly. In 2026 that picture mostly gets in the way. A working prompt is part of an executable contract between your code and the model, and its behavior is determined by far more than the words of the instruction.

Everything shapes the result at once: which model you picked, how system and user messages are prioritized, what made it into the context, which schema describes the answer, which tools are available, what state the session holds, what limits are set, and what code surrounds the call. Change any of these details and "the same" prompt behaves differently. So pretty text on its own no longer guarantees anything: it is just one of the contract's variables.

It helps to keep in mind the shape almost any prompt reduces to - from a classifier to an agent.

Each stage answers its own question. The goal - what actually needs to happen: the role in the product, the boundaries, the order of decisions, and the conditions under which the model must refuse. The context - what to decide from: the user request, retrieved documents, history, state, tool results, and examples. The model turns goal and context into an answer, tools give it hands, and the check decides whether the answer can be trusted and what to do with it next. Skip any stage and the hole has to be patched elsewhere, usually more expensively.

If you fold this into the three parts you actually control, here is what you get.

• Instruction - what to do. The goal, the role in the product, the boundaries, the order of decisions, and the refusal conditions. This is the only part many people call "the prompt", though it is just a third of the picture.
• Context - what to decide from. The request, retrieved documents, history, state, tool results, and examples. The model knows nothing that is not in the context - so answer quality comes down to the quality of what you put there.
• Runtime - what is actually allowed. Schemas, permissions, timeouts, max steps, confirmations, validation, and observability. This is not text but the code and infrastructure around the model, and it is what keeps the promises words cannot.

Hence the book's main formula, which we will return to in every chapter.

The main formula. A prompt sets probabilistic behavior. Code and infrastructure set mandatory boundaries. You cannot replace a permission check with the phrase "do not reveal others' data".

The difference is fundamental. An instruction in words is a request the model fulfills with some probability. A permission check in code is a guarantee that always fires. As soon as the cost of a mistake exceeds mere inconvenience, mandatory boundaries move from text into code, and the prompt stops being the only line of defense.

Finally, it helps to distinguish three levels of systems from the start - the whole book is essentially about choosing between them.

• Single call. Owner - one model. Typical result: classification, extraction, an answer over retrieved context. The cheapest and most predictable level; always worth starting here.
• Workflow. Owner - code. A fixed chain with route, parallel, and loop, where the branching conditions are stated explicitly. Order is expressed reliably by code, not by coaxing the model.
• Agent. Owner - the model inside a harness. Dynamic choice of steps and tools within set limits. Maximum flexibility and maximum risk; justified only when the path is not known in advance.

These three levels are not a ladder you must climb. More often the right move is the reverse: take the simplest level that passes your check, and add complexity only under the pressure of real requirements. That is where engineering prompting begins, and we will return to it in the chapter on choosing the simplest system.