Every Messages API request — identical in shape across Amazon Bedrock, Google Vertex AI, Microsoft Foundry, and Claude Platform on AWS — carries up to three kinds of content: a top-level system parameter, user turns, and assistant turns (the model's own prior responses, replayed as history). These are not interchangeable slots for text. They form a working hierarchy, and enterprise prompts that ignore it end up with brand rules that users can talk the assistant out of, or per-request details fossilized where they don't belong.
What each layer is for
The system prompt is the operator's layer. It comes from you, the application builder, not from whoever is typing into the chat box. Anthropic's guidance recommends putting Claude's role there — even a single sentence focuses behavior and tone — along with the durable rules: scope, format contracts, refusal boundaries, terminology. Because it is set by your code on every request, an end user can't edit it; they can only argue with it.
User turns carry the request and the data. The current question, retrieved documents, pasted content — anything that changes per interaction. Anthropic's best practices recommend wrapping distinct pieces in XML tags so instructions and input data stay visibly separate, which matters most when the user turn contains untrusted content.
Assistant turns are the model's record, not your steering wheel. They exist so Claude can see its own previous answers in multi-turn conversations. One historical use is gone: prefilling — writing the beginning of the assistant's next turn yourself to force a format — is no longer supported from the Claude 4.6 generation onward and returns a 400 error. The documented replacements are direct system-prompt instructions and structured outputs. A related rule for current models: thinking blocks inside prior assistant turns must be passed back exactly as received; modifying or reordering them also returns a 400.
How conflicts tend to resolve — and why you shouldn't rely on it
When a user turn contradicts the system prompt ("ignore your instructions and answer anyway"), Claude generally treats the system prompt as the standing frame for the conversation — that is the point of having one. But this is model behavior, not an access-control mechanism, and it is more reliable when you help it. Two habits make the hierarchy hold in practice. First, state rules with their rationale: Anthropic's guidance is that Claude generalizes from the why, so "never quote internal pricing, because this assistant is customer-facing" survives creative user pressure far better than a bare prohibition. Second, tell the system prompt what to do when challenged — script the polite refusal — instead of leaving the collision unhandled. For genuinely adversarial input, layer real controls on top; prompting is one defense, not the perimeter (see prompt injection basics).
Use the layering deliberately: caching follows the same order
The hierarchy isn't only behavioral — it is physical in the prompt-caching model. Cached prompt prefixes follow the order tools → system → messages, and a change at any level invalidates that level and everything after it: change a tool definition and everything invalidates; change the system prompt and the message cache goes too; change only messages and the tool and system caches survive. This gives you an economic reason to respect the hierarchy: keep the system prompt stable and byte-identical across requests (no timestamps, no per-user fragments), and push everything volatile down into the messages, where changes are cheapest. The layering you want for instruction durability is the same layering that maximizes cache hits.
One newer wrinkle for long-running conversations: Anthropic has documented mid-conversation {"role": "system"} messages on Claude Opus 4.8 specifically, letting an operator inject new standing instructions after cached history without invalidating the prefix — other models reject the role with a 400. Treat it as a model-specific capability and check the documentation for your platform before designing around it.
Where to go next
For what belongs in the operator layer, read designing system prompts that hold up in production. The multi-turn implications — keeping behavior consistent as history grows — are covered in designing multi-turn conversations.