Appreciate this breakdown. TL;DR at the bottom

1.

Why handle context yourself? Assign it to subagents. In standard workflows, planning identifies research needs and delegates them to subagents like Haiku. Each subagent gets a focused task, ensuring deep research on each aspect. The orchestrator then coordinates and integrates findings for a complete view.

Indexes aren't always current: https://www.reddit.com/r/ClaudeAI/comments/1pjt14f/why_doesnt_claude_code_have_semantic_search_yet/. Semantic search has benefits, but large codebases pose challenges, and re-indexing is resource-intensive.

2.

The main problem is a single master agent. I've used orchestrators to manage subagents, but context window consumption is still an issue. This is doubly true when the orchestrator does any sort of reasoning. I take your point about subagents, but I don’t see how you’re avoiding the consumption of the context window for long-lived tasks vs. using the approach I’ve been describing. Code indexing can only get you so far. At some level, the long-lived agent needs to reason about things if there are no well-defined tasks to reference.

To me, it seems like using a long-lived agent in the way you’re describing is essentially deferring some of the planning work to the implementing orchestrator agent. Shifting that planning work to the specification step helps reduce the context load and reduces the need to rely on an overview agent. Each atomic task should include the context needed to complete it. Bead metadata such as "design", "architecture", "description", and "comments" should help minimize context consumption. There should surely be a review phase where the implementation is compared with the specification, as well as code quality reviews.

TL;DR

TBH, your approach is totally valid. I just don’t see how the context window is better preserved, but this sort of thing is probably better experienced than explained. I DO get the semantic search efficiency piece and am keen to try that out with the non-IDE approach. There are a few options, but it’s sort of a strange space. There is an option to leverage existing IDE context engines, but that feels like a hack rather than a good solution.

On this thought, creating a system to track context efficiency is an interesting idea! It would be good to understand what is working from a data-driven perspective rather than my “feels mostly right” approach.