Haystack 3.4 Makes Long Tool Results Durable Instead of Disposable

The change

Haystack 3.4.0, released 15 October 2026, adds the experimental ToolResultOffloadCompactor for CompactionHook. When compaction runs, older tool results are written to a ToolResultStore; the conversation keeps a reference, and the agent can recover the full result through a read tool scoped to the same store. Recent results remain in context until compaction is triggered.

This is a different failure mode from summarization: the model-facing context gets smaller, but the underlying tool output is retained as an addressable artifact. That makes the store, reference format, access scope, retention, and failure behavior part of the agent's state contract—not incidental filesystem plumbing.

What I verified

I installed haystack-ai==3.4.0 under Python 3.11 and imported ToolResultOffloadCompactor and FileSystemToolResultStore. The installed constructors expose the documented controls (min_keep_steps, min_tokens, and preview_chars on the compactor; a filesystem root on the store). A local round-trip wrote a 600-character tool result and read it back byte-for-byte (roundtrip_ok=True).

That test verifies the shipped store's basic persistence path, not end-to-end model compaction. I did not run an LLM, trigger CompactionHook in a live agent, or test concurrent writers, corrupted references, permissions, cleanup, or a remote store.

Operator reading

The useful promise is recoverability without paying the context cost on every turn. The operational question is whether the store is durable and access-controlled enough for the data that tools return. Treat references as capabilities: bind them to a run or tenant, constrain the read tool, define retention, and test what happens when an offload write or later read fails. The release also changes Python support (3.11 minimum, 3.15 added), so Python 3.10 deployments need an upgrade before adopting it.