Dynamic Context Truncation Prompt for Agents

This prompt is designed for agent builders whose systems accumulate verbose tool outputs, redundant observations, and repetitive sub-task results that rapidly exhaust the context window. The primary job-to-be-done is compressing agent context in-flight—collapsing noisy tool responses, removing duplicate observations, and retaining only the details required for the next action or decision—without breaking the agent's ability to complete its task. The ideal user is a production AI engineer or technical decision maker who has already instrumented their agent loop with tool-call logging and needs a deterministic, prompt-driven compression step before the next model call to control cost, latency, and reliability at scale.

Use this prompt when your agent's context budget is dominated by raw tool outputs rather than conversation history. It is most effective in single-agent loops where the model receives a sequence of Observation blocks from tools like web browsers, code executors, API calls, or database queries. You should have access to the raw tool output, the action that produced it, and the agent's current task or goal. The prompt works best when you can batch multiple observations into a single compression pass, rather than compressing one observation at a time, because cross-observation redundancy is the primary target. Do not use this prompt for compressing multi-turn user-assistant dialogue; use a conversation summarization or turn pruning prompt instead. Do not use it when tool outputs are already terse and information-dense with no redundancy—the compression step adds latency without benefit.

Before implementing this prompt, ensure you have a validation harness that can compare the agent's task completion rate and error rate with and without compression. The prompt is lossy by design: it will drop details that appear redundant at compression time but may become relevant later. Always log both the raw and compressed context for debugging. If the agent operates in a high-risk domain—such as healthcare, finance, or safety-critical infrastructure—require human review of the compression logic or implement a conservative mode that flags rather than drops uncertain content. Start by applying this prompt when the accumulated tool outputs exceed 50% of your remaining context budget, and measure whether task completion holds steady as you tune the aggressiveness of compression.

This prompt template is designed to be inserted into an agent's execution loop when the accumulated context—tool outputs, sub-task results, and observations—threatens to exceed the context window budget. It instructs the model to act as a context compressor, producing a dense, structured summary that preserves the information necessary for the agent to continue its task without error. The template uses square-bracket placeholders so you can wire in the specific agent state, tool definitions, and output schema required by your harness.

textCopy
You are an agent context compressor. Your task is to reduce the token footprint of the provided agent context while preserving all information required for successful task completion.

## INPUT
[AGENT_CONTEXT]

## COMPRESSION RULES
1. **Truncate Verbose Tool Outputs:** For each tool output, retain only the fields and values listed in [RETAINED_FIELDS]. Remove all other content. If a tool output is a natural language response, summarize it into a single sentence capturing the actionable result.
2. **Collapse Redundant Observations:** If multiple observations or tool results convey the same fact, keep only the most recent or most authoritative instance. Note the deduplication in a brief `[DEDUP: reason]` tag.
3. **Retain Action-Critical Details:** Preserve verbatim any information that matches the patterns in [CRITICAL_PATTERNS]. This includes error codes, IDs, URLs, specific user corrections, and decision outcomes.
4. **Summarize Sub-Task Results:** For each completed sub-task in [SUB_TASKS], replace the full execution trace with a single-line summary: `[SUB_TASK_ID]: [OUTCOME]`. Include any unresolved items.
5. **Preserve Unresolved Items:** List all unanswered questions, pending actions, and unfulfilled commitments from [UNRESOLVED_ITEMS] in a dedicated section at the end of your output.

## OUTPUT FORMAT
Output a valid JSON object conforming to this schema:
{
  "compressed_context": "string containing the full compressed agent context",
  "token_estimate": "integer estimated token count of compressed_context",
  "removed_items": [
    {
      "item_id": "string",
      "reason": "truncated | redundant | summarized | low_signal"
    }
  ],
  "unresolved_items": ["string list of pending questions or actions"]
}

## CONSTRAINTS
- Do not introduce new facts or hallucinate details not present in the input.
- If compression would remove information matching [CRITICAL_PATTERNS], do not remove it.
- If the input is already under [TOKEN_BUDGET] tokens, return it unchanged with a token_estimate and an empty removed_items list.

To adapt this template, start by defining the [RETAINED_FIELDS] for each tool your agent uses. For a web-browsing agent, you might retain only url, status_code, and page_title from a full page fetch. Next, populate [CRITICAL_PATTERNS] with regex-like descriptions of high-signal data: error codes, confirmation numbers, or user corrections. Wire [SUB_TASKS] and [UNRESOLVED_ITEMS] from your agent's internal state tracker. Set [TOKEN_BUDGET] to a value below your model's context limit, leaving headroom for the system prompt and future turns. Before deploying, run this prompt against a golden dataset of agent traces and validate that the compressed_context leads to identical task completion rates as the uncompressed baseline. If your agent operates in a high-risk domain, route outputs where removed_items contains items matching [CRITICAL_PATTERNS] to a human reviewer before the agent continues.

This prompt is designed to be called as a pre-processing step inside an agent's main execution loop, immediately before the primary reasoning or action model is invoked. The harness should intercept the agent's working memory—a structured object containing the system prompt, recent conversation turns, and accumulated tool outputs—and pass it to the truncation prompt when a token budget threshold is exceeded. The output is a compressed, structured representation of the agent's context that replaces the verbose working memory for the subsequent call to the primary model. This is not a one-time setup; it is a recurring budget-reclamation subroutine that fires whenever the estimated token count of the agent's state crosses a configured limit, such as 80% of the model's context window.

The implementation must treat the truncation prompt as a deterministic state transformation with a strict input and output contract. The input should be a JSON object with fields for system_instructions, conversation_turns (an ordered list of objects with role, content, and turn_id), and tool_outputs (a list of objects with tool_name, output, and call_id). The prompt's output must be parsed and validated against a schema that includes compressed_context (a string for the model's next system message), retained_turn_ids (a list of IDs preserved verbatim), and discard_log (a list of removed items with a reason for each). If the output fails schema validation, the harness should retry once with the validation error injected into the prompt's [CONSTRAINTS] field. If the retry also fails, the system must fall back to a safe but expensive behavior, such as sending the full, untruncated context and logging an alert, rather than proceeding with a malformed compression.

To make this workflow observable, the harness must emit structured logs and metrics at each invocation. Log the pre_truncation_token_count, post_truncation_token_count, compression_ratio, and the full discard_log. This data is critical for debugging agent failures: if a task fails after truncation, you can query the discard log to see if a critical observation was removed. Instrument a counter metric for truncation_attempts and truncation_failures (both schema validation failures and downstream task failures attributed to truncation). For high-stakes agent workflows, consider a shadow mode where the truncated context is used for the primary model, but a parallel, async call is made with the full context to a cheaper evaluator model. The evaluator can judge if the compressed context led to a materially different or worse action, creating a continuous feedback loop for tuning the truncation prompt's instructions without degrading the live user experience.