THE THREE DISCIPLINES AROUND THE MODEL

EXAMPLES Example 1: Prompt engineering in action. A manager types "summarize this" and pastes a long earnings report. The reply is a rambling paragraph that is hard to use. The manager rewrites the request: "Summarize this in three bullet points for a busy executive, focusing on financial risk." The new answer is short, targeted, and useful. Nothing about the model, the tools, or the system changed. Only the wording of one instruction changed, and that is prompt engineering. Example 2: Context engineering in action. An agent has been helping a user debug a program for an hour, and there are now fifty messages in the history, several large files, and many tool outputs. If all of it is sent on every step, the window fills up and the model begins to lose track of the goal. A context engineer designs rules: keep the last six messages in full, keep a short summary of everything older, include only the two files currently being edited, and include only the latest test results instead of all of them. Walking through one step: the harness collects these selected pieces, assembles them in a sensible order with the goal stated clearly at the top, and sends them. The model now has what it needs without being overloaded. Example 3: Harness engineering in action. A team builds a coding agent that is allowed to run shell commands. They write code that retries a failed model call up to three times with a growing pause between tries. They write a permission check that blocks any command that deletes files outside the project folder. They write a logger that stores every command and result. They set a budget that stops the run after a fixed spend or time. Because of these protections, the agent can work for hours without a human reading every step, and if something goes wrong the log shows exactly what happened. None of this was done by editing a prompt. Example 4: Same model, different results. Team X and Team Y both use the identical model. Team X sends the model the whole conversation every time, has no retries, lets the agent call any tool, and never checks the final answer. Team Y trims the context, retries on temporary errors, restricts the tools, caps the number of steps, and verifies results against tests before accepting them. Over one hundred tasks, Team X's agent succeeds in far fewer cases, and when it fails nobody can tell why. Team Y's agent succeeds much more often, and its failures are logged and fixable. The model is the same, so the difference comes from the harness. This is the practical meaning of the saying that the harness often matters more than the model.