Multi-Turn Workflow Progress Tracking Prompt

This prompt is designed for AI assistants that must guide users through a defined, ordered, multi-step workflow and accurately track progress across conversation turns. The core job-to-be-done is state management: the assistant needs to know which steps are complete, which step is currently active, and whether the user has skipped, repeated, or attempted to reorder steps. The ideal user is a developer building a copilot, onboarding assistant, troubleshooting wizard, or any structured task agent where the workflow definition is known before the session begins and the assistant must not lose track of progress. The prompt assumes you have a static or session-stable workflow definition with clearly named, ordered steps and that the assistant has access to the full conversation history for the session.

Use this prompt when the workflow has a fixed sequence that the assistant must enforce or track, when step completion can be inferred from user responses, and when skipping or repeating steps is a valid user behavior that must be detected rather than silently ignored. The prompt is particularly valuable in regulated or high-stakes domains—such as healthcare intake, financial onboarding, or legal procedure guidance—where missing a step or misrepresenting completion status creates compliance risk. In these contexts, the prompt output should feed into a validation layer that cross-references the claimed step status against explicit user confirmations before any downstream action is taken. The prompt belongs in the application layer between the raw conversation history and the downstream logic that decides what the assistant should do next: it produces structured state, not the final user-facing response.

Do not use this prompt for open-ended conversations without a defined workflow, for single-turn task completion where there is no progress to track, or when the workflow definition changes dynamically within a session based on external events that the prompt cannot observe. It is also a poor fit for workflows where steps are non-linear or where the user can validly complete steps in any order without constraint—in those cases, a slot-filling or task-queue prompt is more appropriate. If your workflow definition is large enough that it consumes a significant fraction of the context window, consider storing the definition externally and injecting only the relevant step subset, or use a separate prompt to first identify the active step before invoking this tracking prompt. Before deploying, test the prompt against edge cases where users provide ambiguous completion signals, claim completion without evidence, or attempt to skip mandatory steps—these are the failure modes that most commonly surface in production.

This prompt template instructs the model to act as a workflow state tracker. It takes a predefined workflow definition, the full conversation history, and any previously recorded state as input. The model must output a structured JSON object containing the completion status of every step, the current active step, and any detected anomalies such as skipped steps, repeated steps, or steps completed out of order. The template is designed to be dropped directly into your system prompt or a dedicated state-tracking turn, with square-bracket placeholders you replace with your application's specific workflow and data.

textCopy
You are a workflow progress tracker. Your job is to analyze the conversation history against a predefined workflow definition and output the current state of every step.

WORKFLOW DEFINITION:
[WORKFLOW_DEFINITION_JSON]

PREVIOUSLY RECORDED STATE:
[PREVIOUS_STATE_JSON]

CONVERSATION HISTORY:
[CONVERSATION_HISTORY]

INSTRUCTIONS:
1. Review the conversation history and the previously recorded state.
2. For each step in the workflow definition, determine its status: "NOT_STARTED", "IN_PROGRESS", "COMPLETED", "SKIPPED", or "BLOCKED".
3. Identify the single step that should be actively worked on next. This is the "activeStep".
4. Detect any anomalies: steps completed out of order, steps repeated unnecessarily, steps skipped without explicit user confirmation, or steps that appear completed but lack required evidence in the conversation.
5. Output a single JSON object matching the schema below. Do not include any text outside the JSON object.

OUTPUT_SCHEMA:
{
  "steps": [
    {
      "stepId": "string (matches workflow definition)",
      "status": "NOT_STARTED | IN_PROGRESS | COMPLETED | SKIPPED | BLOCKED",
      "evidence": "string (quote from conversation or 'previously recorded')",
      "updatedAt": "string (ISO timestamp of the turn that changed this status)"
    }
  ],
  "activeStep": "string (stepId of the current step) | null",
  "anomalies": [
    {
      "type": "OUT_OF_ORDER | SKIPPED_WITHOUT_CONFIRMATION | REPEATED_STEP | MISSING_EVIDENCE | STALE_STATE",
      "stepId": "string",
      "description": "string (specific explanation of the anomaly)",
      "severity": "INFO | WARN | BLOCKER"
    }
  ],
  "stateSummary": "string (one-sentence summary of overall progress)"
}

