Write Assignments, Not Scripts: What OpenAI's GPT-6 Guide Says About Agent Prompts

OpenAI's new guide to the GPT-6 family makes a claim that changes how I would write agent instructions: models understand nuance well enough now that "overly specific guidance can now hinder results where it previously helped."

The guide, published October 2, attributes that line to Eric Provencher of Developer Experience at OpenAI. It then describes what to write instead of a script: a clear assignment.

This is vendor guidance for OpenAI's models, not a neutral study. I have not tested its claims, and the guide does not publish evaluation numbers for this advice. But the structure is useful whatever model you use, because it names the four things an agent instruction most often leaves out.

What does OpenAI mean by a clear assignment?

The guide's wording is: "the result you want, who it's for, the relevant context and constraints, and what counts as done."

That is four parts:

1. The result. What should exist when the work is finished.

2. The audience. Who will read or use it.

3. Context and constraints. What the model should know and what limits apply.

4. What counts as done. The finish line, stated outright.

The newsletter that pointed me to the guide, TAAFT's October 4 issue, summarizes the same four parts for everyday prompting. The guide itself applies them to Codex and API agents.

The reason the fourth part matters is simple. An agent that does not know what done means will stop early, or keep going. Neither is a model failure. It is a missing instruction.

What does it say to do with skills, AGENTS.md, and boundaries?

The guide points to four areas to review, summarized from OpenAI's separate piece on rethinking skills and prompts for GPT-6 Astra:

• Skills. Keep descriptions short and explicit about when each skill should run, load supporting details only when needed, and replace rigid recipes with guidance suited to the models your team uses.
• AGENTS.md. Explain when particular documents and tests are relevant, and explicitly authorize safe routine workflows. The guide's example is running local tests with disposable data and no production access.
• Decision boundaries. State which actions can proceed independently and which need approval. The guide says to replace blanket "always ask" rules with clear boundaries.
• Persistence. Define what done includes: implementing the change, running it, inspecting the result, and fixing failures. Name any decisions that require your review.

The third item is the one I find most useful. A blanket "always ask before acting" rule feels safe, but it makes the agent stop on trivia and gives you no signal about what actually matters. A boundary names the few actions that need a human and lets the rest proceed.

What does a before and after look like?

This is a hypothetical example I wrote to illustrate the structure. It is not taken from the guide or from a real project.

Before:

Fix the failing test. Always ask before changing anything.
Do not touch other files. Run tests after each edit.

After:

Result: the failing checkout test passes and the fix is merged-ready.
Audience: a reviewer who has not seen this bug.
Context and limits: use the local test database only. No production
access. Do not change the public API of the checkout module.
Decisions: you may rename internal helpers and add tests. Ask me before
changing a dependency or a database migration.
Done: the full test suite passes, you ran it, and your final message
lists what changed, what you checked, and anything left for me.

The second version is longer, but it is not more rigid. It says what success looks like, what is safe, and what needs a person. The first version gives the agent a rule for every edit and no description of the goal.

The guide's last line of advice on output fits here too. It suggests asking for a short handoff covering what changed, what was checked, and what still needs attention.

Why does this matter beyond OpenAI models?

Because the failure modes it targets are general.

An agent without a definition of done is hard to evaluate. You cannot tell whether it finished or gave up. An agent without decision boundaries either interrupts you constantly or acts where it should have asked. And a prompt that scripts every step can lock in a plan that no longer fits the task.

I covered the enforcement side in the runtime permissions article. Instructions and enforcement do different jobs. A decision boundary written in a prompt tells the agent what you expect. A permission in the runtime limits what it can do if it ignores you. You want both.

What should you be careful about?

• This is a vendor's advice for its own models. The guide does not show test results for the "less specific" claim. Treat it as a hypothesis to try on your own tasks.
• Less specific is not vague. The guide's advice still asks for four concrete parts. It removes step-by-step scripting, not clarity.
• Some features are new. The guide says multi-agent delegation in GPT-6.1 Sol is in beta, and that mid-turn steering updates are queued and do not undo completed actions.
• Measure. The guide itself recommends running representative tasks and tracking task success, latency, and cost per successful task. Do that before and after rewriting prompts.

If you want a low-risk experiment, rewrite one recurring agent instruction in the four-part form and compare outcomes over a week of real tasks. Keep the old version for comparison.

FAQ

Does the guide say detailed prompts are always worse?

No. It says overly specific guidance can now hinder results where it previously helped, and attributes the line to an OpenAI developer experience engineer. It still asks for a clear assignment with context and constraints.

What are the four parts of an assignment?

The result you want, who it is for, the relevant context and constraints, and what counts as done.

What should I put in AGENTS.md?

According to the guide, explain when particular documents and tests are relevant, and explicitly authorize safe routine workflows, such as running local tests with disposable data and no production access.

Is "always ask before acting" a good safety rule?

The guide recommends replacing blanket rules with decision boundaries that say which actions can proceed alone and which need approval. For hard limits, use runtime permissions, not prompt text.

Does this only apply to GPT-6?

The guide is written for GPT-6 models. The four-part structure is general, but whether less specific prompts help another model is something you would need to test.

What does "what counts as done" include?

The guide's example for coding work is implementing the change, running it, inspecting the result, and fixing failures, plus naming any decisions that need your review.

How do I know if the new style works for me?

Compare task success, latency, and cost per successful task on representative work before and after. The guide recommends measuring those three in its production checklist.