Enhancing Spec Kit with Subagent Delegation for Better Context Management

[MAnders333]

The Problem

When using Spec Kit for agentic development workflows, the main agent executes all process steps sequentially. While this works, it leads to two key issues:

1. Context Pollution: The main agent's context window fills up with step-specific discussions, corrections, and refinements that aren't relevant to subsequent steps
2. Reduced Durability: Long-running sessions become less effective as the agent's context becomes cluttered with implementation details from earlier steps

The Solution

Delegate individual Spec Kit process steps to specialized subagents, using the generated Markdown artifacts as clean context handover mechanisms.

Key Benefits

1. Clean Context Handover: Each Markdown artifact contains only the essential context needed for the next step
2. Isolated Processing: Step-specific discussions, corrections, and iterations happen within subagent contexts
3. Main Agent Durability: The primary session maintains focus on orchestration and decision-making
4. Natural Boundaries: Spec Kit's structured approach provides clear delegation points

Implementation Approach

For each step of the process, generate not only a command but also a subagent; the command orchestrates the subagent while the subagent implementation contains the step-specific context.

Discussion

What are your thoughts on this approach? Have you experienced similar context pollution issues in your agentic workflows? How do you currently handle long-running
development sessions?

[harikrishnan83]

I have tried this and it works well. Here is the write up. Delegating to subagents also allows parallelisation.

[MAnders333]

hey @harikrishnan83,
interesting, but I think not exactly what I meant.
The idea is to not only leverage subagents during the implementation phase, but also for /specify, /clarify, /plan, ...
For each of these process steps, the agent will go through a bunch of tool calling, reasoning, and receive my reviews. All this back and forth could be captured within a subagents context so it does not pollute the main agent longterm.
For example, if I needed 2-3 revisions of the specs, by the time I want to /analyze, either the context window is already quite long or I have to start a new agent session / compact the history. Having the actual work done by subagents who report a summary to the main agent keep the primary agent clean and tight.

[harikrishnan83]

Hey @MAnders333 , good point. Yes, with subagents even I have been having the lost context issue. And yes what you are calling out can become an issue if you are dealing with large features. I was exploring Claude skills yesterday to see if that will help, does not look like it. The more practical alternative I am thinking is to break down larger features and use /specify, /plan, /tasks, ... cycle multiple times with each of them staying within context limits.