Skip to content

Discretionary Agent

The Discretionary Agent is Reversion’s stateful realtime trading agent. It shares the baseline agent infrastructure with the Algo Builder Agent, but it owns a different runtime:

  • a live trading environment
  • session-scoped wallet and account state, 1-to-1 with an isolated agent wallet
  • autonomous alert threads
  • portfolio + per-market risk caps, drawdown penalty, and lockout enforcement
  • reconciliation and sync workers
  • discretionary-specific tools and python worker

Each discretionary agent instance is bound to a single agent wallet. That wallet’s HL portfolio is the agent’s full world: its positions, equity, risk caps, trading notes, watchers, time alerts, and market conditions are all isolated to that wallet.

Multiple discretionary sessions can exist per user — one per agent wallet. They never share state. This is the inverse of the algo builder agent, where one instance per user spans the full portfolio of algo wallets through a shared memory FS.

Within a single discretionary session, multiple threads share the live trading runtime:

  • chat threads — interactive user-facing conversations
  • alert threads — autonomous, short-lived turns spawned by triggered watchers, time alerts, or trade-management alerts

All threads in the same session see the same positions, account state, trade ledger, watchers, alerts, drawdown state, and notes. Conversation transcripts are isolated per thread.

How each discretionary turn is assembled from the session runtime, wallet-scoped state, canonical runtime snapshot, prompt layers, and discretionary tools.

How the live account panel works as a realtime projection of the agent’s trading environment using HTTP snapshot fetches, websocket invalidation events, and optimistic UI mutation.

How discretionary chat threads and alert threads share one session-scoped trading environment while keeping conversation history isolated per thread.

How watcher pairs and time alerts become autonomous alert-thread turns, including queueing, de-duplication, resume behavior, and frontend signaling.

How local runtime state, exchange sync, post-trade correction, and session-scoped risk controls stay aligned. Covers the portfolio cap, the per-market cap (configured as a percentage of the portfolio cap), drawdown penalty decay, and drawdown lockout.

The clean split is:

  • services/agent

    • shared websocket transport
    • shared turn engine
    • provider/model handling
    • generic algo-builder tool runtime (research / algo lifecycle / portfolio of algo wallets)
  • services/autodiscretionary

    • Hyperliquid bridge bound to one agent wallet
    • Redis-backed runtime state per session
    • alert lifecycle
    • reconciliation and sync workers
    • risk engine (portfolio + per-market caps, drawdown penalty, lockout)
    • discretionary tools
    • discretionary turn runner

So the discretionary agent is not a separate unrelated platform. It is a separate domain runtime built on top of the shared agent core, with a tightly-bounded one-wallet trading environment.

How It Differs From The Algo Builder Agent

Section titled “How It Differs From The Algo Builder Agent”
Discretionary AgentAlgo Builder Agent
one instance per agent walletone instance per user
sessions are wallet-scoped trading runtimessessions are conversation views over a shared per-user memory FS
chat threads + autonomous alert threadschat threads only
canonical runtime snapshot injected each turnno per-turn live trading snapshot
sees one isolated agent-wallet HL accountsees the user’s portfolio of algo wallets
live discretionary entries, watcher pairs, time alertsalgo design + backtest + deploy + portfolio monitor
portfolio + per-market risk caps, drawdown penalty, lockoutno agent-layer risk caps