Match each role marker to the kind of content it should carry in a well engineered context

Match pairs·Easy·4.0 · 0·~2 min·Asked atAccenture Browserbase Infosys

Attempt it

Drag each answer to line up with its matching prompt

system

The current human turn, including the latest question and any user supplied content

developer

Tool call results, with stable identifiers, scoped to the recent tail

user

Prior model turns plus any explicit reasoning or plan blocks the agent has chosen to keep

assistant

Static persona, policies, output contract, content that does not change between turns

tool

Application level rules from the app developer (OpenAI's API) that the user is not supposed to override

Modern LLM (large language model) APIs structure the prompt as a list of messages, and every message carries a role marker. The marker tells the model what kind of content it is reading and how much trust to give it. The system role carries the things that should not change from turn to turn: the assistant's persona, its rules, and its output shape. The developer role is OpenAI's. It carries the app developer's rules that the end user is not supposed to override, and it ranks above the user. Anthropic and Google put this content in system. The user role carries the current human turn: the latest question and any user-supplied content. The model treats it as a request. The assistant role carries prior model output: earlier turns, plus any plan blocks the agent keeps for continuity. The tool role carries the output of tool calls. Each entry carries a stable id so later turns can cite it. These results live near the end of the conversation, not in system. Watch for content in the wrong marker: tool output pasted into user text, or policies placed in the latest user turn. Both degrade how the model reads the prompt.

Role markers are the structural contract between you and the model about what kind of content lives where. There are five common markers, each with a distinct job. **system** is the static layer. It holds persona, hard policies, output schema and refusal rules. This content should not change between turns, and prompt caching needs it byte-stable. **developer** is OpenAI's role for the app developer's rules: app-specific constraints and behavior the end user is not allowed to override. On newer OpenAI models it replaces system messages for app builders. Anthropic and Google put this content in system. Tool definitions go in the separate tools parameter. **user** is the current human input. It includes the latest question, user-uploaded content, and any per-turn data the human supplied. **assistant** holds prior model turns. In an agentic loop, it also holds explicit plan blocks or scratchpad summaries the agent decided to retain. **tool** holds tool-call results, each tagged with a stable id so subsequent assistant turns can refer to them. Tool messages live in the recent tail; old tool outputs get summarized or evicted. The model has been trained to weight these roles differently. Pasting tool output into user text makes the model treat it as a new request. Putting policies in the latest user turn makes them easier to jailbreak. The markers are not labels; they are part of the prompt's meaning.

TL;DR

Role markers split the prompt by content stability and trust: system and developer hold static rules, user and tool hold dynamic input, assistant holds prior model output.

Memory aid

Easy to grasp

Think of a workplace where every message gets stamped before it goes on the bulletin board. The boss's stamp goes on policies and dress codes that hang there all year. The team-lead stamp goes on project-specific rules. The customer stamp goes on incoming questions. The employee stamp goes on the answers your team already gave. The machine stamp goes on receipts from machines on the shop floor. Everyone on the board reads the stamp before reading the message, and decides how much weight to give it. Role markers in an LLM prompt do exactly this stamping. The model has been trained to trust and use each stamp differently.

Key concepts

Context engineering Prompt engineering Agents

Concept explanation~2 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

Every modern LLM API ships a structured prompt: a list of messages, each with a role marker. The markers look like labels but they carry semantic weight. The model has been post-trained to read system messages, developer messages, user messages, assistant messages, and tool messages differently. Treating them as interchangeable string slots is one of the most common mistakes in early context engineering work.

The five common role markers

system carries the static layer: persona, hard policies, refusal rules, output-schema descriptions, brand voice, language constraints. The defining property is that the content does not change between turns of the same session. Anthropic exposes this as a top-level system parameter; OpenAI and Google have analogous structures.

developer is OpenAI's role for the app developer's rules: app-specific constraints and behaviors the end user is not allowed to override. On newer OpenAI models, developer messages replace system messages for app builders, because system-level authority is reserved for OpenAI's own rules. On Anthropic and Google this content goes in system. Tool definitions go in each API's separate tools parameter.

user carries the current human input. This includes the latest question and any user-uploaded content for this turn.

assistant carries prior model output. This includes completed assistant turns from earlier in the session, plus any plan or scratchpad blocks the agent chose to retain.

tool carries tool-call results. Each entry should carry a stable identifier (tool_use_id on Anthropic, tool_call_id on OpenAI Chat Completions) so later assistant turns can cite it. Anthropic has no tool role: tool results travel as tool_result blocks inside a user message.

The structure is the contract

The model uses the role markers to decide how to read the content. That makes them part of the prompt's meaning, not a routing detail.

Two hierarchies hidden in the markers

What goes wrong when you mix markers

Designing the role layout for an agent loop

Situations where this technique stops working.

2–4 min · Everything important, quickly.

Real products, models, and research that use this idea.

OpenAI's API distinguishes system, developer, and user roles; its Model Spec ranks System (OpenAI's rules) above Developer above User and gives assistant and tool messages no authority.
Anthropic's Messages API uses a top-level system parameter for static rules and tool_result content blocks inside user messages for tool outputs.

What an interviewer would ask next. Try answering before peeking at the approach.

QHow would you defend against a prompt-injection attempt that tries to override the system message from user content?

Lean on the trust hierarchy: keep all security-critical instructions in system, never echo user content into the system block, and add explicit refusal patterns for instruction-override attempts.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases that signal junior thinking. Click to expand.

Most common mistake

Pasting tool results into the user message as plain text instead of a tool message or tool_result block. The model treats plain user text as a request, not as evidence, and the contract blurs.

60 second bullets to scan on the way to the call.

What are the five common role markers and the purpose of each?
What is the trust hierarchy across roles?

Primary sources. Browse if you want the original framing.