Thread context merging needs consideration

[dremnik]

Problem Statement

The Thread class currently handles context in a way that may lead to unexpected behavior when resuming threads or passing new values on successive runs.

Current Behavior

• Thread holds a context: Context<TContext> property initialized at construction
• When executing tools, a new Context is created each time (see executeTools in thread.ts:579)
• Context is persisted/updated during checkpoints, but the merge semantics are unclear
• On thread resume (hydration from storage), context comes from stored state

Open Questions

1. Context merging on resume: When a thread is resumed with new context values, what happens to existing context? Is it replaced? Merged? What are the semantics?

2. Per-run context updates: If a caller passes different context values on each execute()/stream() call, how should those interact with the thread's existing context state?

3. Tool execution context isolation: Currently a fresh Context is created per tool invocation (new Context(this.namespace, this.context.context)). Is this the right isolation boundary?

4. Checkpoint consistency: Context is persisted during checkpoints - if context mutates mid-tick, which version gets persisted?

References

• packages/kernl/src/thread/thread.ts - Thread class implementation
• Constructor: lines 127-158
• Tool execution context: line 579
• Checkpoint persistence: lines 393-430