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?

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. Using a shared external state store solves this by removing inter-tool state from the conversation entirely. The CodeAnalysisTool writes its complete findings to a structured external artifact, such as 'state/task-{id}/analysis.json', and no token limit applies to stored files. The RefactoringTool reads the analysis directly from the file system or database, so it receives the complete, untruncated data regardless of its size. The 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. Summarizing the CodeAnalysisTool output before passing it to the RefactoringTool reduces token usage but introduces information loss. Summarization of which functions to refactor may omit details the RefactoringTool needs, leading to incomplete or incorrect refactoring, so summarization trades reliability for brevity. Switching to a model with a larger context window is a temporary fix that delays but does not eliminate the problem, because as codebase complexity grows, even large context windows will eventually be exceeded; it also increases cost for every token in the extended window. Re-injecting the CodeAnalysisTool output at the beginning of each subsequent tool 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.