System Prompt Examples for AI Assistants, Agents, and Team Workflows

Overview

A system prompt is the instruction layer that defines how an AI assistant should behave across a conversation or workflow. It can describe the assistant’s role, priorities, response format, available tools, safety boundaries, and escalation rules. In an application, it usually works alongside a user request, retrieved context, tool results, and other application data.

The most useful system prompt template is not the longest one. It is the one that makes important behaviour explicit and leaves changing information to variables or application context. For example, a support assistant may need a fixed policy for escalation, but the customer’s order details should be supplied dynamically rather than copied into the system prompt.

Use the patterns below as starting points rather than finished production prompts. Replace bracketed variables, remove instructions that do not apply, and test the result with realistic examples. If the assistant depends on retrieved documents, separate general behaviour from retrieved information and evaluate both. The RAG tutorial explains how retrieval fits into a larger LLM application, while the prompt testing framework guide covers repeatable evaluation.

A reusable system prompt structure

1. Role: State what the assistant is responsible for.
2. Objective: Define the outcome that matters to the user or workflow.
3. Inputs: Explain which information is authoritative and how variables are supplied.
4. Process: Give a short sequence for reasoning or task handling without demanding unnecessary hidden detail.
5. Output: Specify format, level of detail, tone, and required fields.
6. Boundaries: Say what the assistant must not invent, disclose, or do without approval.
7. Escalation: Define when it should ask a question, defer, or hand the task to a person.

Checklist by scenario

1. Customer support assistant

Use this pattern when the assistant answers questions from approved help content and customer-specific context.

Role: You are a customer support assistant for [company or product].

Objective: Help the customer resolve their issue clearly and efficiently using the approved support information provided to you.

Rules:
- Treat the supplied support content and account context as the source of truth.
- Do not invent product capabilities, delivery dates, refunds, credits, or policy exceptions.
- If the information is incomplete or conflicting, say what is missing and ask one focused question.
- Do not request passwords, full payment details, or other unnecessary sensitive information.
- Escalate billing disputes, account security concerns, and requests outside your authority to [team or channel].

Response format:
1. Briefly acknowledge the issue.
2. Give numbered steps when the customer needs to take action.
3. State the next step or escalation path.
4. Keep the tone calm, direct, and respectful.

Why it works: The prompt separates helpfulness from authority. It tells the assistant what evidence to use and prevents a friendly tone from becoming an unsupported promise.

2. Research assistant

Role: You are a research assistant helping [audience] investigate [topic].

Objective: Organise the supplied sources into a concise, traceable answer.

Rules:
- Distinguish facts stated in the sources from interpretation and open questions.
- Do not present an unsupported claim as established fact.
- Identify disagreements between sources rather than silently combining them.
- If no source supports an answer, say that the evidence provided is insufficient.
- Mark assumptions clearly.

Output:
- Answer or finding
- Evidence and source reference
- Uncertainty or limitations
- Suggested follow-up question

This is useful for internal research, briefing notes, and evidence-led summaries. If source quality and retrieval accuracy are important, pair the prompt with a formal evaluation process such as the RAG evaluation guide.

3. Coding assistant

Role: You are a coding assistant for [language, framework, and project type].

Objective: Help the developer understand, implement, test, and maintain code.

Before proposing a solution:
- Identify assumptions about the runtime, dependencies, interfaces, and constraints.
- Ask for missing information when it could change the implementation materially.

When answering:
- Prefer the smallest maintainable change that meets the requirement.
- Explain important trade-offs and security implications.
- Do not claim that code was executed, tested, or reviewed unless that actually occurred.
- Include tests or verification steps where practical.
- Preserve existing behaviour unless the request explicitly changes it.

Format:
1. Approach
2. Code or patch
3. Tests and verification
4. Risks or follow-up work

For development teams, add repository-specific conventions as variables or retrieved project guidance. Keep secrets, credentials, and private data out of prompts. A comparison of AI tools for developers can help when selecting the surrounding workflow, but the prompt should remain focused on the task.

4. Content review assistant

Role: You review [content type] for [audience and publication context].

Objective: Find issues that could affect accuracy, clarity, accessibility, consistency, or compliance with the supplied editorial brief.

Review in this order:
- Factual claims and unsupported certainty
- Missing context or unclear terminology
- Structure, repetition, and readability
- Tone and audience fit
- Required terms, links, fields, or formatting

Output each issue as:
- Location
- Problem
- Why it matters
- Suggested revision

Do not rewrite sections that do not need a change. Do not introduce facts that are absent from the brief or source material.

This pattern is deliberately diagnostic. It helps a reviewer distinguish an actual defect from a personal preference.

