Anyone migrating a prompt between providers often runs into a simple trap: the names look equivalent, but the architecture is not. In August 2026, OpenAI, Anthropic, and Google converge on the idea of separating high-level instructions from the user's immediate request, yet each API represents that separation differently. Copying a payload and changing only the model name can alter the authority, context, and even the meaning of an instruction.
The short answer is this: developer message is an explicit layer at OpenAI, but it is not a universal role. In the Claude API, persistent application rules normally go into system, while the conversation uses user and assistant; compatible models also allow system instructions in the middle of a conversation. In the Gemini API, the high-level rule goes into system_instruction, and conversation turns use user and model. Therefore, the concept is portable; the role name is not.
What instruction hierarchy actually means
Instruction hierarchy is the mechanism by which the model decides what to do when it receives incompatible guidance from different sources. The issue is not only the order in which text appears. The central point is the authority assigned to the source of that instruction.
If an application says that the response must follow a rule and the user asks for the opposite, the result depends on where the rule was placed and on how that provider interprets the layer. The same applies to instructions found in documents, web pages, tool outputs, or conversation history. Treating all of it as equivalent text increases the risk that the wrong instruction wins.
This distinction gained particular importance at OpenAI in 2026. On March 10, the company published IH-Challenge, work aimed at training frontier models to follow instructions according to trust level. The publication summarizes the operational order used in that context as system above developer, developer above user, and user above tool. OpenAI's Model Spec is broader still and includes levels the developer does not directly control, such as Root, above System.
For application builders, this leads to a practical rule: do not confuse position in the payload with authority. An instruction needs to be in the correct semantic layer.
OpenAI: developer is its own layer and sits above the user
Among the three providers, OpenAI is the one that publishes the hierarchy most explicitly. Current Responses API documentation describes messages with roles that indicate the instruction-following hierarchy and states that developer or system have precedence over user. The Model Spec organizes the chain of authority as Root, System, Developer, User, and Guideline.
Root and part of System are controlled by OpenAI itself. For the application developer, the most important layer is Developer. This is where product rules, persistent behavior, expected format, agent limits, and other instructions belong when the end user should not be able to replace them simply by writing a conflicting request.
User represents the user's request and the data supplied for that interaction. Assistant represents previous model responses and helps form the history, but it should not be treated as a substitute for an application instruction. Tool outputs and content retrieved from external sources require additional care because they may contain text that looks like a command even though it should be treated as data.
Why system and developer still cause confusion at OpenAI
The confusion exists because system was historically used as the place where the developer put the main prompt. Chat Completions documentation now states that, with o1 models and newer, developer messages replace the older system messages for that purpose. At the same time, the API continues to expose system in different surfaces, and the Model Spec keeps System as a level above Developer.
For new applications, this favors a clear convention: use Developer for rules that belong to your application and User for the user's request. If the surface you use offers an instructions field, treat it as the high-level instruction area provided by the API and check how it is serialized for the selected model. In the Responses API, instructions from a previous response are not automatically carried forward merely because you reuse previous_response_id; if a rule needs to remain in force, the application must provide it again according to the API flow.
This difference matters because a robust architecture should not depend on implicit memory. A persistent rule is the application's responsibility, not a side effect of history.
Claude: system exists, but there is no equivalent developer message
In the Claude API, the traditional Messages API structure is different. The top-level system field receives the instructions that should guide Claude from the outset, while the messages array represents the conversation with user and assistant roles. The official reference specifically emphasizes that the system prompt is not, in the classic format, a regular turn inserted as the first item in messages.
This means an OpenAI developer message should not be converted literally into a role called developer when migrating to Claude. The semantic function of that rule should normally be mapped to system.
In 2026, a new nuance appeared. Claude documentation began allowing, on compatible models, messages with role system in the middle of a conversation. They can introduce or update system instructions without rewriting the entire prefix. On those surfaces, a later system instruction takes precedence over an earlier system instruction for subsequent turns. The feature depends on the model and does not turn developer into a new role in the Messages API.
Assistant history is not a policy layer
Claude also allows assistant messages to appear in history and, in some flows, to be used to partially start the next response. That can shape continuation, but it is something else. Response history should not store critical rules that belong in system.
There is also a difference between the Claude product and the Claude API. Anthropic publishes notes about system prompts used on claude.ai and in mobile applications, but makes clear that those product updates are not the same prompt a developer sends through the API. When comparing providers, you must separate the behavior of the consumer application from the API contract.
Gemini: system_instruction is the developer's rule, with no developer role
In the Gemini API, the closest parallel to the application's persistent layer is system_instruction. Google's documentation describes this field as a system instruction defined by the developer and shows its use both for content generation and in the Interactions API.
In the GenerateContent format, conversation contents use role user or role model. The Content type reference itself limits the producer of a turn to those two values. Therefore, there is no separate developer role equivalent to OpenAI's. The rule that would go into Developer in an OpenAI architecture is usually placed in system_instruction in Gemini.
In the Interactions API, the shape can look even simpler: system_instruction appears as a configuration parameter and the request can be sent in input. The idea remains the same: separate stable behavior from the immediate request.
The cover of this article uses the expression developer instruction in the Gemini column as a conceptual layer for a developer-defined rule. In the actual Gemini API payload, however, that function is materialized in system_instruction; there is no separate developer role in the standard conversation structure.
System prompt is a common concept, not a common contract
The expression system prompt is widely used in the market to mean high-level instructions. That is useful in a conceptual discussion, but it can get in the way when someone turns the concept directly into code.
At OpenAI, System and Developer are distinct levels in the authority specification, and Developer is the explicit layer for application instructions. At Anthropic, system is the main field for this kind of rule and there is no equivalent developer role. In Gemini, system_instruction is defined by the developer, while the conversation works with user and model.
For that reason, an internal library should not store only a string called system_prompt and dump it in the same place for every provider. It is better to separate the intent of the instruction from the API syntax.
Where to place each type of rule when working with all three providers
Stable application rules
Operational persona, default language, flow limits, response criteria, and rules that should not be replaced by the user's request belong to the application layer. At OpenAI, the preferred destination for modern models is Developer or the equivalent instructions area of the surface being used. In Claude, the destination is system. In Gemini, it is system_instruction.
The content can be semantically the same, but the application should have provider-specific adapters. That is where portability should happen.
The user's immediate request
The user's current intent should remain in the layer intended for the user. At OpenAI and Claude, this normally means a user message. In Gemini GenerateContent, it is also user; in the Interactions API, the request may appear in input.
Mixing permanent rules into every user request makes the system more fragile, increases token cost, and makes it harder to identify why a response failed to follow the expected behavior.
Conversation history
History serves continuity, not policy storage. OpenAI and Claude use assistant for previous responses. Gemini uses model. If a rule needs to remain valid, it should continue to be represented in the appropriate instruction layer instead of relying on the model to infer it from an old response.
Documents, tools, and retrieved content
Data from search, RAG, pages, files, and tools should be treated as evidence or context, not as new authority. This distinction is central to protection against prompt injection: a document may contain the phrase ignore previous instructions without that being allowed to change the application's objective.
OpenAI made this relationship explicit in its instruction-hierarchy work and in the Model Spec by treating untrusted content and tool outputs as lower authority. Anthropic and Google use different structures, but secure engineering still requires the developer to separate data from commands rather than relying only on the model's ability to guess intent.
What happens when two instructions conflict
Application rule versus user request
Imagine an internal assistant that must answer only with information found in an approved knowledge base. If the user asks it to ignore that restriction and invent an answer, the structural rule should remain in the application layer. At OpenAI, that means Developer above User. In Claude, the guidance should be in system, not hidden in an old assistant turn. In Gemini, it should be in system_instruction, not mixed into the input text.
The expected practical outcome is similar, but the formal justification is not identical. OpenAI publishes an explicit chain of authority. Anthropic and Google document their fields and uses, but they do not present the same public ladder of levels with the same terminology. It is therefore incorrect to sell the formula system greater than user as if it were an identical universal specification across all three.
An old instruction versus a new rule
In long conversations, rules can change. At OpenAI, the application should send the current instruction in the correct layer and not rely on an old prompt carried by history. In Claude, models compatible with system in the middle of the conversation allow a later system instruction to be inserted, which then takes precedence over earlier system instructions for subsequent turns. In Gemini, the guidance should be updated in the system_instruction configuration of the flow being executed.
The implementation principle is to version rules outside the conversation. History records what happened; the current configuration determines how the agent should work now.
Prompt injection inside an external source
This is the test that best reveals whether the architecture is separating authority from content. If a consulted file contains a command to the model, the application should treat it as part of the document, not as a developer instruction. Placing retrieved content directly in the same layer as application rules is a design flaw, regardless of the provider.
Why prompt hierarchy does not replace software controls
Even a well-defined hierarchy should not be used as the sole authorization mechanism. If an action requires permission, the application must validate that permission in code. If an output must follow a schema, use structured-output features or appropriate validation when available. If a tool can cause a real-world effect, limit parameters, credentials, and scope in the system that executes the action.
Prompts guide the model; they do not replace access control, data validation, business rules, or isolation of untrusted content. OpenAI's 2026 work on instruction hierarchy reinforces precisely the importance of teaching the model to prioritize trusted sources, but this is a defense layer, not a license to remove deterministic controls.
How to design a portable layer across OpenAI, Claude, and Gemini
The most stable approach is to create an internal representation independent of the vendor. Instead of thinking first in system, developer, or user, think in semantic categories: application policy, operational instructions, user request, untrusted context, and history.
In the OpenAI integration, policy and operational instructions are mapped to Developer or to the appropriate instructions mechanism; the request goes to User; the history keeps its roles. In the Claude integration, policy and operational instructions go to system; the request goes to user; the history alternates user and assistant. In the Gemini integration, policy and operational instructions go to system_instruction; the request enters as input or user; the history uses user and model.
This architecture allows you to switch vendors without pretending the APIs are identical. It also makes testing easier, because the same internal rule can be rendered differently and compared in equivalent scenarios.
The minimum test before calling a prompt portable
First, create a direct conflict between the application rule and the user's request. The expected behavior needs to remain stable in each provider.
Next, place a malicious instruction inside a document or tool return and confirm that it is interpreted as data. This test checks whether the adapter has accidentally elevated external content to the wrong layer.
Finally, change a rule in the middle of a long conversation. The test should confirm that the new rule is the one actually applied and that old history does not continue to govern by accident. In Claude, this also requires checking whether the chosen model supports system in the middle of the conversation; in OpenAI and Gemini, it requires attention to how state and instructions are resent on each call.
The rule of thumb for not mixing up the three
If you are using OpenAI, think Developer for application rules and User for the final request, remembering that the platform has higher levels the user does not control. If you are using Claude, think system for persistent rules and user for the request, with assistant as history and system in the middle of the conversation only when the surface and model support it. If you are using Gemini, think system_instruction for developer-defined rules and user or input for the request, with model representing previous responses.
The similarity across providers is in the separation of responsibilities. The difference is in the concrete API contract. That difference is what must be preserved in a migration.
What is worth reviewing in existing projects
Projects that started before developer messages became established at OpenAI may still concentrate everything in system. Claude integrations may carry critical rules repeated in user messages because they were adapted from generic examples. Gemini integrations may treat system_instruction as if it were a third conversation turn, when it is a separate configuration field.
Reviewing these points usually brings more predictability than simply making the prompt longer. A shorter architecture, with each instruction at the right level, is easier to test and port.
It is also important to record the implementation date. APIs evolve quickly. The differences described here reflect official documentation consulted on August 24, 2026. Before deploying a migration, confirm the current reference for the endpoint, model, and selected SDK, especially for model-dependent features such as system messages in the middle of a conversation in Claude.
Common concept does not mean identical implementation
OpenAI, Claude, and Gemini allow developers to separate stable rules from the immediate request, but they do not offer three versions of the same schema. OpenAI formalizes a Developer layer and an explicit chain of authority. Claude concentrates application rules in system and keeps the conversation in user and assistant, with extensions for system in the middle of a conversation on compatible models. Gemini uses system_instruction and restricts content roles to user and model in GenerateContent.
The best practice, therefore, is not to memorize an equivalence table, but to model the intent of each instruction in your own code. Then each adapter sends that intent to the provider's correct field. That is how hierarchy stops being a prompt detail and becomes part of the application architecture.
