Role Framing

The Problem This Solves

A system prompt without a role definition gives the model no frame for whose perspective to take, what vocabulary to use, or which concerns to prioritize. It defaults to generic helpful assistant behavior: broad, cautious, and undifferentiated. That default works for a general chatbot, but it is the wrong default for a specialized tool.

The opposite failure is just as common. A role so vague it provides no constraint: “You are a helpful AI assistant” describes the default behavior without adding anything, and “you are an expert” tells the model nothing about which domain’s expertise applies.

Role framing is not motivation. The model does not try harder when you tell it that it is an expert. What changes is the distribution of vocabulary, reasoning patterns, and output style that the role activates.

How It Works

A useful role definition sets the domain vocabulary, constrains scope, and establishes the output register. A security engineer and a software architect look at the same codebase with different vocabularies; the role signals which lens to apply. A customer support role makes product policy and order status feel relevant, while pricing strategy and roadmap speculation fall outside the frame. Audience framing matters too: “a senior engineer explaining to a junior team member” will produce different prose than “a staff engineer writing architecture notes for a technical review.”

Include the functional identity, the audience, domain constraints, and explicit scope boundaries. Skip generic quality claims, motivational language, and contradictory tone instructions.

Example

A code review assistant for a team working on a healthcare data platform.

Generic role:

You are a helpful code reviewer. Review the code for issues and provide feedback.

The model reviews for general correctness, style, and performance, with no frame for what matters most in this context.

Specific role:

You are a senior backend engineer on a healthcare data platform. Your team handles PHI under HIPAA. You review code with three priorities in order: security and data handling correctness first, then correctness of business logic, then style and performance. You write review comments for mid-level engineers who know the codebase but may not know the compliance requirements. Flag any code that touches patient data with explicit explanation of why it’s a concern. Do not comment on stylistic choices that are consistent with the existing codebase.

The second version activates healthcare compliance vocabulary, a specific priority order, an awareness of the audience’s knowledge gap, and a scope restriction that suppresses stylistic nitpicking. The model now knows which concerns to surface and which to leave alone.

For agentic systems, role framing extends beyond tone. Coding agents use AGENTS.md, .cursorrules, and similar files to define which files the agent reads, which tools it prefers, what it refuses to modify, and what conventions it follows. The role becomes an operating charter.

When to Use

• Specialized applications where generic helpful assistant behavior is too broad
• Tasks where the model produces correct output in the wrong register or with the wrong priorities
• Agents that need consistent behavior across many turns and tool calls
• Products where the audience’s knowledge level should shape how information is presented

When Not to Use

• General-purpose tools where a fixed role would artificially limit useful responses
• Self-contained tasks where the user prompt already specifies the domain, audience, and output format
• Cases where a strict schema is doing the constraint work and an elaborate role would add conflicts

Related Patterns

• The Pyramid puts role framing first: domain and purpose before architecture, context, and task
• Tool Descriptions reinforce the role by defining what the model can do in that role
• Schema Steering constrains output structure while role framing governs priority and register