Thread-per-Task

Understand This First

• Context Window – thread-per-task is a response to context window limits.

Context

At the agentic level, thread-per-task is the practice of giving each coherent unit of work its own conversation thread. Rather than running a long, sprawling conversation that covers multiple features, bug fixes, and refactorings, you start a fresh thread for each distinct task.

This pattern is a direct response to the limits of the context window. A long conversation accumulates context (some relevant, some stale) until the window is saturated and the agent begins losing coherence. Thread-per-task keeps each conversation focused, fresh, and manageable.

Problem

How do you prevent agentic sessions from degrading in quality as conversations grow longer and accumulate irrelevant context?

Developers naturally continue existing conversations, adding “one more thing” after the previous task is done. This is convenient but costly. Each completed task leaves behind context (file contents, intermediate reasoning, dead-end approaches) that consumes window space without benefiting the next task. Over time, the agent’s effective memory for the current task shrinks as the accumulated weight of previous tasks grows.

Forces

• Convenience favors continuing an existing conversation rather than starting a new one.
• Context carryover: sometimes the next task genuinely benefits from what was discussed earlier.
• Context pollution: more often, the previous task’s context is irrelevant noise for the next one.
• Session setup cost: starting a fresh thread means re-establishing project context, though instruction files reduce this cost.

Solution

Start a fresh conversation thread for each distinct task. A “task” is a coherent unit of work with a clear goal: fix a specific bug, implement a defined feature, refactor a module, write tests for a component. When one task is done, close the thread and open a new one for the next.

This doesn’t mean every thread must be short. A complex feature implementation might require a long conversation, and that’s fine, as long as the conversation stays focused on one task. The anti-pattern is a conversation that drifts through multiple unrelated tasks, accumulating context that’s increasingly irrelevant to whatever the agent is currently doing.

When context from a previous task is genuinely needed, transfer it explicitly: summarize the relevant findings or link to the relevant files. This is more effective than carrying an entire conversation history because you control what context enters the new thread.

How It Plays Out

A developer fixes a bug in thread 1, then asks “while you’re here, can you also add input validation to the form?” The agent adds validation but uses a coding style inconsistent with the project conventions it was following five minutes ago. The conventions have scrolled out of effective context, displaced by the bug fix discussion. Starting thread 2 with a fresh context for the validation task would have produced better results.

A team adopts a strict thread-per-task discipline. Each morning, a developer opens a thread for each planned task: one for the bug fix, one for the feature, one for the documentation update. Each thread gets the agent’s full, fresh context. At the end of the day, completed threads are closed and their summaries are recorded in the progress log.

Here’s what the difference looks like in practice. A developer is 90 minutes into a thread that started with a database migration and has since wandered into bug fixes and a refactor. She asks the agent to add a field to the user form:

Developer:
  "Add a 'preferred_name' field to the signup form. Use the same
  validation pattern as the existing 'display_name' field."

Agent (in the sprawling thread):
  Adds the field. Uses a regex validator with snake_case naming,
  inline error messages, and a tailwind utility class for the
  input width.

Developer notices:
  The project uses camelCase for form field names, uses a shared
  `validators.ts` module (not inline regexes), shows errors in a
  toast (not inline), and has a design system class for form inputs.
  The agent followed these conventions 90 minutes ago when touching
  the same file. They've since scrolled out of effective context,
  buried under migration SQL and refactor diffs.

She closes the thread and opens a fresh one:

Developer (fresh thread):
  "Read CLAUDE.md and src/components/forms/README.md, then add a
  'preferred_name' field to the signup form, matching the pattern
  used for 'display_name'."

Agent:
  Reads the conventions file and the form directory's README.
  Adds `preferredName` (camelCase), imports from `validators.ts`,
  wires errors through the toast system, applies the `FormInput`
  design system class. Matches the existing file's style exactly.

Same task, same agent, same codebase. The only difference was the starting context. The first thread’s output would have needed a code review catch and a rework; the second thread’s output was ready to merge.

Consequences

Thread-per-task keeps agent output quality high by ensuring each task gets a fresh, focused context. It makes conversations easier to review because each thread has a clear scope. It also creates a natural audit trail: completed threads document what was done and how.

The cost is the overhead of starting new threads and re-establishing context. Instruction files reduce this cost significantly, since project conventions are loaded automatically. The remaining cost is providing task-specific context, which is usually a few sentences describing the goal and pointing to the relevant files.

Related Patterns

• Depends on: Context Window – thread-per-task is a response to context window limits.
• Uses: Instruction File – instruction files reduce the cost of starting fresh threads.
• Uses: Memory – memory carries learnings across threads without carrying stale context.
• Enables: Progress Log – each thread’s outcome feeds the progress log.
• Enables: Subagent – subagents naturally operate as separate threads.
• Uses: Compaction – compaction is an alternative to starting fresh when the thread must continue.

Sources

• Drew Breunig’s How Long Contexts Fail (2025) named the failure modes that make thread-per-task necessary: context poisoning, context distraction, context confusion, and context clash. These names gave practitioners a shared vocabulary for problems they had been hitting in practice.
• Yichao “Peak” Ji and the Manus team articulated the production case for spinning up fresh sub-agents per task in Context Engineering for AI Agents: Lessons from Building Manus (2025), borrowing the discipline from Go’s concurrency slogan, “share memory by communicating, don’t communicate by sharing memory.”
• Anthropic’s engineering essay Effective Context Engineering for AI Agents (2025) frames the context window as a finite, degradable resource, which is the constraint thread-per-task exploits.
• The underlying intuition – that fresh conversations outperform sprawling ones – emerged from the agentic coding practitioner community as long-running sessions began visibly degrading. The originators of the exact phrase “thread-per-task” are communal; the pattern is named here to give the practice a fixed handle.