The Discipline of One-Task-Per-Agent: Solving Context Rot in Agentic Workflows

In the early days of Vibe Coding, the dream was simple: give a highly capable AI agent a massive context window, point it at a repository, and say, “Build me a competitor to X.” We marveled at 100k, 200k, and even million-token windows. But as any senior engineer who has spent dozens of hours in deep agentic sessions knows, the “Drunken Master” phenomenon eventually takes over.

After fifty turns, your once-brilliant agent starts hallucinating file paths that don’t exist, forgetting the security constraints established in turn three, and—most frustratingly—introducing regressions in code it wrote perfectly ten minutes ago. This isn’t a failure of the model’s intelligence; it is a fundamental byproduct of Context Rot.

The solution isn’t a larger context window. The solution is the Discipline of One-Task-Per-Agent. This advanced architectural pattern shifts our focus from “One Agent for the Whole Project” to “One Agent for One Atomic Task.” By enforcing strict epistemic isolation, we can achieve 10x higher reliability and maintain production-grade quality in even the most complex Vibe Coding initiatives.

The Core Problem: Why Context is Your Enemy

To understand why we need the One-Task-Per-Agent discipline, we must understand how LLMs process attention. Even with “Long Context” models, there is a phenomenon known as Loss-in-the-Middle. As the conversation history grows, the model’s “attention” is stretched thin across thousands of tokens of previous attempts, failed terminal commands, and irrelevant file reads.

1. Context Poisoning

When an agent tries to fix a bug, fails, and tries again, the “failure” remains in its memory. In subsequent turns, the agent is more likely to repeat the same logic or get confused by its own previous errors. The context becomes “poisoned” with bad ideas.

2. The Distraction Multiplier

In a multi-file refactor, an agent might read twenty files to understand a dependency. Those twenty files now sit in the context window, competing for attention with the actual code being edited. Every irrelevant line of code the agent reads is a potential source of distraction.

3. State Bloat

In Vibe Coding, we often iterate rapidly. A single “agent session” might encompass a research phase, a strategy phase, an implementation phase, and a testing phase. By the time the agent reaches the testing phase, the research data is stale, but it still consumes tokens and attention.

How It Works: The Philosophy of Decomposition

The Discipline of One-Task-Per-Agent is rooted in the UNIX philosophy: Do one thing, and do it well. Instead of asking an agent to “Refactor the authentication system,” we decompose that goal into a Directed Acyclic Graph (DAG) of atomic sub-tasks, each executed by a “fresh” sub-agent with a surgically curated context.

Epistemic Isolation

When a sub-agent is spawned for a single task (e.g., “Update the login schema in user.ts”), it starts with a clean slate. It doesn’t know about the three failed attempts the previous agent made. It only knows the current state of the file and the specific instruction. This isolation prevents the “sunk cost fallacy” of agentic reasoning.

The Orchestrator-Worker Pattern

In this discipline, we distinguish between two roles:

The Orchestrator: Maintains the high-level goal, tracks progress, and decomposes the work.
The Worker (Sub-Agent): Receives a specific, atomic directive, performs the work, validates it, and returns a summary.

Once the Worker completes its task, its entire context window is collapsed into a single high-signal summary (e.g., “Updated user.ts to use Zod validation; all tests passed”). The Orchestrator receives this summary, but the “noise” of the Worker’s implementation process (the file reads, the linter errors, the intermediate thoughts) is discarded.

Practical Example: A Complex Legacy Migration

Let’s look at how this solves a real-world problem. Imagine you are migrating a legacy Express.js backend from CommonJS to ESM and adding TypeScript.

The “Old Way” (Single Agent)

You start a session. The agent reads package.json, then app.js, then twenty middleware files. It starts renaming files to .ts. It hits a linter error. It tries to fix tsconfig.json. It forgets to update the imports in the tenth file. By turn thirty, the agent is looping on a circular dependency error it created in turn fifteen. The context is huge, messy, and the agent is “tired.”

