Stop Micromanaging Models That Can Already Plan
When GPT-6 Astra shipped on September 3, 2026, OpenAI made an unusual claim: not that the model is smarter in a quiz sense, but that you can delegate tasks with greater confidence in its judgment. The company built a new evaluation, inspired by the earlier Hugging Face incident, that tests whether a model facing a difficult or impossible task will go beyond its intended scope. Astra, OpenAI says, respects task boundaries, understands user intent, and never even attempted to circumvent an auto-review denial in internal tests.
That changes what good prompting looks like. The prompt style that dominated the chat era — scripted, step-by-step, telling the model exactly how to think and in what order — was designed for models that could not plan. The frontier models of late 2026 plan constantly: they reason, call tools, retry, and course-correct. Give one of them a rigid script and you create friction, conflicts, and wasted tokens. The new skill is delegation: writing a brief, not a script.
Why Scripts Backfire on Agentic Models
A scripted prompt assumes the model is a literal executor and you are the architect. An agentic model assumes it is the executor, planner, and quality checker all at once. When those assumptions collide, the model does not simply follow your script; it reconciles your instructions with what it observes, and every contradiction costs you. The habits to unlearn:
- Over-specifying the how. "First do X, then Y, then Z" breaks the moment the environment differs from your mental model, and the model must choose between your stale plan and reality.
- Burying the outcome. A paragraph of process with the actual goal in the last sentence produces meandering work.
- Conflicting constraints. "Be creative" plus "never deviate from this template" is a recipe for the model guessing which one you meant.
- Instruction bloat. Ten paragraphs of rules dilute the few that matter. OpenAI's own guidance for coding agents is strikingly restrained: avoid excessive test files, avoid unrelated cleanup, reuse existing utilities, keep the code clean and mergeable.
Notice what that official guidance does not do. It does not tell the model which files to open or which algorithm to choose. It sets boundaries and a quality bar, then lets the model apply judgment inside them.
The Five-Part Brief
A good delegation prompt reads like a brief you would hand a capable contractor. Five parts, in order:
- Outcome. What does done look like, stated as the result, not the process.
- Constraints. Hard limits: budget, time, scope, tools allowed, things you must not touch.
- Boundaries. What the model should do if it gets stuck or the task turns out to be impossible — ask, stop, or proceed conservatively.
- Definition of done. The acceptance criteria you will check the work against.
- Context pointers. Where the relevant information lives, not a dump of all of it.
A workable template looks like this:
Outcome: A refactored version of the checkout service that removes the duplicated payment-validation logic.
Constraints: No changes to the public API. No new dependencies. Tests must stay green.
Boundaries: If you find the duplication is load-bearing, stop and report instead of refactoring blindly.
Done when: CI passes, the duplication is gone, and you have summarized what you changed and why.
Context: The service lives in services/checkout; the duplication is between validate_card and validate_wallet.
From Script to Brief: A Before and After
Here is the same request written two ways. The scripted version tells the model to list files, read them, then rewrite them, and to be careful. The brief version states the outcome and the boundaries.
Before (script): "First, list every file in the repo. Then read the ones related to payments. Then rewrite the validation logic, but be careful not to break anything, and also keep the code style consistent, and update the tests if needed, and make sure you don't change the database schema, and write a summary at the end..."
After (brief): "Remove the duplicated card-validation logic in services/checkout by extracting one shared module. Keep the public API and database schema untouched. Update the existing tests where they assert the old structure; do not add tests just for coverage. Done when CI passes and you report which call sites changed."
The brief is shorter, yet it gives the model everything the script tried to guarantee through volume: a clear goal, explicit non-negotiables, and a definition of done. The model fills in the plan; you audit the result. That is the division of labor delegation is supposed to achieve.
Match the Prompt to the Model and the Risk
Delegation is not one-size-fits-all. The right amount of instruction depends on two variables: the model's capability and the cost of failure.
For a small local model or a weak API tier, keep more structure — these models still benefit from explicit steps and examples. For a frontier agentic model, add constraints and acceptance criteria instead of process. For irreversible or high-stakes actions, whatever the model, require a verification step: have it state its plan before executing, or route sensitive operations through a human approval gate. Delegation with confidence is not the same as delegation with no supervision; it means supervising outcomes instead of keystrokes.
There is also a context angle. Models reason over what they can see, so a brilliant brief attached to a mountain of irrelevant retrieved documents still fails. Keep the working context tight: the model does not need your entire wiki to refactor one module. Quality of context beats quantity, and a brief that points to the right two documents outperforms one that dumps forty.
The New Prompting Mindset
If you take one habit from the Astra generation of models, let it be this: before you write instructions, decide what you are delegating. State the outcome as if the model were a smart colleague, set the rails, define done, and then get out of the way. When the model asks a clarifying question or flags an impossible request, treat that as success — it means the boundaries were clear enough to be tested. The models got better at judgment; the least we can do is stop scripting every move and start writing briefs they can actually execute.
