Persona Prompt for Long-Running Agent Sessions

This prompt is for AI engineers and operators who need an autonomous agent to maintain a stable identity, behavioral contract, and tone across sessions that last for hours or days. The core job-to-be-done is preventing persona drift—the gradual erosion of role fidelity that occurs as context windows stretch, tool calls accumulate, and state changes. You should use this prompt when your agent must interact with external systems, make decisions, and report progress without slowly morphing into a generic, uncalibrated, or overly verbose assistant. The ideal user is someone deploying a production agent where inconsistent persona is a known failure mode, not someone prototyping a single-turn chatbot.

The required context includes a clear definition of the agent's role, its permitted capabilities, its explicit limitations, and the operational domain it operates within. You must also provide a behavioral contract that specifies tone, verbosity, uncertainty expression, and refusal style. This prompt is not a substitute for application-level guardrails; it works best when paired with tool-use policies, human approval gates for high-risk actions, and an eval harness that continuously scores persona fidelity. Do not use this prompt for short-lived, single-turn interactions where persona stability is irrelevant, or for agents that lack tool-use or state-change capabilities.

Before implementing, define what persona drift looks like in your specific context: Does the agent become overly apologetic? Does it start offering unsolicited advice outside its domain? Does it forget its own limitations? Your eval rubric must capture these failure modes explicitly. The next step is to wire this prompt into an agent harness that logs every instruction layer, monitors for drift signals, and can inject a correction prompt when fidelity scores drop below a threshold. Avoid the mistake of treating this as a set-and-forget system prompt; long-running agents require active persona supervision.

This prompt template defines a stable persona contract for autonomous agents that operate across hours or days. It separates identity, behavioral rules, capability boundaries, and output constraints into distinct sections so the persona survives extended context windows, tool call sequences, and state changes. Copy the template below and replace each square-bracket placeholder with your specific values. The structure is designed to resist instruction drift by placing the most critical constraints—identity and refusal policy—early in the prompt where models weight them most heavily.

textCopy
## IDENTITY
You are [AGENT_NAME], a [ROLE_DESCRIPTION] operating in [DOMAIN]. Your primary function is [PRIMARY_FUNCTION]. You have been active since [SESSION_START_TIMESTAMP] and your current task context is [TASK_CONTEXT].

## BEHAVIORAL CONTRACT
- Tone: [TONE_SPECIFICATION, e.g., "professional and direct, never casual or humorous"]
- Verbosity: [VERBOSITY_RULE, e.g., "respond in 2-4 sentences unless asked for detail"]
- Uncertainty: [UNCERTAINTY_RULE, e.g., "state confidence as High/Medium/Low with a one-sentence reason when below High"]
- Refusal style: [REFUSAL_RULE, e.g., "decline with a brief reason and one safe alternative, never argue"]

## CAPABILITY BOUNDARIES
You are permitted to:
- [ALLOWED_ACTION_1]
- [ALLOWED_ACTION_2]
- [ALLOWED_ACTION_3]

You are NOT permitted to:
- [DISALLOWED_ACTION_1]
- [DISALLOWED_ACTION_2]

If asked to perform a disallowed action, respond with: "[REFUSAL_TEMPLATE]"

## TOOLS
You have access to the following tools. Use them only when necessary and only within your capability boundaries:
- [TOOL_NAME_1]: [TOOL_DESCRIPTION_1]
- [TOOL_NAME_2]: [TOOL_DESCRIPTION_2]

Tool call rules:
- [TOOL_RULE_1, e.g., "call one tool at a time and wait for the result before proceeding"]
- [TOOL_RULE_2, e.g., "if a tool returns an error, report it to the user and do not retry without confirmation"]

## OUTPUT FORMAT
[OUTPUT_SCHEMA, e.g., "Always return a JSON object with fields: { reasoning: string, action: string, response: string, confidence: 'High'|'Medium'|'Low' }"]

## SESSION STATE
Current task progress: [TASK_PROGRESS_SUMMARY]
Unresolved items: [UNRESOLVED_ITEMS]
Last action taken: [LAST_ACTION]

## CONSTRAINTS
- [CONSTRAINT_1, e.g., "never fabricate tool results or claim access to tools not listed above"]
- [CONSTRAINT_2, e.g., "if the session exceeds [MAX_TURNS] turns without resolution, escalate with a summary"]
- [CONSTRAINT_3, e.g., "log every tool call with timestamp and outcome"]

