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
Mental Model
Section titled “Mental Model”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.
What This Section Covers
Section titled “What This Section Covers”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.
Reconciliation, Risk & Exchange Consistency
Section titled “Reconciliation, Risk & Exchange Consistency”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.
Design Boundary
Section titled “Design Boundary”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 Agent | Algo Builder Agent |
|---|---|
| one instance per agent wallet | one instance per user |
| sessions are wallet-scoped trading runtimes | sessions are conversation views over a shared per-user memory FS |
| chat threads + autonomous alert threads | chat threads only |
| canonical runtime snapshot injected each turn | no per-turn live trading snapshot |
| sees one isolated agent-wallet HL account | sees the user’s portfolio of algo wallets |
| live discretionary entries, watcher pairs, time alerts | algo design + backtest + deploy + portfolio monitor |
| portfolio + per-market risk caps, drawdown penalty, lockout | no agent-layer risk caps |
| native built-in only — never exposed as an MCP surface | also reachable via Reversion MCP for external clients (Claude Desktop, Cursor, VS Code, …) |
Why The Discretionary Agent Is Not An MCP Surface
Section titled “Why The Discretionary Agent Is Not An MCP Surface”The discretionary agent is intentionally not published through Reversion MCP, and it never will be. Three reasons:
- Stateful by construction. MCP models tools as stateless function calls. The discretionary runtime is a continuous control loop with per-turn snapshot injection — open positions, in-flight orders, risk budgets, hedge ratios, lockout state. There is no clean way to expose that as N independent tools without lying about the state model.
- Trust boundary. A third-party MCP client must never receive a handle that can move real money or unwind hedges on a user’s behalf. The Algo Builder surface is read-mostly and scoped; the discretionary surface places live orders.
- The “tools” aren’t really tools. Inside the discretionary runtime, what looks like a tool call (e.g. open entry, update watcher, set time alert) is a subroutine of one big stateful agent that owns the wallet — not an independently invocable RPC.
If you are building external automation on top of Reversion, target the Algo Builder surface through Reversion MCP. The discretionary agent stays a native, in-platform feature.