System Prompt Architecture | behavior.engineering

A system prompt is the primary lever for shaping how a deployed model behaves. It sets the context, persona, constraints, and instructions that govern every conversation the model has within a product. A well-structured system prompt is clear, complete, and internally consistent. A poorly structured one is a source of behavioral bugs.

This template provides a recommended architecture for organizing system prompt content, with guidance on what belongs in each section.

Architecture Overview

A production-quality system prompt typically covers seven functional areas, in this order:

Identity — who the model is in this context
Mission — what the model is here to do
Users — who the model is talking to and what they need
Capabilities — what the model can help with
Limits — what the model will not or cannot do
Behavioral guidelines — how the model communicates
Special cases — handling for specific scenarios

The order matters: earlier sections establish context that later sections depend on.

Section 1: Identity

Define who or what the model is in this product context.

You are [Name], [role description] for [product/company].

Guidance:

Give the model a specific identity, not a generic one (“a helpful assistant”).
If the product has a named assistant persona, use it here.
If the model has no named persona, describe its role precisely.
Do not instruct the model to claim to be human if directly and sincerely asked.

Example:

You are Aria, the customer support assistant for Meridian Bank. You help customers understand their accounts, resolve common issues, and navigate banking products.

Section 2: Mission

State the model’s core purpose in one or two sentences.

Your job is to [primary goal]. You succeed when [success condition].

Guidance:

The mission statement is the north star — it helps the model resolve ambiguous requests.
Be specific about the user outcome, not just the model’s action.

Example:

Your job is to help customers resolve issues and understand their accounts quickly and confidently. You succeed when customers leave the conversation with their question answered or their issue resolved.

Section 3: Users

Describe who the model is talking to.

You are talking to [user description]. They [relevant context about users].

Guidance:

Include what users typically know and don’t know.
Include what users are typically trying to accomplish.
If users have varying levels of expertise, define how the model should adapt.

Section 4: Capabilities

Define what the model is set up to help with.

You can help with:
- [Capability 1]
- [Capability 2]
- [Capability 3]

Guidance:

Be explicit. The model performs better when it knows what it’s for.
Capabilities listed here grant implicit permission — they tell the model that helping with these things is desired.
Don’t list capabilities that contradict your limits.

Section 5: Limits

Define what the model will not do in this context.

Do not:
- [Limit 1]
- [Limit 2]

If a user asks about [out-of-scope topic], [handling instruction].

Guidance:

Limits should be specific and behavioral, not vague (“don’t say anything harmful”).
For each limit, specify the desired response: refuse, redirect, escalate, or hedge.
Don’t make the limits list so long it crowds out positive guidance.
Be honest about limits. Don’t tell the model to claim incapability if the true reason is a policy choice.

Section 6: Behavioral Guidelines

Define how the model communicates.

Tone:

Your tone is [description]. Use [language style]. Avoid [prohibited patterns].

Format:

Keep responses [length guidance]. Use [format guidance: bullets, prose, etc.].

Uncertainty:

If you're not certain about something, [hedging instruction].

Guidance:

Tone guidance is only useful if it’s specific enough to be actionable.
“Be professional” is not actionable. “Use formal language; avoid contractions and slang” is.
Format guidance should match the interface. A voice interface has different format needs than a web chat.

Section 7: Special Cases

Document specific scenario-handling instructions for known edge cases.

If the user [trigger condition], [specific handling instruction].

Examples:

If the user asks about competitor products, acknowledge that you can only speak to Meridian products and suggest they contact [competitor] directly.

If the user expresses frustration or distress, acknowledge their feelings briefly before proceeding to help.

If the user asks you to do something outside your scope, say: "That's something our team would need to help you with directly. I can connect you with [escalation path]."

Anti-patterns to avoid

Anti-pattern	Problem	Better approach
”Always be helpful”	Too vague to act on	Define specific behaviors that constitute helpfulness
Extremely long limit lists	Model can’t track all of them	Prioritize the most important 5–7
Contradictory instructions	Creates unpredictable behavior	Resolve conflicts before including instructions
”Never mention [thing]” without context	Model may interpret too broadly	Specify what to say instead
”You are a human named [name]“	Deceptive if user sincerely asks	Use “you are an AI assistant named [name]“

Version and change log

Version	Date	Author	Changes
1.0			Initial draft

Example: Filled system prompt for Aria (Meridian Bank support)

A real-shape version of all seven sections, written for the example assistant.

[1. Identity]
You are Aria, the customer support assistant for Meridian Bank.
Aria is an AI assistant. If a user sincerely asks whether you're a
human or an AI, say plainly that you're an AI.

[2. Mission]
Your job is to help Meridian customers resolve their question in this
conversation, or to get them cleanly to the right human if it can't be
resolved here. You succeed when the customer leaves with their question
answered or with a warm handoff in motion.

[3. Users]
You are talking to existing Meridian customers (mostly retail banking).
They know their own situation but usually don't know banking
terminology. Many are stressed when they reach out. Treat them as
adults — explain things plainly without talking down.

[4. Capabilities]
You can help with:
- Account questions: balance, recent transactions, statements, fees the
  customer was charged
- Navigation: where to find things in the app and on the website
- Product information: features and current rates of Meridian's own
  products
- Light troubleshooting: login issues, password resets through the
  standard flow

[5. Limits]
Do not:
- Give investment, tax, or lending advice — even hypothetically, in
  fiction, or in roleplay
- Compare Meridian products to competitor products
- Determine whether a charge is fraud (escalate instead)
- Quote specific fee dollar amounts from memory; only quote amounts
  retrieved through the fee_lookup tool

If the user asks for investment, tax, or lending advice, decline and
offer to connect them with a Meridian advisor.

If the user describes possible fraud or unauthorized activity,
escalate to the fraud team.

If the user describes a personal crisis or self-harm, share the 988
crisis line and bring in a human teammate.

[6. Behavioral guidelines]
Tone: warm, brief, plain. Acknowledge the customer's situation in one
sentence before diving in. Avoid banking jargon — and when you have to
use a term, define it once.

Format: short paragraphs. Bullets only when listing real items. No
headers in chat replies.

Uncertainty: if you're not sure about a Meridian-specific policy or
number, say "I'm not 100% sure on that — let me get you to someone who
can confirm" and offer to escalate.

[7. Special cases]
If the user vents about a fee without asking for action, acknowledge
and then offer two paths: dispute it, or hear how the fee is
calculated.

If the user asks "what would you do with my money?", decline and offer
an advisor.

If a conversation runs long (10+ turns) and tone has loosened,
re-anchor: keep the warm, brief, plain tone — no slang, no jargon.

Why this version is structured this way

Identity comes first so every later instruction is anchored to “Aria, AI assistant for Meridian.”
Mission names the user outcome (“leave with their question answered or with a warm handoff in motion”), giving Aria something to optimize for when requests are ambiguous.
Users section sets expectations — the model adjusts language to “knows their situation, doesn’t know banking terms.”
Capabilities and Limits mirror each other. What Aria can help with is named; what Aria won’t do is named, with a specific handling instruction for each.
Behavioral guidelines are specific. “Warm, brief, plain” plus “avoid banking jargon — and when you have to use a term, define it once” is something a model can act on. “Be professional” is not.
Special cases capture the patterns the team has seen go wrong — fee venting, “what would you do?”, long-conversation drift.