Multi-Thread Runtime Architecture

This page documents the discretionary agent’s multi-thread architecture.

Thread Model

The discretionary agent has two thread types:

• chat threads
• alert threads

Chat threads

• user-facing
• manually created
• can persist over long periods
• accept queued user messages during active turns

Alert threads

• autonomous
• spawned by watcher, time, or trade-management alerts
• short-lived operational turns
• use alert payload plus embedded context as their briefing

Shared vs Isolated State

Shared within a discretionary session

All threads inside the same discretionary session share:

• positions
• trade ledger
• portfolio risk
• notes
• price watchers
• time alerts
• market conditions
• live prices
• drawdown state
• local account state

Isolated per thread

Each thread keeps its own:

• transcript history
• streaming turn buffer
• queued messages
• title / summary / status

So the architecture is:

• session-scoped trading environment
• thread-scoped conversation history

Runtime Scope

The session-scoped runtime identity is:

session:${sessionId}

This is what makes multiple discretionary agent accounts per user possible without state collision.

Queueing Model

Only one active turn runs per thread.

If a user sends another message while the thread is running:

• it is appended to the thread queue
• frontend shows it in queue state
• after turn completion, queued messages are combined and executed in order

This keeps thread execution deterministic while still supporting fast user interaction.

Concurrency Model

Concurrency rules are:

• many discretionary sessions can exist per user
• each session has its own runtime scope
• each session can have many threads
• each thread runs one turn at a time
• many threads can be active across different sessions

This is what enables multi-agent-per-user operation without cross-account pollution.