Tool Output Compression for Budget Reclamation Prompt

This prompt is designed for production AI engineers and agent builders who need to reduce the token footprint of verbose tool outputs—such as raw API responses, search engine results pages, or large file reads—before they consume the context window. The core job-to-be-done is budget reclamation: preserving the actionable data, structured fields, and critical identifiers from a tool response while discarding boilerplate, HTML, redundant metadata, and low-signal prose. The ideal user is an engineering lead or developer integrating this compression step into an agent loop, a copilot's tool-call handler, or a RAG pipeline where tool outputs compete with conversation history and system instructions for limited context space.

You should use this prompt when your agent or copilot makes function calls that return payloads exceeding a few hundred tokens, especially when multiple tool calls occur in a single turn. It is particularly effective for compressing REST API responses, web_search results, database query outputs, and file read operations before they are injected into the model's next request. The prompt expects a raw tool output as [INPUT], an optional [OUTPUT_SCHEMA] describing the fields you need to preserve, and a set of [CONSTRAINTS] such as a target token limit or required fields. The output is a compressed, schema-preserving object that retains only essential information. This is not a summarization prompt for natural language understanding; it is a structured data compression step that must not hallucinate values, drop required identifiers, or alter numeric data.

Do not use this prompt when the tool output is already small, when the downstream task requires verbatim source text for citation or compliance, or when the compression step itself would introduce latency that outweighs the budget savings. It is also inappropriate for compressing user messages or system instructions—those require different preservation rules. Before deploying, wire the prompt into a validation harness that checks the compressed output against the original for field completeness, type consistency, and value preservation. For high-risk domains such as finance or healthcare, add a human review step or a secondary verification prompt that compares critical fields before the compressed output enters the agent's context. Start by measuring your current token consumption per tool call, then apply this prompt to outputs exceeding your budget threshold and monitor downstream task completion rates to confirm that compression is not degrading action correctness.

This prompt template is the core instruction set for reclaiming context budget from verbose tool outputs. It is designed to be inserted into an agent or copilot harness immediately after a tool returns a response and before that response is appended to the conversation history. The prompt instructs the model to act as a lossy compression function: preserve the fields required for downstream decision-making and tool calls, discard explanatory fluff, and output a structured object that matches a predefined schema. Use this template when your agent's context window is dominated by large API payloads, search result pages, or multi-step function returns that contain far more text than actionable signal.

textCopy
You are a tool output compressor for an AI agent system. Your task is to compress the provided tool output into a minimal, schema-preserving summary. You must preserve every field that could affect a downstream decision, tool call, or user-facing answer. You must discard explanatory text, markdown formatting, boilerplate, and any field that is not actionable.

[OUTPUT_SCHEMA]

[TOOL_OUTPUT]

[COMPRESSION_RULES]

Return ONLY the compressed output as valid JSON matching the schema above. Do not add commentary, markdown fences, or extra text. If a required field is missing from the tool output, set its value to null. If you are uncertain whether a field is actionable, retain it.

After copying the template, replace the three square-bracket placeholders with concrete values for your integration. [OUTPUT_SCHEMA] should contain a JSON Schema or TypeScript interface describing the exact shape you need downstream. [TOOL_OUTPUT] is the raw string returned by the tool, API, or function. [COMPRESSION_RULES] is where you encode domain-specific retention logic—for example, 'Retain all order IDs, status codes, and error messages. Drop product descriptions, timestamps older than 24 hours, and HTTP headers.' Adapt these rules per tool type. For high-stakes workflows such as financial transactions or clinical data, add a rule requiring the compressor to flag any field it drops that might be safety-relevant, and route those flags to a human reviewer before the compressed output is used downstream.

The Tool Output Compression prompt is not a standalone utility; it is a budget-reclamation step inside an agent execution loop. The harness must intercept verbose tool responses—API payloads, search result blobs, multi-page function returns—before they enter the main context window. The goal is to reduce token consumption while preserving the fields and values that downstream reasoning or tool-calling steps actually need. This means the harness owns three responsibilities: deciding when compression is triggered, validating that the compressed output is still actionable, and recovering when compression drops critical data.

Implement a pre-compression filter that checks the raw tool output size against a configurable threshold (e.g., 2,000 tokens). Outputs below the threshold bypass compression entirely to avoid unnecessary latency. For outputs above the threshold, extract the tool name, the output schema if available, and the downstream task context (e.g., 'the agent needs to decide the next function call' or 'the user needs a summary'). Pass these as [TOOL_NAME], [OUTPUT_SCHEMA], and [DOWNSTREAM_TASK] placeholders into the compression prompt. After compression, run a post-compression validator that checks: (1) the compressed output is valid JSON matching the expected schema, (2) required fields specified in [REQUIRED_FIELDS] are present and non-null, and (3) the compression ratio is within an acceptable range (e.g., 50–90% reduction). If validation fails, log the failure with the tool name, raw output length, compressed output length, and the specific validation error. Then trigger a retry with the same prompt but append the validation error as a [PREVIOUS_FAILURE] constraint.

Retry logic should be bounded. Set a maximum of two retry attempts. If both attempts fail validation, fall back to a safe truncation strategy: take the first N tokens of the raw output (where N is a conservative budget allocation) and attach a warning flag to the context object. The downstream agent or user-facing step can then decide whether to request the full output explicitly. Log all compression events—attempts, ratios, validation results, and fallback triggers—as structured telemetry so the team can tune thresholds, identify brittle tool outputs, and decide when to invest in tool-specific output schemas instead of relying on prompt-based compression. Do not use this prompt for outputs where field-level precision is legally or financially binding without human review of the compressed result.