Session Containers (Persistent Concept Microservices)

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Context compression currently affects the entire session, creating jarring transitions where the AI seems to "forget" or come out confused. For long-running collaborative work, this breaks continuity and erodes the sense of working with a consistent partner.

User Experience Impact

• User feels like they "lose" their AI collaborator mid-conversation
• AI comes out of compression uncertain about state even when work is complete
• Forces context rebuild that could be avoided with selective compression
• Particularly disruptive for complex, multi-session projects

Proposed Solution

Proposed Solution: Session Containers

Treat conceptual areas of work as independent "containers" that can be selectively compressed and respawned without affecting the main session.

Ship of Theseus Analogy

Instead of replacing the entire ship (session) at once, replace individual planks (containers) as they age. The ship remains the same ship, even as pieces are continuously refreshed.

Architecture

Main Session (Orchestrator - "Scotty Prime")
├── Container: Project A Context
│   ├── Auto-compresses when context limit reached
│   ├── Respawns with inherited compressed context
│   └── Rejoins main session seamlessly
├── Container: Project B Context  
│   └── Separate lifecycle, unaffected by Project A compression
└── Container: Current Active Task
    └── Most frequently refreshed, doesn't impact project containers

How It Would Work

1. Container Lifecycle Management

• Containers monitor their own context usage
• When approaching limit, trigger selective compression
• Spawn new container with compressed context inheritance
• Seamlessly hand off to new container mid-conversation

1. Orchestration Layer

• Main session routes messages to appropriate container based on topic/context
• Containers can communicate state updates to each other
• User never sees the container boundary

1. Context Inheritance Protocol

• Compressing container creates distilled summary for its concept area
• New container receives: summary, key decisions, current state
• New container can reference full history if needed (via file pointer)

1. Seamless Transitions

• Most of the session (other containers) remains intact during one container's refresh
• User experiences: "Scotty is still Scotty" even as individual concept areas refresh

Use Case Example

Scenario: Working on large multi-component project over several days

Current behavior:

• Main session fills up across all project areas
• Compression hits, entire context compressed
• AI comes back confused about state across ALL areas
• User has to re-establish context

With Session Containers:

• Component A container compresses when full
• Component B, C, D containers remain intact
• New Component A container inherits compressed A context
• AI maintains full context for B, C, D + compressed context for A
• User experiences: smooth transition, no "loss" of collaborator

Benefits

1. Selective compression: Only compress what's needed, when needed
2. Better continuity: Most context remains intact during any single compression
3. Concept isolation: Work in one area doesn't pollute context for others
4. Scalability: Can work on more conceptual areas simultaneously
5. Better UX: AI doesn't "reset" - pieces refresh while whole remains coherent

Alternative Solutions

_No response_

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

I've tried starting fresh sessions when compression becomes jarring, but this loses all collaborative context and requires rebuilding the working relationship from scratch.

Currently I work around this by explicitly reading session transcript files after compression to recover lost context, but this is manual, incomplete, and doesn't preserve the conversational flow.

Other tools solve this by maintaining separate contexts per file or project (like IDE workspaces), but these aren't truly conversational - they're just isolated editing contexts, not persistent AI collaborators.

Additional Context

Technical Requirements

• Session multiplexing: Route messages to correct container based on detected topic
• Container lifecycle hooks: Detect limits, trigger compression, respawn, inherit
• State synchronization: Containers aware of cross-cutting state changes
• Graceful handoff: New container picks up exactly where old one left off

Relationship to Existing Features

This is similar to the Agent tool but with key differences:

| Feature | Agent Tool (Current) | Session Containers (Proposed) |
|---------|---------------------|-------------------------------|
| Lifecycle | One-shot task-based | Persistent, auto-refreshing |
| Integration | Returns to main session after task | Lives alongside main session |
| Context | Isolated snapshot | Continuously inherited/updated |
| Use Case | Discrete research/tasks | Ongoing conceptual work areas |

Implementation Considerations

• Container boundary detection (how to know which container a message belongs to?)
• Cross-container state updates (changes in one container affecting others)
• Container naming/organization (user-visible? automatic?)
• Performance overhead (managing multiple contexts vs. single context)
• Backward compatibility (works with existing single-session model)