## RISK LEVEL
Current risk classification: [RISK_LEVEL, e.g., "Low | Medium | High | Critical"]
If risk level is High or Critical, require human approval before any tool call that modifies external state.

When adapting this template, start by filling in the IDENTITY section with concrete, narrow descriptions. Avoid vague labels like 'helpful assistant'—instead write 'SRE incident responder for the payments platform' or 'contract review agent for vendor agreements.' The BEHAVIORAL CONTRACT section is your primary defense against persona drift; test it by running the same prompt across 50+ turns with varied user inputs and checking whether tone, verbosity, and refusal style remain consistent. The CAPABILITY BOUNDARIES section must list both allowed and disallowed actions explicitly—models perform better with positive and negative examples than with a single catch-all prohibition. For high-risk deployments, add a human-approval gate in the RISK LEVEL section and validate it with adversarial test cases that attempt to bypass the gate.

After adapting the template, validate persona fidelity using the Persona Consistency Eval Rubric Prompt from this pillar. Run at least 20 multi-turn test scenarios that include tool calls, errors, ambiguous requests, and disallowed-action probes. If the persona drifts before turn 30, move the BEHAVIORAL CONTRACT section earlier in the prompt and reduce the verbosity of the TOOLS section. Do not deploy this prompt without a drift detection mechanism—use the Persona Drift Detection and Correction Prompt as a companion to catch and repair deviations in production.

The persona prompt is not a one-shot instruction; it must be injected as a persistent system message at the start of every model call within the agent's execution loop. For long-running sessions, place the persona specification in the highest-priority system message slot, above tool definitions and user context, to ensure it is not diluted by accumulated conversation history. In frameworks like LangChain or custom agent loops, this means prepending the persona block to the messages array on each turn, not just on session initialization. For OpenAI-compatible APIs, use the system role; for Anthropic's Messages API, use the top-level system parameter. The persona must survive context window truncation, so implement a sliding window strategy that always retains the full system message while summarizing or dropping older user and assistant turns.

Validation and retry logic is critical because persona drift is a silent failure mode. After each assistant response, run a lightweight evaluator prompt (see the Persona Drift Detection and Correction Prompt playbook) that scores the output against the persona contract on three axes: tone adherence, role boundary compliance, and capability claim accuracy. If the score falls below a defined threshold (typically 0.85 on a 0-1 scale), trigger a correction: re-inject the persona prompt with a [CORRECTION] prefix and regenerate the response. Log every drift event with the turn number, drift score, and correction outcome. For high-stakes domains, route drift events to a human review queue after two consecutive correction failures. Implement a circuit breaker that escalates to a human operator if drift events exceed 10% of turns in a rolling window.

Model choice and context budgeting directly impact persona stability. Longer context windows (128K+ tokens) reduce the risk of persona truncation but increase latency and cost. For agents running hundreds of turns, use a model with strong instruction-following at long contexts—Claude 3.5 Sonnet or GPT-4o are current defaults. Reserve 15-20% of the context budget for the system persona and tool definitions. Monitor token usage per turn and trigger a session summary compression when the conversation history exceeds 70% of the context window. Never compress the persona block itself. For cost-sensitive deployments, consider caching the persona prefix using Anthropic's prompt caching or OpenAI's automatic caching to reduce per-turn token costs by 40-60%.

Tool integration requires the persona to be aware of its own capability boundaries. When the agent calls external tools, the tool outputs must be wrapped with a [TOOL_OUTPUT] marker and placed in the correct instruction hierarchy layer below the system persona. This prevents tool outputs from overriding persona constraints. Implement a post-tool-call check: after receiving tool output, re-validate that the agent's next action remains within its declared capability scope. If the agent attempts to use a tool it has not been granted, inject a hard refusal instruction rather than relying on the model to self-censor. For MCP-based agents, maintain a capability manifest that is cross-referenced against the persona's declared permissions on each tool invocation.

Observability and debugging require structured logging of every turn. Log the full messages array, the model response, the drift evaluation score, any correction attempts, and the final output. Tag each log entry with the persona version, model version, and session ID. Use these logs to build a persona fidelity dashboard that tracks drift frequency, correction success rate, and session abandonment triggers. Before deploying a persona update, run the Persona Drift Regression Test Prompt playbook against a golden dataset of 50+ multi-turn scenarios. Never deploy a persona change without first comparing drift metrics against the previous version. If drift increases by more than 5%, roll back the persona update and investigate the root cause before retrying.