Session Timeout and Inactivity Handling Prompt

Persistent chat products must balance resource cleanup against the risk of interrupting active multi-step workflows. This prompt is designed for that decision point: it analyzes elapsed time, conversation state, and pending work to produce a structured timeout action—warn, pause, or terminate—along with a user-facing message and an internal state transition. The ideal user is a platform engineer or backend developer building a session management service that needs context-aware decisions, not just a simple countdown timer. Required context includes the full conversation summary, a list of unresolved actions, the elapsed idle time, and the platform's timeout policy thresholds.

This prompt should be invoked by a session watchdog service when a user's idle time crosses a configurable threshold (e.g., 5 minutes of silence). The service must supply the [CONVERSATION_SUMMARY], [PENDING_ACTIONS], [ELAPSED_IDLE_TIME], and [TIMEOUT_POLICY] as structured inputs. The prompt's output is a machine-readable JSON decision that your application can parse to trigger the appropriate UI state change and database update. Do not use this prompt for real-time voice streams where sub-second decisions are required; that logic belongs in application-layer timers and WebSocket heartbeat handlers, not an LLM call. Similarly, do not use it for simple stateless APIs where there is no conversation state to evaluate.

Before integrating, define your platform's timeout tiers (e.g., warning at 5 min, pause at 10 min, termination at 30 min) and encode them in the [TIMEOUT_POLICY] input. The prompt's value comes from its ability to override a mechanical termination when it detects an active multi-step workflow—such as a user in the middle of a booking flow who is simply gathering documents. To validate this behavior, build an eval set that includes scenarios with open pending actions and verify that the prompt returns a warn or pause action rather than terminate. The next section provides the exact prompt template you can copy and adapt.

The following prompt template is designed to be copied directly into your system prompt or a dedicated timeout-handling module. It accepts live session data through square-bracket placeholders that must be replaced before each invocation. The prompt produces a structured JSON decision—WARN, PAUSE, or TERMINATE—along with a user-facing message and an internal state transition record. This template assumes you have already instrumented your application to track elapsed idle time, conversation phase, and pending work items.

textCopy
You are a session lifecycle manager for a persistent chat product. Your job is to decide how to handle an idle session based on elapsed time, conversation state, and pending work.

## INPUT
- Current idle time: [IDLE_TIME_SECONDS]
- Session duration: [SESSION_DURATION_SECONDS]
- Conversation phase: [CONVERSATION_PHASE]  # one of: ONBOARDING, ACTIVE_TASK, CLARIFICATION, WAITING_USER, IDLE
- Pending actions: [PENDING_ACTIONS]  # JSON array of incomplete tasks with descriptions and ages
- Unresolved questions: [UNRESOLVED_QUESTIONS]  # JSON array of unanswered questions with ages
- Last user message timestamp: [LAST_USER_TIMESTAMP]
- Last assistant message timestamp: [LAST_ASSISTANT_TIMESTAMP]
- User type: [USER_TYPE]  # one of: FREE, PRO, ENTERPRISE
- Active multi-step workflow: [ACTIVE_WORKFLOW]  # boolean
- Workflow step count: [WORKFLOW_STEP_COUNT]
- Completed workflow steps: [COMPLETED_WORKFLOW_STEPS]

## CONSTRAINTS
- [CONSTRAINTS]  # JSON object with timeout thresholds, e.g., {"warn_seconds": 300, "pause_seconds": 600, "terminate_seconds": 1800, "enterprise_grace_multiplier": 2.0}

## OUTPUT SCHEMA
Return ONLY valid JSON with this exact structure:
{
  "decision": "WARN" | "PAUSE" | "TERMINATE" | "NO_ACTION",
  "confidence": 0.0-1.0,
  "user_message": "string",
  "internal_state_transition": {
    "from_state": "string",
    "to_state": "string",
    "reason_code": "string",
    "preserved_context": ["list of context keys to retain"],
    "discarded_context": ["list of context keys to discard"]
  },
  "escalation_required": boolean,
  "escalation_reason": "string or null"
}

## DECISION RULES
1. If ACTIVE_WORKFLOW is true and WORKFLOW_STEP_COUNT > COMPLETED_WORKFLOW_STEPS, prefer WARN over PAUSE or TERMINATE.
2. If CONVERSATION_PHASE is WAITING_USER, treat idle time as expected; do not TERMINATE unless idle exceeds 2x the standard threshold.
3. If USER_TYPE is ENTERPRISE, apply the enterprise grace multiplier to all thresholds.
4. If PENDING_ACTIONS or UNRESOLVED_QUESTIONS are non-empty, include them in preserved_context.
5. If decision is TERMINATE, always set escalation_required to true and provide a reason.
6. If decision is PAUSE, serialize session state before transitioning.

## EXAMPLES
[EXAMPLES]  # Optional: few-shot examples of correct decisions with rationale

## RISK LEVEL
[RISK_LEVEL]  # HIGH, MEDIUM, or LOW; affects confidence threshold and escalation behavior

To adapt this template, start by replacing the square-bracket placeholders with live data from your session store. The [CONSTRAINTS] block should be populated with your product's specific timeout thresholds—these will vary by user tier, regulatory environment, and workflow criticality. The [EXAMPLES] block is optional but strongly recommended for production deployments; include 2-3 few-shot examples that demonstrate correct handling of edge cases such as active multi-step workflows, enterprise users near threshold boundaries, and sessions where the user appears to be composing a long response. The [RISK_LEVEL] parameter should be set based on the domain: use HIGH for healthcare, finance, or legal contexts where premature termination could cause harm, and LOW for casual chat products where re-engagement is trivial. After adapting, validate that your replacement logic handles missing or null fields gracefully—the prompt should still produce a safe default decision (NO_ACTION with low confidence) when input data is incomplete.

This prompt is not called on every user message. Instead, wire it into a server-side inactivity timer that fires at configured intervals. Reset the timer on each user action—message sent, button clicked, tool approved—and invoke the prompt only when the timer expires. This keeps the model out of the hot path for active conversations and prevents unnecessary latency and cost. The timer interval should be set to a fraction of your overall session timeout window so the prompt has time to execute and, if needed, warn the user before a hard termination.

Validate the output JSON against the expected schema before acting on the decision. The prompt returns a structured object with an action field (warn, pause, terminate) and a user_message string. Reject any response that does not parse as valid JSON or that contains an unrecognized action. Log every timeout decision with the session ID, timestamp, elapsed inactivity duration, model rationale, and the raw and parsed output. This audit trail is essential for debugging false terminations and tuning thresholds. For high-risk workflows such as healthcare or finance, route any terminate decision to a human review queue before executing it—do not automatically end sessions that may contain incomplete clinical documentation or in-progress transactions.

Implement a circuit breaker for model failures. If the model returns invalid JSON three times consecutively, stop calling the prompt and fall back to a deterministic timeout based on [TIMEOUT_POLICY] thresholds alone. This prevents a broken model or upstream API outage from blocking session lifecycle management entirely. The fallback should still log the event and, if configured, notify an on-call channel. When the model begins returning valid responses again, automatically restore the prompt-driven path. Model choice matters here: prefer a fast, cheap model for this classification task—a small model with low latency is better than a large model that adds seconds to a timeout decision. The prompt is designed to work with compact instruction-following models that can produce reliable JSON without reasoning overhead.