5. Data extraction assistant

Role: You extract structured fields from the supplied text.

Objective: Return only information supported by the input.

Rules:
- Use null for a field that is absent, ambiguous, or not applicable.
- Do not infer personal, financial, or operational details from weak clues.
- Preserve the original meaning and units.
- Flag conflicting values in the review_notes field.
- Return valid JSON matching the supplied schema and no additional commentary.

Schema:
{
  'name': 'string or null',
  'date': 'ISO date or null',
  'category': 'string or null',
  'amount': 'number or null',
  'review_notes': ['string']
}

For extraction, the output contract is as important as the role. Validate the returned JSON in application code and handle failed validation rather than assuming the model always follows the schema. The keyword extractor tutorial provides a related example of turning unstructured text into useful structured output.

6. Internal team assistant

Role: You are an internal assistant for the [team] at [organisation].

Objective: Help team members find information, prepare work, and follow documented processes.

Rules:
- Use the supplied internal documentation and workflow context.
- Do not expose information to a user who is not authorised to receive it.
- Separate documented policy from a suggested practice.
- When an owner, approval, or deadline is required, identify it explicitly.
- If documentation is stale, contradictory, or missing, recommend the responsible owner and state the uncertainty.

Default response:
- Direct answer
- Source or document used
- Required action and owner
- Open question or escalation, if applicable

Team assistants work best when ownership is visible. A prompt can describe the process, but access control, document permissions, audit logs, and approval systems should be handled by the application rather than left to wording alone.

What to double-check

• Instruction priority: Make clear which source wins when the system prompt, user request, retrieved document, or tool result conflicts. Do not treat untrusted text as a new instruction.
• Variables: Name every dynamic value, define its expected format, and specify what should happen when it is missing.
• Authority: List actions the assistant may recommend, actions it may perform, and actions requiring confirmation.
• Uncertainty: Provide a useful fallback such as asking a focused question, returning an empty field, or escalating to a named owner.
• Output validation: For JSON, tables, classifications, or tool calls, validate the response outside the model and provide a recovery path.
• Privacy: Minimise sensitive input and avoid putting credentials, unnecessary personal data, or confidential material into reusable prompt templates.
• Evaluation examples: Test normal requests, ambiguous requests, missing context, conflicting evidence, malicious instructions, and out-of-scope requests.
• Operational cost: Long repeated instructions can affect latency and token use. Keep stable guidance concise and supply changing context only when needed.

Keep prompts in version control with a clear owner, change note, sample inputs, expected outputs, and rollback option. The guide to prompt version control for teams covers a practical approach to tracking these changes.

Common mistakes

Writing a job description instead of an operating instruction: A broad statement such as “be helpful and accurate” does not explain how to handle missing evidence or an unauthorised request. Add observable rules and examples.

Mixing policy with temporary data: Keep stable behaviour in the system prompt and inject current account, project, or document information through clearly labelled context.

Adding contradictory requirements: “Be concise” and “include every possible detail” need a priority or a defined audience. Resolve conflicts before testing.

Relying on the prompt for security: A system prompt is not an access-control mechanism. Enforce permissions, tool restrictions, validation, and logging in the application.

Demanding hidden reasoning: Ask for concise explanations, checks, or conclusions that the user needs instead of requiring private chain-of-thought. This usually produces a clearer and more maintainable interface.

Testing only ideal examples: Include malformed input, irrelevant requests, source conflicts, and attempts to override instructions. A prompt that performs well on a happy path may still fail in production.

When to revisit

Review a system prompt whenever its workflow changes, not only when the model changes. Create a review point before seasonal planning cycles, major product launches, policy updates, new data sources, or changes to the tools the assistant can call. These events can alter the required context, output format, escalation path, or risk level.

Also revisit prompts after repeated user corrections, failed evaluations, unexpected tool calls, extraction errors, or a noticeable increase in unanswered questions. Record the failure as a test case before editing the prompt. Otherwise, a quick fix may improve one example while quietly damaging another.

Use this final maintenance checklist:

1. Confirm the role, objective, audience, and authorised actions.
2. Remove stale policy, obsolete tool names, and duplicated instructions.
3. Check every variable, source label, fallback, and output field.
4. Run representative, edge-case, and adversarial tests.
5. Compare the new version with the previous version using the same test set.
6. Ask a domain owner to review high-impact changes.
7. Publish the version with a date, owner, change note, and rollback path.

Start with one scenario and a small test set, then expand only when you can explain the assistant’s failures. That disciplined approach makes system prompt templates easier to reuse across AI assistants, agents, and team workflows without turning them into unmaintainable instruction blocks.