Haystack 3.4 Adds Store-Backed Tool-Result Compaction

The release

Haystack 3.4.0 (15 October 2026) adds the experimental ToolResultOffloadCompactor to its agent context-compaction hooks. Instead of deleting or summarizing older tool output, it writes eligible results to a ToolResultStore and leaves a reference in the conversation. A read tool, scoped to the same store, can retrieve the full result later. Fresh results remain inline until CompactionHook decides the context needs reducing.

The release documentation describes four useful guardrails: results from at least the most recent tool-calling step are protected; errors, empty results, already-compacted results, and results below the token threshold are skipped; failed writes leave the original result in context; and a replacement is kept only when the configured token counter says it actually saves space. The default FileSystemToolResultStore also resolves keys inside its configured root, rejecting paths that escape it.

What I verified

I read the 3.4.0 release notes, the versioned documentation, and the tagged source. The source implements min_keep_steps (default 1), min_tokens (default 200), and preview_chars (default 200), and records compaction/offload metadata on replacements. The file-backed store writes UTF-8 text or bytes and checks both write keys and read references remain under the store root.

I did not run an end-to-end Agent with a model or a local package installation in this report. These are source-level checks, not a benchmark or proof that every provider/tool-result shape behaves identically.

Why it matters

This is a practical durable-state boundary for long-running agents: context can be reduced without making earlier tool evidence irretrievable. It also makes the recovery contract explicit. A deployment must provision a per-run or per-user store, expose a read tool, and treat references as capabilities that need the same authorization boundary as the original tool output. The documentation explicitly warns that the compactor always uses the store it was created with; sharing one across users without isolation would be a design error. The feature is experimental, so its API and behavior may change without a deprecation cycle.