The reason your agent gets worse after an hour is that nothing ever leaves the context window

A dev.to post published under the headline "Research, Plan, Implement: A Workflow That Keeps AI Agents Accurate" makes a structural argument about why long agent sessions go bad: every input you give the agent and every output it produces is appended to the context window, and nothing ever leaves ^[1]. If that diagnosis holds, the remedy is plumbing rather than wording, and the author's remedy is a three-phase workflow in which each phase ends in a markdown file and the context is cleared between phases ^[2][3]. The failure described is cumulative, not sudden. By fifty messages in, according to the author, the agent is re-reading abandoned approaches, stale file contents, and corrections you made an hour ago ^[4]. The post's blunt version: the fix is not a better prompt, it is less context ^[5]. Two habits carry the load. Subagents do the heavy reading in their own context and return only a summary ^[6]. And you clear between phases, on the reasoning that once a phase has produced a file, you no longer need the context that led to it ^[7]. The author says he aims to stay under 40 percent context usage in the main agent ^[8], which is a working ceiling that leaves roughly 60 percent as headroom ^[2]. The three phases are research (write a doc, then clear), plan (write a doc, then clear), and implement ^[3] - two clears across the run ^[1]. The main agent never has to remember the previous phase because the previous phase wrote it down ^[9]. The author credits the pattern to a HumanLayer talk ^[10]. The research phase spins up parallel subagents, and from HumanLayer's repo the author found three most useful: codebase-locator to find where things live, codebase-analyzer to explain how a component works, and codebase-pattern-finder to find existing patterns to model new work on ^[11]. There is a cost angle: his subagents run Sonnet while the orchestrator runs Opus ^[12]. The plan phase runs the locator and analyzer in parallel and then writes a plan naming which files to touch, which lines, and what exactly changes ^[13][14]. The example plan is the most useful part, because it shows what a reviewable artifact looks like. Current state is asserted with file and line references, such as all routes being unthrottled at src/api/router.ts:34-58 ^[15], plus the observation that Redis is already present for session storage so no new infrastructure is needed ^[16]. It carries a discoveries section noting that the existing Redis client is created per request and needs to be a singleton to back a shared counter ^[17], and that health-check endpoints must stay unthrottled or the load balancer will mark instances unhealthy ^[18]. It has an explicit "What We're NOT Doing" list: no cross-region quota syncing, no admin UI, no billing-tier limits ^[19]. Target behaviour is 100 requests per minute per authenticated user and 20 per minute per IP for unauthenticated traffic ^[20], a five-to-one split ^[3], with a 429 and a Retry-After header on breach ^[21]. Real plans, the author says, run a few hundred lines across several phases ^[22]. The honest caveats are in the post too. If you pass in an older research doc the agent should reference it but still verify it, because the code may have drifted ^[23]. And plans are only as good as the requirements: agents fill gaps by assuming, and those assumptions rarely match what the app needs, so edge cases have to be written out ^[24]. The author adds a fourth subagent, context-locator, to pull in prior research, which he says noticeably improves plans ^[25]. What to watch: this is one practitioner's account, with no measured failure rate before or after, and the 40 percent figure is a personal target rather than a benchmark ^[8].