Alert Lifecycle & Autonomous Threads

This page documents how the discretionary agent turns a saved watcher or timer into an autonomous alert-thread turn.

Why Alert Threads Exist

The discretionary runtime separates:

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

That allows one agent account to maintain:

• normal user chat threads
• autonomous alert threads spawned by market watchers or time alerts

Alert threads exist so the runtime can react to a trigger without polluting the user’s main chat thread.

Main Components

• backend/services/autodiscretionary/tools/alert-tools.ts
• backend/services/autodiscretionary/alert-consumer.ts
• backend/services/autodiscretionary/turn-runner.ts
• backend/services/autodiscretionary/thread-runtime-state.ts

Lifecycle

1. Alert is created

The agent creates a watcher pair or time alert through the discretionary tool layer.

2. Trigger is detected

The bridge or scheduler detects that the condition has fired and enqueues alert work.

3. Alert consumer arbitrates work

The consumer de-duplicates, enforces concurrency limits, and decides whether to create, resume, retry, or re-queue work.

4. Alert thread is run

The discretionary turn runner prepares the same session-scoped trading environment and runs the shared agent loop on the autonomous thread.

Frontend Implications

The frontend treats alert threads as a separate panel because they are not the same UX object as chat threads.

Important distinction:

• chat threads are user-driven conversations
• alert threads are runtime-driven conversations