Role Prompting

By the Syncfusion DevTutorials team · Last updated October 20, 2026

Set who the model is and who it writes for: roles, system prompts, personas, audience prompting, checking reading level and rules in code, and the limits of roles.

Ask a doctor, a primary school teacher, and a comic writer "What is a fever?" You get three very different answers. The facts are the same, but the words, the amount of detail, and the tone change with the person.

You can get the same effect from a model by giving it a role. "You are a patient teacher for 10-year-olds" changes the words, the length, and the tone of every reply. This is called role prompting.

The main idea: a role tells the model how to answer: what voice to use, how much detail to give, and who the reader is. It does not give the model any new knowledge.

A Real-World Example

Think about a call centre. Before their shift, every agent gets a short script:

• "You work for Brightgrid support."
• "Be friendly and keep it short."
• "Never promise a refund. Send refund questions to the billing team."

The script doesn't change what the agent knows. It changes how they talk, and what they will and won't do. A system prompt is a script like this for a model.

What You Will Learn

In this lesson, you will learn:

1. What a role and a system prompt are.
2. How to write a role that says who, for whom, what tone, and what rules.
3. How naming the reader changes the level of a reply.
4. How to check a reply's reading level and rules with code.
5. What a role can do, and what it can't do.
6. Where roles go: in the system prompt or in the user message.

Roles and System Prompts

A role is a short description of who the model should act as. It usually goes in the system prompt. This is the first message the model reads, before any message from the user.

A role can describe:

• A job. "You are a senior JavaScript reviewer."
• A character. "You are Max, a cheerful guide for a cooking app."
• A reader. "Explain things to a 10-year-old."
• Rules. "Answer in under 80 words. Never give medical advice."

Try a role. Send the question. Then change the system prompt to "You are a doctor writing for other doctors." and send it again.

Write a Role in Four Parts

A strong system prompt answers four questions:

1. Who is the model? Its job or character.
2. Who is it writing for? The reader.
3. How should it sound? The tone and the length.
4. What are the rules? What it must always do, or never do.

The next box builds a system prompt from these four parts.

Build a system prompt from four parts

function makeRole(r) {
  const lines = ["You are " + r.who + ".", "You write for " + r.audience + ".", "Tone: " + r.tone + "."];
  r.rules.forEach((rule) => lines.push("- " + rule));
  return lines.join("\n");
}

const role = makeRole({
  who: "a support agent for Brightgrid, a data grid for web apps",
  audience: "developers who use Brightgrid",
  tone: "friendly and brief, under 80 words",
  rules: ["Answer only questions about Brightgrid.", "Send refund questions to billing@example.com."],
});

console.log(role);

Expected output:

You are a support agent for Brightgrid, a data grid for web apps.
You write for developers who use Brightgrid.
Tone: friendly and brief, under 80 words.
- Answer only questions about Brightgrid.
- Send refund questions to billing@example.com.

It is easier for the model to follow rules in a short list than rules hidden inside a long paragraph.

Audience Prompting

Sometimes you don't need a job title at all. You just need to say who the reader is. This is called audience prompting, and it is one of the most useful parts of a role.

One question, three audiences

const audiences = {
  child: "Explain to a 10-year-old. Use short sentences and one everyday example.",
  beginner: "Explain to a new developer. Define any technical word you use.",
  expert: "Explain to a senior engineer. Be precise and skip the basics.",
};

const question = "What is an API?";
for (const name in audiences) {
  console.log("[" + name + "] " + audiences[name] + " Question: " + question);
}

Expected output:

[child] Explain to a 10-year-old. Use short sentences and one everyday example. Question: What is an API?
[beginner] Explain to a new developer. Define any technical word you use. Question: What is an API?
[expert] Explain to a senior engineer. Be precise and skip the basics. Question: What is an API?

Compare two different readers with the real model:

Check the Reading Level

How can you test that a reply really suits a 10-year-old? One simple sign is the average sentence length. Shorter sentences are usually easier to read. The next box measures this for two sample replies written for this example.

Measure the average sentence length

function avgWords(text) {
  const sentences = text.split(/[.!?]+/).map((s) => s.trim()).filter(Boolean);
  const words = text.split(/\s+/).filter(Boolean).length;
  return Math.round((words / sentences.length) * 10) / 10;
}

const forChild = "An API is like a waiter. You ask for food. The waiter brings it from the kitchen.";
const forExpert = "An API is a contract that defines the requests a client may send to a service and the responses it can expect, usually over HTTP.";

console.log("For a child:", avgWords(forChild), "words per sentence");
console.log("For an expert:", avgWords(forExpert), "words per sentence");

Expected output:

For a child: 5.7 words per sentence
For an expert: 25 words per sentence

For a child, aim for short sentences of fewer than about 12 words. You can add a check like this to your tests.

Check the Rules

Rules in a system prompt are instructions, not promises. Small models break them more often. So turn each rule into a check, and test the replies.

Turn role rules into checks

const checks = [
  { rule: "under 80 words", test: (r) => r.split(/\s+/).length < 80 },
  { rule: "no refund promise", test: (r) => !/we will refund|you will get a refund/i.test(r) },
  { rule: "mentions billing for refunds", test: (r) => !/refund/i.test(r) || /billing/i.test(r) },
];

const reply = "Sorry about that! You will get a refund within 3 days.";
checks.forEach((c) => console.log(c.test(reply) ? "pass" : "FAIL", "-", c.rule));

Expected output:

pass - under 80 words
FAIL - no refund promise
FAIL - mentions billing for refunds

This sample reply breaks two rules. If the real model does this in your tests, make the rule stronger, put it at the end of the system prompt, or add an example of the right answer.

What a Role Cannot Do

A role changes the style, the amount of detail, and the focus. It does not:

• Add knowledge. "You are an expert tax lawyer" does not teach the model tax law. It only makes the model sound like a lawyer, and that can make wrong answers more convincing.
• Make the model safe. A user can still ask the model to ignore its role. Don't depend on a system prompt to protect secrets.
• Replace a clear task. "You are a world-class marketer" without a task still gets an unclear reply.

System Prompt or User Message?

You can put a role in either place:

The next box shows both ways, as the messages the model receives.

A role in the system prompt or in the user message

const inSystem = [
  { role: "system", content: "You are a strict code reviewer." },
  { role: "user", content: "Review: let x = 1" },
];
const inUser = [
  { role: "user", content: "As a strict code reviewer, review: let x = 1" },
];

console.log("System way:", inSystem.length, "messages, role applies to every turn");
console.log("User way:", inUser.length, "message, role applies to this turn");

Expected output:

System way: 2 messages, role applies to every turn
User way: 1 message, role applies to this turn

Common mistakes

Exercises

In each exercise, the last line should give back a value. Press Check to compare your value with the expected answer.

What to Remember

• A role tells the model who to act as. It usually goes in the system prompt.
• A good role says who, for whom, what tone, and what rules.
• Audience prompting sets the level of a reply by naming the reader.
• Check the reading level and the rules with code. Rules are not promises.
• A role changes the style, not the knowledge, and it does not keep things secure.
• Use the system prompt for the whole chat, and the user message for just one task.

Next: Delimited and Template Prompting, where you keep instructions separate from data and build prompts you can use again.