Tool Context Pruning

Definition

Application-side filtering of verbose tool responses down to only the fields the conversation needs, before they enter the context window.

Key points

• The bloat: repeatedly calling lookup_order fills the context window with verbose shipping and payment data when only the return status is needed.
• The pattern: application-side filtering. Extract only the relevant fields (items, purchase data, return window, status) from each order response, removing verbose details before the conversation proceeds.
• Diagram: Raw API Response (40+ fields) → Application-Side Filter (funnel) → Pruned Context.
• Aligns with managing multiple extensive tool responses in a single support session.
• On the Architect's Reference Matrix this is the Token Bloat row for Customer Support (paired there with "Filter Stale Results"); complements Prompt caching and Compressing Long Sessions as a state/token lever.

Why it matters for the exam

• README study focus item. "Tool responses are bloating context" → answer is prune fields application-side, not raise the context window or stop calling the tool.

Common gotchas

• Pruning happens in your application code, not by asking the model to ignore fields.
• Distinct from stale-data filtering on resumption (dropping old tool_result messages) — pruning trims field-level verbosity.

See also

• Prompt Caching
• Compressing Long Sessions
• Structured Intermediate Representations
• Architect's Reference Matrix

Sources

• architects-playbook
• netlight-study-guide