# Why your context-engineering "optimization" is probably breaking > Source: > Published: 2026-08-27 23:52:10+00:00 # Why your context-engineering "optimization" is probably breaking The team tried to solve two classic LLM workflow problems: token bloat from tool outputs and the loss of "thinking" traces from models like [DeepSeek](/en/tags/deepseek/). Both solutions looked perfect on a whiteboard, but both failed spectacularly in production. ## The failed sliding window approach The first attempt was a tool-result sliding window. In long agent sessions, the context window gets choked by massive blobs of text—directory listings, file contents, test logs. The "fix" was to implement a mechanism where tool outputs older than $N$ rounds were compressed into a tiny placeholder: ``` [Tool results omitted - older than recent 7 rounds] executed: read_file x3, bash x2 tool_call_ids: ... full results: history.jsonl ``` The logic was a classic token economy play: keep the recent stuff, compress the old stuff, and keep the full logs on disk for auditing. The problem? It failed **silently**. If the model needed a specific detail from a file read in round 3 to make a decision in round 12, it simply couldn't see it. There was no error message, no crash, and no "missing data" warning. The model just made a slightly worse decision or hallucinated a detail. When an agent's performance degrades without a clear error signal, you aren't debugging; you're just guessing. ## The "reasoning pass-back" mistake The second feature was even more ambitious. When using models with reasoning modes (like DeepSeek's thinking process), the "thought" tokens are usually discarded after the final answer is generated. The team decided to re-inject that reasoning back into the context for the next turn. The idea was to give the model its own logic as permanent memory. This failed because it was **unmeasured**. Adding reasoning back into the context changes the model's probability distribution. It costs more tokens and alters how the model perceives the next prompt. Without a rigorous A/B test or a specific metric to track if this actually improved task completion, the team was essentially flying blind on a "belief" rather than a proven mechanism. ## The takeaway for prompt engineering and agent design If you are building an LLM agent or working on complex prompt engineering workflows, there is a massive lesson here regarding context transformation. Whether you are compressing, summarizing, or re-injecting data, you are fundamentally changing the information density the model sees. The failure mode to avoid is the "silent loss." If your context management system decides to drop or summarize information, it must be anchored to an external metric. You cannot just hope the model doesn't need that data. A robust AI workflow needs: **Countable signals:** You need to know exactly how many tokens were compressed and what specific data points were omitted.**Auditability:** If a model fails, you must be able to see instantly if a context-management rule (like a sliding window) was the culprit.**Directional guardrails:** A guardrail that fails "safe" (by doing nothing and keeping all tokens) is easy to ignore, but a guardrail that fails "silent" (by quietly dropping data) is impossible to audit. Don't build "smart" context managers unless you have a way to measure exactly how much intelligence you are stripping away in the name of token efficiency. [Next Publicly auditing my OSS release proved that your documentation →](/en/threads/7914/)