The “One-Task” Way (Sub-Agent Pipeline)

You use an orchestrator to spin up a series of focused sub-agents:

Agent A (The Auditor): Task: Identify all CommonJS require calls and map them to ESM import. Output: A JSON map of necessary changes. (Context discarded after task).
Agent B (The Scaffolder): Task: Initialize tsconfig.json and install @types. Output: Environment ready. (Context discarded).
Agent C (The Component Worker): Task: Convert one specific controller file to TypeScript using the map from Agent A. Output: auth.controller.ts implemented. (One agent per file).
Agent D (The Verifier): Task: Run tsc on the specific file and fix type errors. Output: File verified.

By the time you get to the 50th file, the agent working on it has the same “energy” and “clarity” as the agent that worked on the 1st file. There is no cumulative fatigue.

Best Practices & Tips for High-Stakes Vibe Coding

To master this discipline, you must treat your agents as ephemeral resources. Here are the advanced rules for maintaining task purity:

1. The 500-Line Rule

Never ask a single worker agent to handle more than 500 lines of logic change in a single turn. If the task requires more, it is likely too complex and should be split into “Phase 1: Interfaces” and “Phase 2: Implementation.” Smaller tasks lead to fewer regressions.

2. Surgical Context Injection

Don’t let the agent “explore” the whole repository if it doesn’t need to. Use tools like grep_search to find exactly what is needed, then pass only those snippets to the sub-agent. If an agent is editing a UI component, it doesn’t need to see the database migration scripts.

3. The “Evidence Before Assertion” Protocol

A task is not “complete” because the agent says so. A sub-agent must provide evidence of success (terminal output, test results, or a screenshot) before it is allowed to terminate and report back to the orchestrator. This “Validation Gate” ensures that errors don’t leak from one task to the next.

4. Statis Verification

Before a sub-agent begins a task, it should verify the “Starting State.” If it’s supposed to fix a bug, it must first run a test that reproduces that bug. This ensures the agent is actually working on the problem it thinks it is, rather than hallucinating a fix for a problem that doesn’t exist.

5. Summary Compression

When a sub-agent finishes, don’t just “merge” its thoughts. Write a concise “Handover Note.”

Bad Summary: “I worked on the file and changed some things and it looks good.”
Good Summary: “Implemented getUsers endpoint in api.ts. Added JWT validation. Verified with curl. Note: Exported UserSchema for use in the frontend.”

Implementation Strategy: Setting Up the Handoff

How do you actually do this in your workflow? If you are using advanced CLI tools (like Gemini CLI or Claude Code), you can explicitly delegate tasks using sub-agent commands.

The Strategy Phase: Before writing any code, ask the agent: “Analyze this requirement and give me a list of 5-10 atomic tasks. For each task, define the ‘Input Context’ (which files to read) and the ‘Verification Criteria’ (how to prove it’s done).”

The Execution Phase: Execute the tasks sequentially. For each task:

Spawn a sub-agent (or start a fresh session).
Provide the “Handover Note” from the previous tasks.
Provide the specific file to be edited.
Require a “Success Evidence” report.

This creates a Stateful Orchestration with Stateless Execution. Your project state lives in your git repository and your documentation, while your “Intelligence” is applied in fresh, focused bursts.

Conclusion: The Path to Atomic Intelligence

The era of the “Generalist Agent” that lives in a single, massive chat thread is coming to an end for production-level development. As we move toward more complex, system-wide changes, the Discipline of One-Task-Per-Agent becomes the primary differentiator between hobbyist scripts and enterprise-ready software.

By decomposing your “Vibe” into atomic tasks, you protect the agent’s attention, eliminate context rot, and create a verifiable trail of high-quality code. It requires more discipline upfront—you have to think about how to split the work—but the result is a development process that is faster, safer, and infinitely more scalable.

In Vibe Coding, your most precious resource isn’t your API key or your GPU time. It is the Attention of the agent. Don’t waste it on a 200,000-token history of linter errors. Give every task the fresh start it deserves.