Incomplete Function Call Recovery Prompt

This prompt is for AI engineers and platform developers building tool-use systems where a model's generated function call payload—specifically its JSON arguments—is truncated or interrupted mid-generation. The core job is to repair a partial JSON argument set using available conversation context, flag any arguments that cannot be reliably recovered, and produce a decision on whether to execute the call, re-request missing information from the user, or abort safely. This is a production reliability component, not a general-purpose chat fix.

Use this prompt when your system streams model outputs and tool calls can be cut off by token limits, connection drops, or mid-stream cancellation. It is appropriate for voice assistants, real-time copilots, and any agent loop where a partial function call must be salvaged to avoid a dead-end turn. The prompt expects a structured input containing the partial JSON payload, the function schema, and the preceding conversation context. It is not designed for repairing malformed JSON caused by model hallucination or schema violations—those failures belong to output repair and validation playbooks. Do not use this prompt when the function has side effects that cannot be safely rolled back; in those cases, always abort and re-request confirmation from the user.

Before wiring this into your application, define clear thresholds for unrecoverable arguments. The prompt distinguishes between arguments that can be inferred from context with high confidence and those that require user clarification. You must pair this prompt with a validation harness that checks the repaired JSON against the function schema before execution. For high-risk domains such as finance or healthcare, always route the repaired call to a human approval queue rather than executing automatically. The next step is to integrate this prompt into your tool-calling pipeline immediately after a truncation event is detected, and to log every repair decision for observability and regression testing.

This prompt template is designed to be inserted into a tool-use agent's error-recovery loop. When a function call payload is truncated mid-generation—a common failure in streaming tool-use scenarios—this prompt instructs the model to repair the partial JSON, flag unrecoverable arguments, and decide whether to proceed, re-request information from the user, or abort the call. The template uses square-bracket placeholders for all dynamic inputs so you can wire it directly into your application's retry logic.

textCopy
You are a function-call repair agent. Your job is to recover a partially generated function call that was truncated before completion.

[CONVERSATION_HISTORY]

[PARTIAL_FUNCTION_CALL]

[AVAILABLE_TOOLS]

[RECOVERY_RULES]

Your task:
1. Parse the partial function call and identify which arguments are complete, which are truncated, and which are missing entirely.
2. For each truncated or missing argument, determine whether its value can be reliably inferred from the conversation history above. Do not guess. Only infer if the value is explicitly stated or unambiguously implied.
3. For each argument you cannot infer, classify it as one of:
   - REQUIRED_UNRECOVERABLE: The argument is required and cannot be inferred. The user must be asked.
   - OPTIONAL_UNRECOVERABLE: The argument is optional and cannot be inferred. The call can proceed without it.
   - AMBIGUOUS: Multiple possible values exist. The user must disambiguate.
4. If all required arguments are recoverable, output the repaired function call as valid JSON.
5. If any required argument is unrecoverable or ambiguous, output a clarification request to the user instead.

Output format:
{
  "decision": "PROCEED" | "CLARIFY" | "ABORT",
  "repaired_call": {
    "function_name": "string",
    "arguments": {}
  } | null,
  "unrecoverable_arguments": [
    {
      "argument_name": "string",
      "status": "REQUIRED_UNRECOVERABLE" | "OPTIONAL_UNRECOVERABLE" | "AMBIGUOUS",
      "reason": "string",
      "clarification_question": "string" | null
    }
  ],
  "confidence": 0.0-1.0,
  "rationale": "string"
}

[OUTPUT_CONSTRAINTS]

To adapt this template, replace each square-bracket placeholder with your application's live data. [CONVERSATION_HISTORY] should contain the last N turns formatted consistently with your main assistant prompt. [PARTIAL_FUNCTION_CALL] is the raw truncated JSON or text that the model was generating when the interruption occurred. [AVAILABLE_TOOLS] should include the full function schema for the tool being called, plus any related tools the model might confuse it with. [RECOVERY_RULES] is where you inject domain-specific policies—for example, whether financial amounts must never be inferred, or whether certain argument types always require user confirmation. [OUTPUT_CONSTRAINTS] can include strict JSON mode instructions, temperature settings, or max token limits for the repair response. Always validate the output against the expected schema before acting on the repaired call, and log both the partial input and the repair decision for observability.

The Incomplete Function Call Recovery Prompt is not a standalone chat prompt; it is a recovery module that sits between the model's raw output and your function execution layer. When a tool-use model emits a partial JSON payload—due to a streaming interruption, a context window boundary, or a mid-generation abort—this prompt receives the truncated arguments, the conversation context, and the tool schema, then attempts to produce a valid, callable function invocation. The harness must intercept the malformed output before it reaches your JSON parser or function dispatcher, route it to this recovery prompt, and then validate the repaired output against the original schema before execution.

The implementation flow should follow a strict validate-repair-validate pattern. First, attempt to parse the model's raw output. If parsing fails or required fields are missing, extract the partial JSON string, the last N conversation turns (typically 3–5 turns for context), and the full function schema including required fields, types, and enum constraints. Inject these into the recovery prompt's [PARTIAL_FUNCTION_CALL], [CONVERSATION_CONTEXT], and [FUNCTION_SCHEMA] placeholders. The recovery prompt should return a structured object with a recovery_status field (repaired, unrecoverable, or clarification_needed), a repaired_arguments object, and an optional missing_fields array. Never execute a repaired call without re-validating the output against the schema: check that all required fields are present, types match, and enum values are valid. If validation fails, log the failure and escalate—do not loop the recovery prompt more than twice to avoid drift.

For high-risk tool calls (write operations, financial transactions, data deletion), add a human approval gate after successful repair. The harness should surface the original partial output, the repaired arguments, and the recovery confidence (if your prompt includes a confidence field) in a review queue before execution. For lower-risk read operations, you can auto-execute after validation passes, but always log the repair event with the original truncated payload, the repaired payload, and the conversation turn ID for observability. Model choice matters here: models with strong JSON mode and schema-constrained generation (such as GPT-4o with structured outputs or Claude with tool-use beta) reduce the frequency of partial outputs, but no model eliminates them entirely under streaming or interruption conditions. Budget for this recovery path as a standard error handler, not an exceptional case.