GPT-5.6's New Prompting Guide: What to Write Less of, and What to Write More of

On July 22, 2026, OpenAI updated its Model guidance. In this latest prompting guide for GPT-5.6, there is an engineering move that runs counter to many people’s habits: when an Agent is given sufficient context, the developer does not need to manually spell out specific intermediate execution steps line by line in the prompt.

For a long time, the prevailing habit was to write steps in as much detail as possible, hoping to pin the Agent to a pre-planned trajectory with a string of operational instructions. The latest guidance doesn’t ask people to give up control; it shifts where the constraints are placed: the effort once spent on prescribing routes is reallocated to clarifying the final deliverables, the verification evidence that must be left behind, and which critical operations require human approval.

Reading only this page of the update, it is easy to assume this is just a casually adjusted prompting trick. But if you pull together the prompting documentation that OpenAI has previously made public for GPT-4.1, GPT-5, and GPT-5.6, a coherent engineering thread emerges.

GPT-5.6: Write Fewer Steps, Specify the Deliverables

Cleaning up prompt redundancy in a concrete project is not about shortening instructions by intuition. What GPT-5.6 recommends is straightforward: on a representative test set, delete the route descriptions from the prompt group by group, re-run the tasks, and observe whether the quality metrics and evidence have regressed.

Only when the test metrics remain stable after deletion can that portion of instructions be considered safely removable; if the readings drop, add the removed constraints back in. OpenAI tried this kind of ablation testing on its internal coding Agent, and removing unnecessary steps brought directional improvements, with the effect depending on the specific workload. This approach of using test metrics to decide what instructions stay or go is precisely the key point discussed in Evaluation-First: What the Cursor Agent Harness Article Is Really Worth Reading: you cannot guess which prompt passages are useful by intuition; every simplification must be validated through eval data to verify that output quality is preserved. The method used here for ablation validation is referred to in the guide as lean-prompt.

After omitting intermediate steps, what remains in the prompt becomes more explicit instead. The guide organizes a checklist built around delivering results: task objectives, domain context, hard constraints, approval boundaries, success criteria, rules for asking clarifying questions when facing ambiguity, the required verification evidence, and the output format. Taken together, these elements constitute the concrete requirements that constrain an Agent’s delivery quality.

If deleting step-by-step instructions on the test set still keeps the metrics stable, it raises a puzzling question: why, in earlier official prompting guides, did developers have to spend so many pages spelling out every intermediate step in the system prompt?

GPT-4.1: Writing Routes into the Prompt

Rewind to April 14, 2025, and the GPT-4.1 Prompting Guide was released. The SWE-bench sample prompt inside it shows how things were done at the time: the developer hard-coded an entire eight-step workflow directly into the system prompt.

The prompt explicitly required the model to write a plan before each tool call, reflect after using tools, and run tests after modifying code. It also included multiple reminders to prevent the Agent from giving up or drifting off course during long tasks. This approach made perfect sense at the time. Whether the committed code passed automated testing could verify whether the final product was correct, but during execution, the model’s inherent uncertainty could cause the Agent to lose context at any moment, deviate from the mainline, or terminate prematurely. The detailed eight-step route was essentially using a deterministic workflow to constrain behavioral drift during execution, helping the Agent navigate the full journey reliably.

When models started to comprehend longer contexts and make sensible tool choices on their own, rigidly spelling out every path in the prompt became too cumbersome. Developers needed to know in which scenarios they could grant the Agent more autonomy, and where they had to set checkpoints.

GPT-5: Routes Begin to Loosen

The GPT-5 prompting guide released on August 7, 2025, didn’t answer by simply deleting route instructions wholesale; it presented a continuous spectrum of delegation.

Developers no longer assumed that every task required rigidly prescribed routes. Instead, they matched the scope of delegation to the scenario: from completely context-guided autonomous decision-making by the model, to programmatically controlled branching with code. The guide began to focus on how to regulate the model’s agentic eagerness, guiding developers to define exploration boundaries, early stopping conditions, and termination criteria, and to separate routine safe operations from high-risk actions that require confirmation. The core demand of the prompt changed: no longer the mechanical command of every step to take, but the decision of when a task can continue, when it must stop, and when it needs to consult a human.

As the model’s ability to understand context and plan routes improved, developers also gradually figured out how to use completion conditions, verification evidence, and permission boundaries as constraints. GPT-5.6 consolidates this approach into building prompts around delivery outcomes. But what does this shift in control actually look like in terms of concrete code changes in real projects?

The Same Thing in a Translation System

Applying this control philosophy to the English translation system at Superlinear Academy for processing long-form Chinese articles, I stepped into the same pitfalls.

In the early days of handling long-article translation, the model’s generation uncertainty frequently broke the workflow: texts would be silently truncated mid-stream, Chinese characters would slip into the translation output, Markdown formatting would be lost, or long-text generation would time out. To keep the system stable, I built a heavy defense mechanism in the outer code layer, attempting to pre-empt every possible recovery path. I wrote logic for paragraph splitting, exception retries, terminology context stitching, and checkpoint resume — just as I had attempted in Wide Research. While this design did manage to run end-to-end, it also consumed a great deal of energy maintaining cumbersome format validation code.

Later, Claude Code and Codex demonstrated a lighter way to organize things: keep state in the local filesystem and establish a standard agentic loop. On-disk files hold persistent state; the Agent can write chapter by chapter and read context on its own, and after interruption it can resume by reading the files. Faced with a long article translation, the Agent can autonomously decide whether to read through the entire text first, write its own Python regex checking script, re-translate a certain paragraph, or first cross-check domain terminology. I no longer intervene in the specific translation route. Instead, I provide a deliverable specification composed of three parts:

1. Completion conditions: Define when the task reaches a qualified termination state. For long-article translation, the focus is on whether any Chinese characters remain in the full text, whether Markdown formatting is fully preserved, and whether specific English terminology remains consistent throughout. In code-fixing scenarios, it means all unit tests pass and no new lint warnings appear.
2. Verification evidence: Objective proof that the completion conditions have been satisfied. For example, the output of a Python regex checking script that the Agent wrote and ran itself, automated test logs, or eval scores. In regulated or incident-postmortem scenarios, the process record itself is also indispensable verification evidence and should not be treated as optional supplementary material.
3. Permission boundaries: Clarify the activity scope and forbidden zones when the Agent chooses its own path. For example, strictly limit the tool-calling range through the --allowedTools parameter, and for high-risk actions involving filesystem overwrites, external API publishing, or procurement, enforce Guardrails and human review mechanisms. Only when the translation output satisfies format completeness, has no residual Chinese, and maintains terminology consistency, and after human approval, is external publication permitted.

Closing: Keep the Success Criteria in Your Own Hands

Using completion conditions and permission boundaries to guard the exit does not mean the system automatically achieves one hundred percent reliability.

In real development, you still need to build an evaluation-first testing system, paired with controlled ablation tests, to progressively streamline non-essential step interventions from prompts while solidifying permission boundaries and side-effect interception at the tool-configuration layer.

As inference costs continue to decline, as discussed in Disposable Software and Compressed Reality, trading token consumption and closed-loop self-checks for ultimate delivery reliability has become increasingly cost-effective. But if you introduce an Agent framework without clear boundaries and constraints, blindly letting the model roam freely, it will instead bring greater technical debt. Developers who wish to establish this new engineering balance and control boundary in concrete application scenarios can refer to the operational guide we have compiled.

A reliable Agent system is not built by micro-managing every step, nor is it achieved by letting go entirely. What developers need to do is release the route to a model with sufficient context, while keeping the completion criteria, verification evidence, and permission boundaries firmly in their own hands.