Incomplete Function Call Recovery Prompt Template

This prompt is for agent-framework builders and AI reliability engineers who need to recover from a specific, high-impact failure: a model's tool call was truncated by a context window limit or token budget exhaustion, leaving a malformed JSON argument block. The job-to-be-done is to reconstruct a complete, valid, and executable function call from the partial output without losing the agent's original intent, the selected tool, or the required parameters. The ideal user is someone integrating this recovery step into an agent harness, where a failed tool call breaks an execution pipeline and requires a structured, automated retry before escalating to a human operator or falling back to a simpler model.

Use this prompt when you have a partial function call—specifically, a JSON object that is cut off mid-structure—and you can provide the original tool schema, the user's goal, and the truncated text. It is designed for scenarios where the model's intent is clear but the syntax is broken, such as a closing brace missing or a string value cut off. Do not use this prompt for semantic errors where the model chose the wrong tool or hallucinated parameters; those failures require a different recovery strategy focused on intent correction, not structural repair. This prompt is also inappropriate when the truncation point is so early that no meaningful arguments were captured, in which case a full re-generation with a reduced context window is a better first step.

The prompt assumes you have a defined [TOOL_SCHEMA] and the raw [TRUNCATED_OUTPUT]. It works best when paired with a validation harness that can parse the repaired JSON, check it against the schema, and confirm that all required fields are present and correctly typed. Before deploying this into a production agent loop, implement a retry budget and an escalation threshold: if the repair fails after a set number of attempts, the system should log the failure, capture the partial output for debugging, and either request human intervention or return a controlled error to the upstream orchestrator. The next section provides the exact prompt template you can adapt and embed in your recovery logic.

This prompt template is designed to be injected into a retry loop when an agent harness detects an incomplete tool call. The core job is to take the partial JSON payload, the original tool's schema, and any available error context, and instruct the model to produce a syntactically valid and semantically correct function call. The template uses square-bracket placeholders so you can wire it directly into your application's retry logic without manual editing.

textCopy
You are a recovery agent for an AI system. Your only job is to repair an incomplete function call.

**Original Task Context:**
[USER_QUERY]

**Tool Definition (JSON Schema):**
```json
[TOOL_SCHEMA]

Truncated Function Call:

jsonCopy
[TRUNCATED_JSON]

Error Message: [ERROR_MESSAGE]

Instructions:

1. Analyze the truncated JSON and the tool schema to understand the intended function and its required parameters.
2. Reconstruct a complete, valid JSON object that strictly conforms to the provided schema. Infer missing values from the original task context where possible.
3. If a required parameter's value cannot be inferred with high confidence, use a null value for that field. Do not hallucinate specific data like names, dates, or identifiers.
4. Your response must be a single, valid JSON object inside a markdown code block labeled json. Do not include any other text, explanations, or apologies.

Recovery Output:

To adapt this template, replace the placeholders with live data from your application's error handler. [USER_QUERY] should contain the original user prompt that triggered the tool call. [TOOL_SCHEMA] is the exact JSON schema of the function the model was attempting to call. [TRUNCATED_JSON] is the raw, incomplete string captured from the model's output. [ERROR_MESSAGE] should include the parsing exception or validation error that flagged the call as incomplete. After the model responds, you must validate the output against the original [TOOL_SCHEMA] before executing the function. If validation fails, increment your retry counter and consider escalating to a human operator if the budget is exhausted.

The incomplete function call recovery prompt is designed to sit inside a retry handler that fires when a tool-use step returns a malformed or truncated JSON argument block. The harness should catch the parse error, extract the partial JSON string and the intended tool name, and inject them into the prompt template as [PARTIAL_JSON] and [TOOL_NAME]. The [TOOL_SCHEMA] placeholder must be populated from the tool's registered JSON Schema definition—never from a cached or assumed version—so the model has the authoritative contract for required fields, types, and enumerations. If the agent framework supports multiple tools, include only the schema for the tool that was being called; providing unrelated schemas increases token cost and risks the model selecting the wrong tool.

After the model returns a reconstructed function call, the harness must validate the output before execution. Parse the response as JSON and check: (1) it is a valid JSON object, (2) it contains a name field matching the original [TOOL_NAME], (3) the arguments field is a valid JSON object, and (4) all required parameters from [TOOL_SCHEMA] are present with correct types. If validation fails, increment a retry counter and re-invoke the recovery prompt with the validation error message appended to [PARTIAL_JSON] as additional context. Set a hard retry limit—typically 2 or 3 attempts—after which the harness should escalate to a human reviewer or log the failure for offline analysis rather than looping indefinitely. For high-risk tools that mutate state (e.g., database writes, API deletions, financial transactions), never execute a recovered call without human approval, even if validation passes.

Model choice matters for this workflow. Use a model with strong JSON generation and instruction-following capabilities, such as GPT-4o, Claude 3.5 Sonnet, or equivalent. Avoid smaller or older models that struggle with partial-input reconstruction. Log every recovery attempt—including the original truncated JSON, the model's reconstructed output, validation results, and whether the call was executed or escalated—so you can measure recovery success rates and identify patterns in truncation failures. If recovery success drops below an acceptable threshold, investigate upstream causes: context window exhaustion, streaming buffer cutoffs, or model output length limits that should be addressed at the generation layer rather than patched in recovery.