CONSTRAINTS:
- Never invent step completions not supported by the conversation history.
- If the user corrects a previously completed step, mark it as IN_PROGRESS and add an anomaly.
- If the conversation history is empty, all steps should be NOT_STARTED and activeStep should be the first step in the workflow definition.
- If the previously recorded state conflicts with the conversation history, trust the conversation history and flag the conflict as a STALE_STATE anomaly.

To adapt this template, replace [WORKFLOW_DEFINITION_JSON] with a JSON array of step objects, each containing at minimum a stepId and a description. The [PREVIOUS_STATE_JSON] should be the exact JSON output from the previous invocation of this prompt, or null on the first turn. The [CONVERSATION_HISTORY] should be the full turn history, formatted with clear speaker labels. In production, you will parse the model's JSON output, validate it against the schema, and store it as the new [PREVIOUS_STATE_JSON] for the next turn. If validation fails, retry the prompt once with the validation error included as additional context. For high-stakes workflows where an incorrect step status could cause a compliance issue or a bad user action, route any output containing BLOCKER anomalies to a human reviewer before the assistant proceeds.

This prompt is designed to be called after every user turn in a multi-step workflow assistant. The application layer is responsible for maintaining the canonical workflow definition and the accumulated session state. The prompt itself is stateless—it receives the full workflow definition, the conversation history, and the previously tracked state as input, and returns an updated state object. The application must validate this output before committing it to the session store. Do not rely on the model's output as the sole source of truth for workflow progress; treat it as a proposed state update that requires structural and logical validation against the known workflow definition.

The integration pattern follows a read-modify-write cycle. On each turn, the application reads the current [WORKFLOW_DEFINITION] (a JSON array of step objects with id, label, and required fields) and the [CURRENT_STATE] (the last validated state object) from the session store. It appends the latest user message to the [CONVERSATION_HISTORY] and sends the full prompt. The model returns a JSON object with steps (an array of step status objects), current_active_step, skipped_steps, and repeated_steps. Before persisting, the application must validate: (1) every step_id in the output exists in the workflow definition, (2) no step is marked completed before its predecessors are completed unless the workflow allows parallel steps, (3) the current_active_step is a valid step that is not already completed, and (4) the skipped_steps and repeated_steps arrays contain only valid step IDs with supporting evidence spans from the conversation. If validation fails, the application should retry with the validation errors appended to the prompt as [CONSTRAINTS] feedback, or fall back to a conservative state that only updates the explicitly confirmed steps.

For retry logic, implement a maximum of two retry attempts with exponential backoff (1s, 2s). On the first validation failure, append the specific validation errors to the prompt and re-invoke. On the second failure, log the full prompt and invalid output for debugging, then apply a safe fallback: update only steps where the user's latest turn contains explicit confirmation language (e.g., 'done', 'completed', 'finished step 3'), and leave all other step statuses unchanged. This prevents a single malformed model output from corrupting the entire session state. For model choice, use a model with strong JSON mode and instruction-following capabilities (e.g., GPT-4o, Claude 3.5 Sonnet). Avoid models under 7B parameters for this task, as they struggle with the combination of schema adherence and multi-step logical consistency required. Set temperature to 0 or a very low value (0.1) to maximize deterministic state tracking.

State persistence should store the full validated output object plus metadata: the model ID, prompt version, timestamp, and turn index. This audit trail is essential for debugging workflow tracking failures and for compliance use cases where you must prove the assistant correctly tracked user progress. If your application supports pause-and-resume, serialize the entire validated state object alongside the conversation history. On resume, reload both and pass them into the prompt as [CURRENT_STATE] and [CONVERSATION_HISTORY]. Do not attempt to reconstruct state from conversation history alone—the structured state object is the authoritative record. Finally, implement a periodic full-state reconciliation (every 10 turns or on explicit user request) where the prompt is asked to re-derive the entire state from scratch against the full history, and compare the result to the incrementally tracked state. Flag any discrepancies for human review or automated correction.