The endless thread is a smell
A lot of new AI coding tools are built around the same idea: start a thread, keep feeding it work, and let it run forever. You can see the assumption hardening into product features: Claude Code lets you name sessions, find and resume them by name, branch them, and export their transcripts. Cursor has editable chat titles, stored history, Markdown exports, and a way to pull old chats into the current one.
They sound like intuitive features to add, but why would a coding conversation need a name? It rests on a premise: that a conversation is a durable unit of work, rather than a temporary interface for finishing one task.
Some tasks take a long time. A large feature needs a proper spec, implementation, testing, and several rounds of correction. Handing that work to an agent doesn't make the complexity disappear. But complexity isn't the same as continuity. Most large tasks should still become a series of small, discrete deliverables: define the interface, add the data model, implement one path, test it, review it, commit it, and then move on.
Small deliverables were better engineering before AI: they produce changes that are easier to understand, test, review, revert, and ship. AI makes the case stronger, because context windows are remarkably small for the job we give them. The largest Claude models hold 1 million tokens, and everything counts against that budget: the system prompt, the tool definitions, every file the agent reads, every test log it scrolls through, and its own thinking. None of it leaves until the session ends or gets summarized. Nor is a bigger window a cure, since Anthropic's own engineers describe context as "a finite resource with diminishing marginal returns."
Agents have limited context, so their assumptions drift and their mistakes compound. When Chroma tested 18 models in July 2025, it found their performance "grows increasingly unreliable as input length grows." The products compensate by summarizing old conversation as the window fills; GitHub even describes automatic compaction as enabling "virtually infinite sessions". The longer a thread runs, the harder it becomes to know which decisions still matter, which constraints have fallen out of view, and whether the latest change quietly broke something from 40 messages ago.
Validation gets worse too. Reviewing one small change is a tractable job, while reviewing a sprawling branch produced across hours of prompts is archaeology. SmartBear, studying a code review team at Cisco, recommends reviewing "no more than 200 to 400 lines of code (LOC) at a time".
The endless thread often looks like an agent capability problem, so we ask how to give it more memory, let it work for longer, or recover when it wanders off course. Often the problem is simpler: the user hasn't broken the work down.
In fairness, an agent can own a meaningful chunk of work, and not every task needs micromanagement. The chunk needs a clear boundary and an outcome you can verify, since a long implementation can still be a sequence of short contracts.
The goal isn't to keep the agent busy, but to keep the work legible. Work quickly and in small increments, check the result, bank the progress, and start the next piece with a clean understanding of what exists. If a coding tool needs one immortal conversation to build useful software, it may be solving the wrong problem.
Update, September 2026: this is the session model I've built into Saggar, my terminal for running coding agents. Terminals belong to a project, so the continuity lives in the repo and the project rather than in any one conversation, and an agent session can be as short as the task it's for. Quick Runs fold away once they succeed, and Run next queues the next piece of work to start when you close the current terminal. Finish the task, close the session, and start the next one clean.