# Prompt guidance | OpenAI API
URL: https://developers.openai.com/api/docs/guides/prompt-guidance
# GPT-5.5 prompting guide
Prompt GPT-5.5 with outcome-first goals, concise style controls, retrieval budgets, and validation loops.
## New in GPT-5.5 vs GPT-5.4
- Shorter, outcome-first prompts usually work better than process-heavy prompt stacks.
- More efficient reasoning means `low` and `medium` effort should be re-evaluated before escalating.
- Preambles, `phase` handling, and assistant-item replay remain important for tool-heavy Responses workflows.
- Explicit personality, retrieval budgets, and validation rules help shape customer-facing and agentic UX.
GPT-5.5 works best when prompts define the outcome and leave room for the model to choose an efficient solution path. Compared with earlier models, you can often use shorter, more outcome-oriented prompts: describe what good looks like, what constraints matter, what evidence is available, and what the final answer should contain.
Avoid carrying over every instruction from an older prompt stack. Legacy prompts often over-specify the process because earlier models needed more help staying on track. With GPT-5.5, that can add noise, narrow the model's search space, or lead to overly mechanical answers.
For more detail on GPT-5.5 behavior changes, start with the Using GPT-5.5 guide. This guide focuses on prompt changes that follow from those behavior changes.
The patterns here are starting points. Adapt them to your product surface, tools, evals, and user experience goals.
## Automated migration with Codex
Codex can implement the changes from this guide with the OpenAI Docs Skill.
```text
$openai-docs migrate this project to gpt-5.5
```
To use this skill in other coding agents, download it from the OpenAI skills repository.
## Personality and behavior
GPT-5.5's default style is efficient, direct, and task-oriented. This is useful for production systems: responses stay focused, behavior is easier to steer, and the model avoids unnecessary conversational padding.
For customer-facing assistants, support workflows, coaching experiences, and other conversational products, define both personality and collaboration style.
- Personality controls how the assistant sounds: tone, warmth, directness, formality, humor, empathy, and level of polish.
- Collaboration style controls how the assistant works: when it asks questions, when it makes assumptions, how proactive it should be, how much context it gives, when it checks work, and how it handles uncertainty or risk.
Keep both short. Personality instructions should shape the user experience. Collaboration instructions should shape task behavior. Neither should replace clear goals, success criteria, tool rules, or stopping conditions.
Example personality block for a steady task-focused assistant:
```text
# Personality
You are a capable collaborator: approachable, steady, and direct. Assume the user is competent and acting in good faith, and respond with patience, respect, and practical helpfulness.
Prefer making progress over stopping for clarification when the request is already clear enough to attempt. Use context and reasonable assumptions to move forward. Ask for clarification only when the missing information would materially change the answer or create meaningful risk, and keep any question narrow.
Stay concise without becoming curt. Give enough context for the user to understand and trust the answer, then stop. Use examples, comparisons, or simple analogies when they make the point easier to grasp. When correcting the user or disagreeing, be candid but constructive. When an error is pointed out, acknowledge it plainly and focus on fixing it.
Match the user's tone within professional bounds. Avoid emojis and profanity by default, unless the user explicitly asks for that style or has clearly established it as appropriate for the conversation.
```
Example personality block for an expressive collaborative assistant:
```text
# Personality
Adopt a vivid conversational presence: intelligent, curious, playful when appropriate, and attentive to the user's thinking. Ask good questions when the problem is blurry, then become decisive once there is enough context.
Be warm, collaborative, and polished. Conversation should feel easy and alive, but not chatty for its own sake. Offer a real point of view rather than merely mirroring the user, while staying responsive to their goals and constraints.
Be thoughtful and grounded when the task calls for synthesis or advice. State a clear recommendation when you have enough context, explain important tradeoffs, and name uncertainty without becoming evasive.
```
For more expressive products, add warmth, curiosity, humor, or point of view explicitly, but keep the block short. Use personality to shape the experience, not to compensate for unclear goals or missing task instructions.
## Improve time to first visible token with a preamble
In streaming applications, users notice how long it takes before the first visible response appears. GPT-5.5 may spend time reasoning, planning, or preparing tool calls before emitting visible text.
For longer or tool-heavy tasks, prompt the model to start with a short preamble: a brief visible update that acknowledges the request and states the first step. This can improve perceived responsiveness without changing the underlying task.
Use this pattern when the task may take more than one step, require tool calls, or involve a long-running agent workflow.
```text
Before any tool calls for a multi-step task, send a short user-visible update that acknowledges the request and states the first step. Keep it to one or two sentences.
```
For coding agents that expose separate message phases, you can be more explicit:
```text
You must always start with an intermediary update before any content in the analysis channel if the task will require calling tools. The user update should acknowledge the request and explain your first step.
```
## Outcome-first prompts and stopping conditions
GPT-5.5 is strongest when the prompt defines the target outcome, success criteria, constraints, and available context, then lets the model choose the path.
For many tasks, describe the destination rather than every step. This gives the model room to choose the right search, tool, or reasoning strategy for the task.
Prefer this:
```text
Resolve the customer's issue end to end.
Success means:
- the eligibility decision is made from the available policy and account data
- any allowed action is completed before responding
- the final answer includes completed_actions, customer_message, and blockers
- if evidence is missing, ask for the smallest missing field
```
Avoid unnecessary absolute rules. Older prompts often use strict instructions like `ALWAYS`, `NEVER`, `must`, and `only` to control model behavior. Use those words for true invariants, such as safety rules, required output fields, or actions that should never happen. For judgment calls, such as when to search, ask for clarification, use a tool, or keep iterating, prefer decision rules instead.
Avoid this style of instruction unless every step is truly required:
```text
First inspect A, then inspect B, then compare every field, then think through
all possible exceptions, then decide which tool to call, then call the tool,
then explain the entire process to the user.
```
Add explicit stopping conditions:
```text
Resolve the user query in the fewest useful tool loops, but do not let loop minimization outrank correctness, accessible fallback evidence, calculations, or required citation tags for factual claims.
After each result, ask: "Can I answer the user's core request now with useful evidence and citations for the factual claims?" If yes, answer.
```
Define missing-evidence behavior:
```text
Use the minimum evidence sufficient to answer correctly, cite it precisely, then stop.
```
## Formatting
GPT-5.5 is highly steerable on output format and structure. Use that control when it improves comprehension or product fit.
Set `text.verbosity`, describe the expected output shape, and reserve heavier structure for cases where it improves comprehension or your product UI needs a stable artifact. The API default for `text.verbosity` is `medium`; use `low` when you prefer shorter, more concise responses.
Plain conversational formatting:
```text
Let formatting serve comprehension. Use plain paragraphs as the default format for normal conversation, explanations, reports, documentation, and technical writeups. Keep the presentation clean and readable without making the structure feel heavier than the content.
Use headers, bold text, bullets, and numbered lists sparingly. Reach for them when the user requests them, when the answer needs clear comparison or ranking, or when the information would be harder to scan as prose. Otherwise, favor short paragraphs and natural transitions.
Respect formatting preferences from the user. If they ask for a terse answer, minimal formatting, no bullets, no headers, or a specific structure, follow that preference unless there is a strong reason not to.
```
Add explicit audience and length guidance:
```text
Write for a senior business audience. Keep the answer under 400 words. Use short paragraphs and only include bullets when they improve scannability. Prioritize the conclusion first, then the reasoning, then caveats.
```
For editing, rewriting, summaries, or customer-facing messages, tell the model what to preserve before asking it to improve style. This pattern is useful when you want polish without expansion.
```text
Preserve the requested artifact, length, structure, and genre first. Quietly improve clarity, flow, and correctness. Do not add new claims, extra sections, or a more promotional tone unless explicitly requested.
```
## Grounding, citations, and retrieval budgets
For grounded answers, citation behavior should be part of the prompt. Define what needs support, what counts as enough evidence, and how the model should behave when evidence is missing. Absence of evidence shouldn't automatically become a factual "no." For more details and examples, see the citation formatting guide.
### Add an explicit retrieval budget
Retrieval budgets are stopping rules for search. They tell the model when enough evidence is enough.
```text
For ordinary Q&A, start with one broad search using short, discriminative keywords. If the top results contain enough citable support for the core request, answer from those results instead of searching again.
Make another retrieval call only when:
- The top results do not answer the core question.
- A required fact, parameter, owner, date, ID, or source is missing.
- The user asked for exhaustive coverage, a comparison, or a comprehensive list.
- A specific document, URL, email, meeting, record, or code artifact must be read.
- The answer would otherwise contain an important unsupported factual claim.
Do not search again to improve phrasing, add examples, cite nonessential details, or support wording that can safely be made more generic.
```
## Creative drafting guardrails
For drafting tasks, tell the model which claims must come from sources and which parts may be creatively written. This is especially important for slides, launch copy, customer summaries, talk tracks, leadership blurbs, and narrative framing.
```text
For creative or generative requests such as slides, leadership blurbs, outbound copy, summaries for sharing, talk tracks, or narrative framing, distinguish source-backed facts from creative wording.
- Use retrieved or provided facts for concrete product, customer, metric, roadmap, date, capability, and competitive claims, and cite those claims.
- Do not invent specific names, first-party data claims, metrics, roadmap status, customer outcomes, or product capabilities to make the draft sound stronger.
- If there is little or no citable support, write a useful generic draft with placeholders or clearly labeled assumptions rather than unsupported specifics.
```
## Frontend engineering and visual taste
For frontend work, refer to the example instructions for practical ways to steer UI quality. They cover product and user context, design-system alignment, first-screen usability, familiar controls, expected states, responsive behavior, and common generated-UI defaults to avoid, such as generic heroes, nested cards, decorative gradients, visible instructional text, and broken layouts.
## Prompt the model to check its work
Give GPT-5.5 access to tools that let it check outputs when validation is possible.
For coding agents, ask for concrete validation commands:
```text
After making changes, run the most relevant validation available:
- targeted unit tests for changed behavior
- type checks or lint checks when applicable
- build checks for affected packages
- a minimal smoke test when full validation is too expensive
If validation cannot be run, explain why and describe the next best check.
```
For visual artifacts, ask for inspection after rendering:
```text
Render the artifact before finalizing. Inspect the rendered output for layout, clipping, spacing, missing content, and visual consistency. Revise until the rendered output matches the requirements.
```
For engineering and planning tasks, make implementation plans traceable:
```text
For implementation plans, include:
- requirements and where each is addressed
- named resources, files, APIs, or systems involved
- state transitions or data flow where relevant
- validation commands or checks
- failure behavior
- privacy and security considerations
- open questions that materially affect implementation
```
## Phase parameter
Starting with GPT-5.4, long-running or tool-heavy Responses workflows can use assistant-item `phase` values to distinguish intermediate updates from final answers. GPT-5.5 uses the same pattern.
If you use `previous_response_id`, the API preserves prior assistant state automatically. If your application manually replays assistant output items into the next request, preserve each original `phase` value and pass it back unchanged. This matters most when a response includes preambles, repeated tool calls, or a final answer after intermediate assistant updates.
```text
If manually replaying assistant items:
- Preserve assistant `phase` values exactly.
- Use `phase: "commentary"` for intermediate user-visible updates.
- Use `phase: "final_answer"` for the completed answer.
- Do not add `phase` to user messages.
```
## Suggested prompt structure
Use this structure as a starting point for complex prompts. Keep each section short. Add detail only where it changes behavior.
```text
Role: [1-2 sentences defining the model's function, context, and job]
# Personality
[tone, demeanor, and collaboration style]
# Goal
[user-visible outcome]
# Success criteria
[what must be true before the final answer]
# Constraints
[policy, safety, business, evidence, and side-effect limits]
# Output
[sections, length, and tone]
# Stop rules
[when to retry, fallback, abstain, ask, or stop]
```
---
# Prompt engineering | OpenAI API
URL: https://developers.openai.com/api/docs/guides/prompt-engineering
# Prompt engineering
With the OpenAI API, you can use a large language model to generate text from a prompt, as you might using ChatGPT. Models can generate almost any kind of text response—like code, mathematical equations, structured JSON data, or human-like prose.
Here's a simple example using the Responses API.
An array of content generated by the model is in the `output` property of the response. In this simple example, we have just one output which looks like this:
```json
[
{
"id": "msg_67b73f697ba4819183a15cc17d011509",
"type": "message",
"role": "assistant",
"content": [
{
"type": "output_text",
"text": "Under the soft glow of the moon, Luna the unicorn danced through fields of twinkling stardust, leaving trails of dreams for every child asleep.",
"annotations": []
}
]
}
]
```
The `output` array often has more than one item in it! It can contain tool calls, data about reasoning tokens generated by reasoning models, and other items. It is not safe to assume that the model's text output is present at `output[0].content[0].text`.
Some of our official SDKs include an `output_text` property on model responses for convenience, which aggregates all text outputs from the model into a single string. This may be useful as a shortcut to access text output from the model.
In addition to plain text, you can also have the model return structured data in JSON format - this feature is called Structured Outputs.
## Choosing a model
A key choice to make when generating content through the API is which model you want to use - the `model` parameter of the code samples above. You can find a full listing of available models here. Here are a few factors to consider when choosing a model for text generation.
- Reasoning models generate an internal chain of thought to analyze the input prompt, and excel at understanding complex tasks and multi-step planning. They are also generally slower and more expensive to use than GPT models.
- GPT models are fast, cost-efficient, and highly intelligent, but benefit from more explicit instructions around how to accomplish tasks.
- Large and small (mini or nano) models offer trade-offs for speed, cost, and intelligence. Large models are more effective at understanding prompts and solving problems across domains, while small models are generally faster and cheaper to use.
When in doubt, `gpt-5.5` offers a strong default for general-purpose text generation and prompt iteration.
## Prompt engineering
Prompt engineering is the process of writing effective instructions for a model, such that it consistently generates content that meets your requirements.
Because the content generated from a model is non-deterministic, prompting to get your desired output is a mix of art and science. However, you can apply techniques and best practices to get good results consistently.
Some prompt engineering techniques work with every model, like using message roles. But different model types (like reasoning versus GPT models) might need to be prompted differently to produce the best results. Even different snapshots of models within the same family could produce different results. So as you build more complex applications, we strongly recommend:
- Pinning your production applications to specific model snapshots (like `gpt-4.1-2025-04-14` for example) to ensure consistent behavior
- Building tests and evaluation suites that measure prompt behavior so you can monitor performance as you iterate, or when you change and upgrade model versions
Now, let's examine some tools and techniques available to you to construct prompts.
## Message roles and instruction following
You can provide instructions to the model with differing levels of authority using the `instructions` API parameter or message roles.
The `instructions` parameter gives the model high-level instructions on how it should behave while generating a response, including tone, goals, and examples of correct responses. Any instructions provided this way will take priority over a prompt in the `input` parameter.
Generate text with instructions (JavaScript):
```javascript
import OpenAI from "openai";
const client = new OpenAI();
const response = await client.responses.create({
model: "gpt-5.5",
reasoning: { effort: "low" },
instructions: semicolonsDevMsg,
input: semicolonsPrompt,
});
console.log(response.output_text);
```
Generate text with instructions (Python):
```python
from openai import OpenAI
client = OpenAI()
response = client.responses.create(
model="gpt-5.5",
reasoning={"effort": "low"},
instructions=semicolonsDevMsg,
input=semicolonsPrompt,
)
print(response.output_text)
```
The example above is roughly equivalent to using the following input messages in the `input` array:
Generate text with messages using different roles (JavaScript):
```javascript
import OpenAI from "openai";
const client = new OpenAI();
const response = await client.responses.create({
model: "gpt-5.5",
reasoning: { effort: "low" },
input: [
{
role: "developer",
content: semicolonsDevMsg
},
{
role: "user",
content: semicolonsPrompt,
},
],
});
console.log(response.output_text);
```
Generate text with messages using different roles (Python):
```python
from openai import OpenAI
client = OpenAI()
response = client.responses.create(
model="gpt-5.5",
reasoning={"effort": "low"},
input=[
{
"role": "developer",
"content": semicolonsDevMsg
},
{
"role": "user",
"content": semicolonsPrompt
}
]
)
print(response.output_text)
```
Note that the `instructions` parameter only applies to the current response generation request. If you are managing conversation state with the `previous_response_id` parameter, the `instructions` used on previous turns will not be present in the context.
The OpenAI model spec describes how our models give different levels of priority to messages with different roles.
| Role | Priority / Description |
| --- | --- |
| `developer` | `developer` messages are instructions provided by the application developer, prioritized ahead of `user` messages. |
| `user` | `user` messages are instructions provided by an end user, prioritized behind `developer` messages. |
| `assistant` | Messages generated by the model have the `assistant` role. |
A multi-turn conversation may consist of several messages of these types, along with other content types provided by both you and the model. Learn more about managing conversation state here.
You could think about `developer` and `user` messages like a function and its arguments in a programming language.
- `developer` messages provide the system's rules and business logic, like a function definition.
- `user` messages provide inputs and configuration to which the `developer` message instructions are applied, like arguments to a function.
## Version prompts in code
Store production prompts in your application code instead of creating reusable prompt objects. Code-managed prompts let you use typed inputs, code review, tests, and your normal deployment process to change model behavior.
OpenAI is deprecating reusable prompt objects in the API. Prompt creation will be de-emphasized beginning June 3, 2026, and `v1/prompts` is scheduled to shut down on November 30, 2026. See the deprecations page for the current timeline.
For new prompt-engineering work:
- Keep prompt builders in a small module near the feature they support.
- Use typed function arguments or schemas for dynamic values such as customer data, files, or task options.
- Pass the generated `instructions` and `input` directly to the Responses API.
- Add representative fixtures, tests, and evaluation checks before changing production prompts.
- Roll out prompt changes through your deployment system, using feature flags or configuration when you need staged releases.
If your integration already calls a saved prompt with a prompt ID or version, use the prompt object migration guide to move that prompt into code.
## Message formatting with Markdown and XML
When writing `developer` and `user` messages, you can help the model understand logical boundaries of your prompt and context data using a combination of Markdown formatting and XML tags.
Markdown headers and lists can be helpful to mark distinct sections of a prompt, and to communicate hierarchy to the model. They can also potentially make your prompts more readable during development. XML tags can help delineate where one piece of content (like a supporting document used for reference) begins and ends. XML attributes can also be used to define metadata about content in the prompt that can be referenced by your instructions.
In general, a developer message will contain the following sections, usually in this order (though the exact optimal content and order may vary by which model you are using):
- Identity: Describe the purpose, communication style, and high-level goals of the assistant.
- Instructions: Provide guidance to the model on how to generate the response you want. What rules should it follow? What should the model do, and what should the model never do? This section could contain many subsections as relevant for your use case, like how the model should call custom functions.
- Examples: Provide examples of possible inputs, along with the desired output from the model.
- Context: Give the model any additional information it might need to generate a response, like private/proprietary data outside its training data, or any other data you know will be particularly relevant. This content is usually best positioned near the end of your prompt, as you may include different context for different generation requests.
Below is an example of using Markdown and XML tags to construct a `developer` message with distinct sections and supporting examples.
Example prompt: A developer message for code generation
```text
# Identity
You are coding assistant that helps enforce the use of snake case
variables in JavaScript code, and writing code that will run in
Internet Explorer version 6.
# Instructions
* When defining variables, use snake case names (e.g. my_variable)
instead of camel case names (e.g. myVariable).
* To support old browsers, declare variables using the older
"var" keyword.
* Do not give responses with Markdown formatting, just return
the code as requested.
# Examples
How do I declare a string variable for a first name?
var first_name = "Anna";
```
API request (JavaScript):
```javascript
import fs from "fs/promises";
import OpenAI from "openai";
const client = new OpenAI();
const instructions = await fs.readFile("prompt.txt", "utf-8");
const response = await client.responses.create({
model: "gpt-5.5",
instructions,
input: "How would I declare a variable for a last name?",
});
console.log(response.output_text);
```
API request (Python):
```python
from openai import OpenAI
client = OpenAI()
with open("prompt.txt", "r", encoding="utf-8") as f:
instructions = f.read()
response = client.responses.create(
model="gpt-5.5",
instructions=instructions,
input="How would I declare a variable for a last name?",
)
print(response.output_text)
```
#### Save on cost and latency with prompt caching
When constructing a message, you should try and keep content that you expect to use over and over in your API requests at the beginning of your prompt, and among the first API parameters you pass in the JSON request body to Chat Completions or Responses. This enables you to maximize cost and latency savings from prompt caching.
## Few-shot learning
Few-shot learning lets you steer a large language model toward a new task by including a handful of input/output examples in the prompt, rather than fine-tuning the model. The model implicitly "picks up" the pattern from those examples and applies it to a prompt. When providing examples, try to show a diverse range of possible inputs with the desired outputs.
Typically, you will provide examples as part of a `developer` message in your API request. Here's an example `developer` message containing examples that show a model how to classify product reviews.
```text
# Identity
You are a helpful assistant that labels short product reviews as
Positive, Negative, or Neutral.
# Instructions
* Only output a single word in your response with no additional formatting
or commentary.
* Your response should only be one of the words "Positive", "Negative", or
"Neutral" depending on the sentiment of the product review you are given.
# Examples
I absolutely love this headphones — sound quality is amazing!
Positive
Battery life is okay, but the ear pads feel cheap.
Neutral
Terrible customer service, I'll never buy from them again.
Negative
```
## Include relevant context information
It is often useful to include additional context information the model can use to generate a response within the prompt you give the model. There are a few common reasons why you might do this:
- To give the model access to proprietary data, or any other data outside the data set the model was trained on.
- To constrain the model's response to a specific set of resources that you have determined will be most beneficial.
The technique of adding additional relevant context to the model generation request is sometimes called retrieval-augmented generation (RAG). You can add additional context to the prompt in many different ways, from querying a vector database and including the text you get back into a prompt, or by using OpenAI's built-in file search tool to generate content based on uploaded documents.
#### Planning for the context window
Models can only handle so much data within the context they consider during a generation request. This memory limit is called a context window, which is defined in terms of tokens (chunks of data you pass in, from text to images).
Models have different context window sizes from the low 100k range up to one million tokens for newer GPT-4.1 models. Refer to the model docs for specific context window sizes per model.
## Prompting current GPT-5 series models
GPT models like `gpt-5.5` benefit from precise instructions that explicitly provide the logic and data required to complete the task in the prompt. To get the most out of the latest GPT-5 series model, start with the current prompting guide.
### Prompting best practices for the latest GPT-5 series model
For the full current treatment, use the prompt guidance guide. The practical reminders below still apply.
#### Coding
Prompting `gpt-5.5` for coding tasks is most effective when following a few best practices: define the agent's role, enforce structured tool use with examples, require thorough testing for correctness, and set Markdown standards for clean output.
- **Explicit role and workflow guidance**: Frame the model as a software engineering agent with well-defined responsibilities. Provide clear instructions for using tools like `functions.run` for code tasks, and specify when not to use certain modes—for example, avoid interactive execution unless necessary.
- **Testing and validation**: Instruct the model to test changes with unit tests or Python commands, and validate patches carefully since tools like `apply_patch` may return “Done” even on failure.
- **Tool use examples**: Include concrete examples of how to invoke commands with the provided functions, which improves reliability and adherence to expected workflows.
- **Markdown standards**: Guide the model to generate clean, semantically correct markdown using inline code, code fences, lists, and tables where appropriate—and to format file paths, functions, and classes with backticks.
For detailed guidance and prompt samples specific to coding, see our prompt guidance guide.
#### Front-end engineering
GPT-5.5 performs well at building front ends from scratch as well as contributing to large, established codebases. To get the best results, we recommend using the following libraries:
- Styling / UI: Tailwind CSS, shadcn/ui, Radix Themes
- Icons: Lucide, Material Symbols, Heroicons
- Animation: Motion
##### Zero-to-one web apps
GPT-5 can generate front-end web apps from a single prompt, no examples needed. Here's a sample prompt:
```bash
You are a world class web developer, capable of producing stunning, interactive, and innovative websites from scratch in a single prompt. You excel at delivering top-tier one-shot solutions.
Your process is simple and follows these steps:
Step 1: Create an evaluation rubric and refine it until you are fully confident.
Step 2: Consider every element that defines a world-class one-shot web app, then use that insight to create a with 5–7 categories. Keep this rubric hidden—it's for internal use only.
Step 3: Apply the rubric to iterate on the optimal solution to the given prompt. If it doesn't meet the highest standard across all categories, refine and try again.
Step 4: Aim for simplicity while fully achieving the goal, and avoid external dependencies such as Next.js or React.
```
##### Integration with large codebases
For front-end engineering work in larger codebases, we've found that adding these categories of instruction to your prompts delivers the best results:
- **Principles**: Set visual quality standards, use modular/reusable components, and keep design consistent.
- **UI/UX**: Specify typography, colors, spacing/layout, interaction states (hover, empty, loading), and accessibility.
- **Structure**: Define file/folder layout for seamless integration.
- **Components**: Give reusable wrapper examples and backend-call separation strategies.
- **Pages**: Provide templates for common layouts.
- **Agent Instructions**: Ask the model to confirm design assumptions, scaffold projects, enforce standards, integrate APIs, test states, and document code.
#### Agentic tasks
For agentic and long-running rollouts with `gpt-5.5`, focus your prompts on three core practices: plan tasks thoroughly to ensure complete resolution, provide clear preambles for major tool usage decisions, and use a TODO tool to track workflow and progress in an organized manner.
##### Planning and persistence
Instruct the model to resolve the full query before yielding control, decomposing it into sub-tasks and reflecting after each tool call to confirm completeness.
```text
Remember, you are an agent - please keep going until the user's
query is completely resolved, before ending your turn and yielding
back to the user. Decompose the user's query into all required
sub-requests, and confirm that each is completed. Do not stop
after completing only part of the request. Only terminate your
turn when you are sure that the problem is solved. You must be
prepared to answer multiple queries and only finish the call once
the user has confirmed they're done.
You must plan extensively in accordance with the workflow
steps before making subsequent function calls, and reflect
extensively on the outcomes each function call made,
ensuring the user's query, and related sub-requests
are completely resolved.
```
##### Preambles for transparency
Ask the model to explain why it is calling a tool, but only at notable steps.
```text
Before you call a tool explain why you are calling it
```
##### Progress tracking with rubrics and TODOs
Use a TODO list tool or rubric to enforce structured planning and avoid missed steps.
For detailed guidance and prompt samples specific to building agents, see the prompt guidance guide.
## Prompting reasoning models
There are some differences to consider when prompting a reasoning model versus prompting a GPT model. Generally speaking, reasoning models will provide better results on tasks with only high-level guidance. This differs from GPT models, which benefit from very precise instructions.
- **Reasoning Model**: Like a senior co-worker. You can give them a goal to achieve and trust them to work out the details.
- **GPT Model**: Like a junior coworker. They'll perform best with explicit instructions to create a specific output.