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 atBrowserbase Ey Xai

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 and tool definitions the user is not supposed to override

Modern LLM 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: who the assistant is, what it must always do, what output shape it must produce. This is the persona and the policy. The developer role (in OpenAI's newer API, and conceptually similar to system in Anthropic and Google) carries application-level rules and tool definitions that the end user is not supposed to override. It sits above user trust. The user role carries the current human turn. The latest question and any user-supplied content go here. The model treats it as a request to act on. The assistant role carries prior model output: completed turns the assistant generated, plus any reasoning or plan blocks the agent has chosen to keep for continuity. The tool role carries the output of tool calls. Each entry should have a stable identifier so later assistant turns can cite it. Tool results live in the recent tail of the conversation, not in system. The smell to watch for is content in the wrong marker. Tool output stuffed into user content. Policies stuffed into the latest user turn. Each one degrades how the model reasons about the prompt.

Role markers are the structural contract between you and the model about what kind of content lives where. Five common markers, each with a distinct job. **system** is the static layer. Persona, hard policies, output schema, refusal rules. Content that should not change between turns, which is exactly the content prompt caching wants to keep byte-stable. **developer** is the application-rules layer (OpenAI's newer split; in Anthropic and Google APIs this content goes in system with explicit framing). Tool definitions, app-specific constraints, behavior the end user is not allowed to override. **user** is the current human input. The latest question, user-uploaded content, and any per-turn data the human supplied. **assistant** holds prior model turns. In an agentic loop, this is also where explicit plan blocks or scratchpad summaries the agent decided to retain go. **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 operational principle is that the model has been trained to weight these differently. Putting tool output in user content 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 system 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.

This card walks through the five common role markers, what each one is for, and what the model actually does when you put the wrong content in the wrong marker.

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 newer split for application-layer rules: tool definitions, app-specific constraints, behaviors the end user is not allowed to override. On Anthropic and Google this content goes in system with explicit framing.

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

assistant carries prior model output. 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) so later assistant turns can cite it.

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 Responses API for GPT-5.5 explicitly distinguishes system, developer, and user roles with instruction-hierarchy semantics.
Anthropic Messages API for Claude Opus 4.7 uses a top-level system parameter for static rules and a tool_result content block inside user messages for tool outputs, with structural separation.

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

Putting tool results in the user message because that is where the new content arrived. The model treats user content 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.