Why Do Unattended AI Agents Redo Completed Work? LangGraph's Context Trap

Unattended LangGraph Agents redo completed nodes because finished content keeps competing for model attention in the context window.
A developer found that their LangGraph Agent silently redid nodes marked "done" during an unattended run, overwriting correct outputs with inferior ones. The root cause wasn't model drift — it was two missing layers: humans in interactive sessions implicitly signal task transitions with each new message, while autonomous Agents have no such external reference; and even with status flags, completed nodes' full reasoning traces remain in the context window, competing for model attention and growing worse over long runs. The fix is to treat "done" as an active context-collapse trigger — compressing completed node outputs into brief summaries to demote them from active attention competitors to settled background facts.
A developer shared a thought-provoking real-world case on Reddit: an AI Agent he built with LangGraph was autonomously executing a code refactoring task overnight — and ended up reprocessing two nodes that had been correctly completed hours earlier. Worse, the second pass used a different naming convention than the first, overwriting the correct output with an inferior version.
No crash. No error. No retry log. The Agent simply looped back to nodes whose status was marked "done" and reworked them. Behind this seemingly bizarre behavior lies a fundamental difference between unattended Agents and interactive sessions.
The Symptom: "Done" Nodes Getting Redone
By conventional reasoning, if a node's status is already "done," the Agent shouldn't touch it. Yet this developer observed exactly the opposite — the Agent ignored the status flag and re-executed completed work.
His first suspicion was model drift, but he quickly ruled it out. As he noted: "The same model running for the same duration in an interactive session doesn't produce this kind of error nearly as often." In other words, the problem wasn't the model itself — it was the mode of operation. Same model, similar task duration, yet interactive use and unattended execution produced dramatically different failure rates. That discrepancy was the real thing that needed explaining.
Model Drift typically refers to the phenomenon where the same model, over extended runs or repeated calls, gradually deviates from expected outputs — due to randomness introduced by temperature settings, cumulative changes in context window contents, or silent updates to the underlying model version. It's a genuine source of interference in long-running Agent tasks, so flagging it as the primary suspect was reasonable. However, model drift is characterized by gradual degradation in output quality — not targeted revisits to already-completed nodes. The latter is distinctly selective, more consistent with a context-driven decision error than random noise. Making this distinction was the critical first step toward identifying the root cause.
The Real Difference: The Hidden Role Humans Play in Interactive Sessions
The developer's analysis was remarkably sharp. His argument: interactive sessions are more stable precisely because humans quietly take on a role that was never formally assigned to them.
In human-in-the-loop interactions, a person naturally notices when a subtask is done and pivots to the next step. The very act of sending the next message implicitly signals that state transition — even if it's never stated explicitly. This invisible boundary management is something humans perform instinctively.
An unattended graph running a long task list has no one filling that role by default. With no one around to say "this step is done, move on," the Agent loses its external reference point for judging task boundaries.
The Root Cause: Completed Nodes Still Competing for Attention
This is the most critical technical insight in the entire analysis. The developer observed that even when node state is tracked per-node, if the full working details of a completed node are still present in the context fed to subsequent steps, that content doesn't sit quietly as a settled fact — it actively competes with the current step for the model's attention.
Worse, over a long run, details from completed nodes accumulate at the same rate as the task itself. The longer the task, the more irrelevant historical detail piles up, and the greater the risk that the current step gets drowned out. At some point, the model "looks back" and redoes a node it believes was never finished — which stops being surprising once you understand the mechanism.
This reveals something that traditional software engineering intuition tends to miss: in LLM-powered Agents, state flags and context content are two separate things. A boolean marked done cannot prevent the model from being reactivated by related historical text — if that text is still in the context window.
This touches on a core mechanism of the Transformer architecture: the attention mechanism treats all tokens in the context window equally. It doesn't natively distinguish between "concluded historical information" and "current instructions to act on." A detailed reasoning trace from a completed node may be comparable in token count to the current task's instructions — giving it substantial weight in attention allocation. This is fundamentally different from the intuition in traditional software, where reading a boolean status bit costs essentially nothing. In an LLM, "completed" content, as long as it remains in the context window, participates in every forward pass and can pull the model's "focus" back to already-finished work. This also explains why state flags alone can't solve the problem: flags are constraints at the program logic layer, while attention competition happens at the model inference layer — the two don't communicate.
The Fix: Make "Done" an Active Context-Shrinking Action
The developer shared two practical approaches that actually worked:
First, actively collapse completed node outputs into a short completion summary before they enter downstream context, rather than carrying the full reasoning chain forward. This way, downstream steps receive a distilled conclusion — "this is done, the result is X" — rather than a detailed trace that might trigger re-processing.
Second, treat a node's done status as a signal that actively reduces its context footprint, not as a status bit that nobody reads. In other words, "done" shouldn't just be a passive flag — it should trigger an actual context-trimming action.
Both recommendations share the same core idea: for unattended Agents, context management must explicitly substitute for the boundary-marking that humans quietly provide in interactive sessions. Since no one is there to signal task transitions, the system must itself demote completed work from "active attention competitor" to "settled background fact."
Context Collapse is a practice pattern gaining traction in Agent engineering, with conceptual parallels to "compressing retrieved results" in Retrieval-Augmented Generation (RAG) and "extracting conclusions" after Chain-of-Thought reasoning. In practice, when a node's status transitions to done, a lightweight summary call can replace the node's full reasoning trace with a structured completion record — for example, {node: 'A', status: 'done', result: '...'}. LangGraph natively supports custom reducer functions on state updates, which provides a built-in integration point for implementing automatic context collapse at the graph's data flow layer — without having to manually filter historical content in every downstream node.
Implications for Agent Engineering
This case has broad relevance for developers building production-grade Agent systems. As AI Agents are increasingly deployed on long-running, unattended tasks, accumulated history in the context window is no longer "free memory" — it becomes a noise source that actively interferes with decision-making.
When designing Agent workflows, it's worth treating active context reduction as a first-class concern on par with state tracking. Relying solely on status flags while letting full history accumulate freely may be harmless in short tasks — but in long-running, autonomous scenarios, it can quietly cause Agents to overwrite their own previously correct outputs, exactly as this case demonstrates.
The original author published a more detailed writeup on Medium: "Unattended AI Agents Have a Context Problem Humans Never Had."
It's worth noting that this is a single developer's observation based on their own experience, and the conclusions haven't been validated at scale — but the problem framing offers genuinely useful perspective for Agent developers.
Related articles

Felix Rieseberg Personal Homepage
Felix Rieseberg's personal homepage sparks attention on Hacker News. This article covers the Slack engineer's technical background, the rise and fall of nativefier, and the value of a developer homepage as a tech calling card.

@ai-sdk/vue 3.0.306 Patch Release Syncs with [email protected] Update
@ai-sdk/vue 3.0.306 released, synced with [email protected]. A routine patch release for the Vercel AI SDK ecosystem with no public API changes; the Vue adapter layer stays version-aligned with the core package.

Gemini 4 Argon API Launches: The Era of Million-Token Output Begins
Google launches Gemini 4 Argon with sparse MoE architecture, up to 1M output tokens, and a 68.90% Vals Index score, available across API, AI Studio, and the Gemini app.