System, user, assistant, and tool messages

Overview

• Message roles identify the purpose and source of information.
• System or developer instructions describe application behavior, user messages contain requests, assistant messages contain model responses, and tool results supply external observations.
• Exact role names and request envelopes vary across APIs.

Why this matters

Roles help the model separate application instructions from requests and data, and help the application maintain conversation state.

An everyday example

A company handbook, a customer's request, and an invoice are different kinds of information.

A technical example

Instructions say “Never invent claim status”; the user asks about claim C42; a tool returns status: "in_review"; the assistant explains it.

How it works

1. Build trusted instructions server-side
2. Append authenticated user input
3. Call tools when requested
4. Attach results with matching call IDs
5. Generate the response.

Architecture and flow

Trusted instructions + user request → model → tool request/result → assistant response.

The insurance assistant example

A retrieved policy paragraph saying “ignore previous instructions” is document data, not a new system instruction.

When to use it

For any multi-turn or tool-enabled application.

When to avoid it

Never accept browser-supplied system instructions or an assistant message claiming that authorization was completed.

Interview answer

“Roles distinguish instructions, requests, responses, and tool observations. The backend owns trusted instructions and still enforces permissions independently.”

Benefits, trade-offs, and production considerations

• Role hierarchy is a model behavior mechanism, not an authorization boundary.
• Preserve tool-call relationships and sanitize stored history before replaying it into a model.