An agent pipeline consists of three sequential tools: a CodeAnalysisTool that identifies functions to refactor, a RefactoringTool that applies the changes, and a TestRunnerTool that validates the output. The agent passes state between tools by appending each tool's output to the conversation context. After testing, the team notices that when the CodeAnalysisTool's output is long (>2000 tokens), the TestRunnerTool sometimes receives incomplete state because earlier context was truncated from the window. Which state-sharing mechanism would MOST reliably solve this problem?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Routing inter-tool state through the conversation window is like passing instructions verbally down a chain of workers — the last person only remembers what wasn't drowned out by the noise. A shared state store is the clipboard on the wall: every tool reads from and writes to it directly, without depending on what the conversation remembered to pass along.
Full explanation below image
Full Explanation
Context window truncation is a fundamental constraint of LLM-based agent architectures. When tool outputs are passed through conversation history, they compete for the available token budget with the system prompt, user instructions, and all intermediate reasoning. For multi-tool pipelines, this creates a reliability cliff: pipelines work fine with small outputs but fail unpredictably when outputs grow.
A shared external state store solves this by removing inter-tool state from the conversation entirely: 1. CodeAnalysisTool writes its complete findings to a structured external artifact (e.g., state/task-{id}/analysis.json) — no token limit applies to stored files 2. RefactoringTool reads the analysis directly from the file system or database — it receives the complete, untruncated data regardless of its size 3. TestRunnerTool reads both the analysis and the refactoring results from the same store to perform validation
The conversation context then only needs to carry brief references to the store locations and high-level summaries, keeping token consumption minimal.
Option A (summarize the output) reduces token usage but introduces information loss. A summary of which functions to refactor may omit details the RefactoringTool needs, leading to incomplete or incorrect refactoring. Summarization trades reliability for brevity. Option C (larger context window) is a temporary fix that delays but does not eliminate the problem — as codebase complexity grows, even large context windows will eventually be exceeded. It also increases cost for every token in the extended window. Option D (re-inject at each call) maintains data fidelity but doubles or triples token consumption, is still subject to eventual context overflow, and adds complexity to the prompt construction logic for each tool. The exam-level principle is that structured external state stores are the architecturally correct mechanism for cross-tool state in multi-step agentic pipelines.