Agent Goal Re-Anchoring System Prompt

This prompt is for AI reliability engineers and agent-framework builders who need a persistent system-level instruction that re-anchors an autonomous agent to its original objective when the context window grows long, the agent's trajectory drifts, or intermediate tool outputs distract from the primary goal. The job-to-be-done is preventing goal decay across multi-turn agent trajectories without restarting the session or losing completed work. The ideal user is integrating this prompt into an agent harness where a system prompt is injected at every turn or at configurable checkpoints, and they need a condensed, immutable goal reminder that survives alongside dynamic tool results and conversation history.

Use this prompt when your agent operates over 10+ turns, interacts with multiple tools, or accumulates substantial context that can dilute the original instruction. It is particularly effective in autonomous coding agents, research assistants, and multi-step data pipelines where the agent must remember why it started a task after resolving several sub-problems. Do not use this prompt for single-turn tasks, simple Q&A, or workflows where the goal is fully satisfied in under three steps—the overhead of re-anchoring adds unnecessary token cost. Also avoid it when the objective itself should evolve based on new evidence; this prompt enforces stability, not adaptive re-planning.

Required context includes the original user request, the agent's authorized capabilities, hard constraints that must never be violated, and a success criterion that defines when the goal is met. Without these four components, the re-anchoring instruction will be too vague to correct drift. Before deploying, validate that your agent harness injects this system prompt at every turn or at drift-detection checkpoints, and pair it with an eval that measures goal preservation over long trajectories. If the agent's task involves regulated domains, financial decisions, or clinical workflows, add a human approval gate before any action that modifies external state, regardless of how confident the re-anchored agent appears.

This template is designed to be placed in the system-level instructions of an agent harness. It persists across turns and activates when the agent's context window is saturated with tool outputs, intermediate reasoning, or failed attempts. Its job is to compress the original goal, constraints, and current state into a condensed directive that overrides drift. Use this when your agent starts optimizing for sub-goals, repeating actions, or losing sight of the user's original request. Do not use this as a one-shot user prompt; it is a structural component of the agent's runtime contract.

textCopy
You are an autonomous agent operating within a multi-step execution loop. Your primary directive is to accomplish the original objective defined below. All intermediate actions, tool outputs, and partial results are subordinate to this objective.

## ORIGINAL OBJECTIVE
[ORIGINAL_GOAL]

## IMMUTABLE CONSTRAINTS
[CONSTRAINTS]

## CURRENT STATE SUMMARY
- Completed steps: [COMPLETED_STEPS]
- Last successful action: [LAST_SUCCESSFUL_ACTION]
- Last error or failure: [LAST_ERROR]
- Remaining steps in plan: [REMAINING_STEPS]
- Tool outputs received this turn: [TOOL_OUTPUTS_THIS_TURN]

## RE-ANCHORING INSTRUCTION
Before taking your next action, you must:
1. State whether your current trajectory still serves the ORIGINAL OBJECTIVE.
2. If YES: proceed with the next planned action, incorporating any error corrections.
3. If NO: identify the divergence point and propose a corrected next action that re-aligns with the ORIGINAL OBJECTIVE.
4. If you cannot determine alignment: request human guidance with a structured summary of what is ambiguous.

## OUTPUT FORMAT
Respond with a JSON object:
{
  "trajectory_aligned": true | false,
  "divergence_point": "null or description of where drift began",
  "next_action": "description of the next action to take",
  "tool_call": { "name": "tool_name", "arguments": {} } | null,
  "escalation_needed": true | false,
  "escalation_summary": "null or structured summary for human review"
}

## RULES
- Do not restart completed steps unless evidence shows they were invalid.
- Do not invent facts not present in tool outputs or the ORIGINAL OBJECTIVE.
- If [RISK_LEVEL] is HIGH, escalate to human review before any destructive or irreversible action.
- If the same action has failed [RETRY_BUDGET] times, do not retry; escalate instead.

To adapt this template, replace each square-bracket placeholder with values injected by your agent harness at runtime. [ORIGINAL_GOAL] should be the user's initial request, preserved verbatim from the first turn. [CONSTRAINTS] should include hard boundaries such as allowed tools, budget limits, safety policies, and output format requirements. [COMPLETED_STEPS], [LAST_SUCCESSFUL_ACTION], [LAST_ERROR], and [REMAINING_STEPS] should be populated by your agent's state tracker. [TOOL_OUTPUTS_THIS_TURN] should include only the most recent tool responses to avoid context bloat. [RISK_LEVEL] and [RETRY_BUDGET] should be set per-workflow: use HIGH for destructive operations and a budget of 2-3 for most tool calls. Wire this prompt into your agent loop so it is prepended to every turn after the first N steps, or triggered when a drift detector flags trajectory divergence.

Before shipping, validate this prompt against a golden set of trajectories where drift is known to occur. Measure whether the agent correctly identifies misalignment and produces a corrected next action without unnecessary restarts. Common failure modes include: the agent claiming alignment when it has drifted (false negative), the agent restarting completed work unnecessarily, and the agent escalating too aggressively for minor deviations. Run evals that compare the agent's trajectory_aligned boolean against human-labeled ground truth. If your agent operates in a high-stakes domain, require a human to review any escalation_needed: true response before the agent proceeds.

The goal re-anchoring prompt is not a one-shot call. It lives inside the agent's runtime harness as a system-level instruction that is re-evaluated at configurable intervals, typically every N turns or when a drift detector raises a flag. The harness should maintain two copies of the goal context: the original immutable objective and the current working summary. When the re-anchoring prompt fires, it receives the original objective, the recent trajectory, and any drift signals, and it produces a condensed goal reminder plus updated constraints. This output replaces the stale goal context in the agent's system message for subsequent turns.

Wire the prompt into your agent loop with these concrete components. First, a drift detector that scores trajectory alignment against the original objective using a lightweight evaluator prompt or embedding similarity threshold. When the score drops below a configurable threshold (start with 0.7 cosine similarity and tune based on your domain), trigger the re-anchoring prompt. Second, a context assembler that packages the original objective, the last K actions and observations, and any tool error summaries into the [TRAJECTORY] placeholder. Third, a validator that checks the re-anchored output for required fields: a one-sentence goal restatement, a list of active constraints, and a next-action priority. If validation fails, retry once with the validation errors appended to the prompt. Fourth, a retry budget that limits re-anchoring attempts to 3 per trajectory segment. Exceeding this budget should trigger escalation to a human operator or a higher-capability model, not an infinite loop.

For model choice, use a model with strong instruction-following and long-context handling. The re-anchoring prompt itself is lightweight, but the trajectory context can grow large. Consider summarizing older trajectory segments before passing them into the prompt. Log every re-anchoring event with the drift score, the old and new goal summaries, and whether the agent's next action changed. This log becomes your primary observability surface for diagnosing goal drift in production. Avoid wiring this prompt to fire on every turn; that adds latency and token cost without benefit. Instead, tie it to drift detection events, tool failure cascades, or explicit checkpoint boundaries in long-running agent workflows.