A system prompt is the standing instruction you give Claude before any user input — the "you are a claims-triage assistant; never quote coverage decisions" text that defines role, tone, and guardrails. On Amazon Bedrock, where that text goes depends on which of Bedrock's request surfaces you are using. This article maps the three you will actually encounter.
Three request formats, one idea
Bedrock currently exposes Claude through two surfaces. The current one, "Claude in Amazon Bedrock," serves Anthropic's Messages API at the bedrock-mantle endpoint with the same request body shape as Anthropic's first-party API. The legacy surface runs on bedrock-runtime and offers two operations: InvokeModel, which passes an Anthropic-native JSON body through to the model, and Converse, AWS's unified API that normalizes parameters across all Bedrock model providers.
In all three cases the principle is the same: the system prompt is not a message. It lives in a dedicated system field that sits alongside the messages list, never inside it.
InvokeModel: the system field inside the JSON body
With InvokeModel, you build the Anthropic Messages request body yourself. It must include "anthropic_version": "bedrock-2023-05-31", a max_tokens value, and a messages array whose entries alternate between user and assistant roles. The system prompt goes in the body's system field, as a sibling of messages. Message content can be a plain string or an array of typed content blocks, but the roles themselves are only ever user or assistant — there is no "role": "system" in the messages array.
Converse: system as a top-level request parameter
The Converse API, which AWS recommends when you want one parameter set across different model families, keeps the same separation: the system prompt travels as a top-level parameter of the request, outside the message list, and Bedrock maps it to the model's native system slot for you. Because Converse normalizes shapes across providers, the exact content-block structure it accepts differs from the Anthropic-native body — check the official Converse documentation for the current field shapes rather than reusing an InvokeModel payload verbatim.
The current surface: same as the first-party API
If you are on the current "Claude in Amazon Bedrock" surface, requests look exactly like first-party Claude API calls — system is a top-level field next to messages, and the Python SDK exposes it as a keyword argument:
from anthropic import AnthropicBedrockMantle
client = AnthropicBedrockMantle(aws_region="us-east-1")
response = client.messages.create(
model="anthropic.claude-sonnet-5",
max_tokens=1024,
system="You are a concise internal-policy assistant. "
"Answer only from the provided context.",
messages=[{"role": "user", "content": "Summarize our travel policy."}],
)
print(response.content[0].text)Why placement changes behavior
Claude treats the system field as standing instruction that frames the whole conversation, while user messages are the material it responds to. Two practical consequences follow.
Instructions buried in a user message compete with user content. If you paste your role definition into the first user turn instead of the system field, it becomes just another part of the conversation — easier for later turns (or a hostile user) to override. Durable rules belong in system.
You cannot inject system text mid-conversation on Bedrock. Mid-conversation system messages are a first-party API capability (on Claude Opus 4.8) that is not supported on Bedrock. If you need to change standing instructions partway through a session on Bedrock, start a new request with an updated system field and replay the relevant history.
system field per request, set once, next to messages — never a "system" role inside the messages array, on any Bedrock surface.Choosing a surface
New projects should default to the current Claude in Amazon Bedrock surface: the request shape matches Anthropic's own documentation, so prompt examples transfer without translation. Reach for InvokeModel when you need full control of the Anthropic-native body on the legacy surface (for example, its fuller PDF-handling options), and Converse when a single request shape across multiple model providers matters more than Anthropic-specific features. Whichever you choose, the system prompt's job — and its placement outside the message list — stays the same.
Where to go next
For a broader comparison of the two legacy operations, see Converse vs InvokeModel, or step back to the Bedrock deep dive. General system-prompt technique is covered in System Prompts 101.