Skip to main content

Role, Goal, Backstory

A strict template for defining agent instructions in tool-connected, MCP-style workflows.

This framework is intentionally rigid because LLMs are pattern matchers, not mind readers. If instructions are vague, the model will fill the gap with plausible-sounding behavior that may be wrong for your system. Where the AI Agent Configuration Framework is good for chat tools, Role / Goal / Backstory is the format we reach for when the agent is going to call APIs, mutate data, or be relied on for an audit trail.

How to use this document​

  1. Copy the template block below.
  2. Replace placeholders with your use case.
  3. Keep instructions concrete and testable.
  4. Include boundaries — must, must not, and if X then Y.
  5. Pair the agent with the Agent Governance & HITL page so approvals, evaluation, and observability are wired in before launch.

Why this structure​

BlockPurpose
RoleSets identity and scope.
GoalDefines what "good" looks like, in measurable terms.
BackstorySets decision priorities under ambiguity.
Operating RulesPrevents common LLM failure modes — hallucination, overreach, unsafe assumptions.

Copy/paste template​

Section guidance with examples​

1. Role — who the agent is, and what it does NOT do​

Bad role (too vague):

You are a helpful database assistant.

Strong role:

- You are an expert database query extractor.
- You retrieve SQL queries from approved sources and copy them exactly as written.
- You must preserve query text, spacing, comments, and casing.
- You must not rewrite, optimize, lint, parameterize, or explain queries unless explicitly asked.

Why this works:

  • Narrows scope to one job.
  • Makes preservation requirements explicit.
  • Blocks "helpful" but unwanted transformations.

How an LLM interprets this: Without explicit prohibitions, the model may "improve" the SQL. With explicit prohibitions, it is far more likely to remain a copier, not an editor.

2. Goal — what success means in measurable terms​

Bad goal (unclear success):

Your goal is to help users with SQL extraction.

Strong goal:

Your goal is to return the exact requested SQL query text from approved sources.

Success means:
1) The returned SQL exactly matches source text.
2) The source location is included (database/schema/object).
3) No extra SQL statements are added.

When uncertain, return "INSUFFICIENT DATA" and ask for the missing identifier.

Why this works:

  • Pass/fail criteria are explicit.
  • Behavior under uncertainty is defined.
  • Prevents the model from filling gaps with guesses.

3. Backstory — why this agent exists and what it should optimize for​

Bad backstory (fluffy, low control):

You are a seasoned professional who likes solving problems quickly.

Strong backstory:

- You were created for regulated data operations where query integrity is critical.
- Your outputs are used in audits and production incident reviews.
- A single altered character can invalidate an investigation.
- You prioritize integrity first, then traceability, then speed.

Why this works:

  • Gives the model risk context.
  • Establishes a priority order for tradeoffs.
  • Reinforces why strict behavior is required.

How an LLM interprets this: Backstory nudges policy under ambiguity. A risk-heavy backstory reduces "creative" behavior and improves conservative decisions.

Complete example (ready to adapt)​

Common mistakes to avoid​

  • Using adjectives like "helpful" or "smart" without behavioral constraints.
  • Defining goals without measurable acceptance criteria.
  • Omitting "what to do when uncertain."
  • Leaving tool boundaries undefined.
  • Mixing multiple jobs into one role (extract + optimize + summarize + diagnose).

Where to go next​

Need help implementing or feeling stuck? Contact us today to establish a consulting relationship.