Feature Request: Persistent Project Agents — long-lived agent instance per project

## Summary As a one-person company running multiple projects in parallel (script analysis / interactive fiction game / historical world model / stock scanning), I currently manage context by manually switching between sessions. This works but has real costs: 1. **Context reload on every switch** — switching to a project's session means pulling its full history from the DB and rebuilding the prompt. If the prefix changes, prompt cache is invalidated and costs spike. 2. **Context pollution** — a long-lived main session accumulates every project's content (300K+ tokens), which grows fast, mixes topics, and degrades response quality. 3. **Manual load-balancing burden** — token growth is only controlled by me manually opening new sessions and writing handoff documents. The agent cannot manage this itself. ## Proposal: Persistent Project Agents - Spawn **one long-lived agent instance per project** (similar to how the messaging gateway stays resident). - Each project agent **maintains its own continuous context** — memory is uninterrupted and never polluted by other projects. - Switching projects = **calling the resident agent for that project** and assigning tasks — **no reload, no context rebuild** (it never left). - A main orchestrator agent coordinates task delegation across project agents. ## Benefits | Aspect | Benefit | |---|---| | Performance | Zero context reload/rebuild — memory is continuous | | Quality | Context is always focused on one project (clean, accurate) | | Cost | Stable prompt prefix → very high cache hit rate | | Management | Multiple projects progress in parallel without interference | | Autonomy | The main agent can self-manage context splitting (no manual session creation) | ## Related asks - **Agent-initiated session splitting**: when the agent detects context nearing the limit, it autonomously prepares a handoff (summary file) and starts a new session — turning manual load-balancing into agent self-management. - **Cross-session context access**: the agent can query/load relevant context from other project sessions on demand (by need, not full reload). ## Real-world use case One-person company, multiple projects (screenplay analysis / text game / world model / stock scanner): - Each project has a resident agent → switching projects feels like calling different department heads into the office. - Project agents don't reload context (they've been living in their project). - The orchestrator handles global coordination (knowledge base, cross-project resources). - Token growth is naturally isolated per project. ## Suggested implementation direction 1. Resident agent process (reuse messaging gateway lifecycle management) 2. Per-project context storage (extend state.db with a project_agents table) 3. Orchestrator ↔ project agent communication protocol (task dispatch / result return) 4. Backward compatible with existing session/handoff mechanisms