Understanding Agent Execution: From Prompt to Trade

A user writes a goal in plain English. Minutes later, a perpetual futures position opens on Hyperliquid. Here's every step in between.

The Pipeline#

Step 1: Goal Definition#

The user writes a natural language goal:

"When BTC funding rate exceeds 0.03%, go short BTC-PERP with 2x leverage, 5% of portfolio. Take-profit at 2%, stop-loss at 1%."

This is stored as a goal object attached to the agent. The goal has a trigger condition (funding rate threshold), an action (short BTC), and risk parameters (leverage, size, TP/SL).

Step 2: Trigger Evaluation#

The goal scheduler evaluates triggers continuously. Trigger types:

• Time-based — Run every N minutes (cron schedule)
• Event-based — Fire when a market condition changes (price cross, indicator threshold)
• Chart triggers — Fire on technical events (MACD crossover, RSI threshold, ADX breakout, FVG formation, CHoCH detection)
• Chain triggers — Fire when another goal succeeds or fails

The scheduler checks: is the funding rate above 0.03%? If no, skip. If yes, the goal fires.

Step 3: Context Assembly#

Before the AI model sees the goal, the system assembles context:

• Market data — Current price, recent candles, volume, order book depth
• Position state — Existing open positions, unrealized PnL, margin utilization
• Account state — Available balance, credit budget remaining, daily trade count
• Tool descriptions — What tools the agent can call (market data, order placement, position management)
• Historical context — Recent goal executions and their outcomes

This context window is what the AI model receives alongside the goal prompt.

Step 4: AI Reasoning#

The AI model processes the goal + context through the selected reasoning mode:

Direct — Single pass, immediate decision. "Funding is 0.035%, above threshold. Executing short."

Chain-of-Thought — Step-by-step analysis. "Funding is 0.035%. Let me check the trend direction. BTC is in an uptrend on 4h — shorting against the trend carries higher risk. However, extreme funding rates historically mean-revert. The risk/reward is acceptable given the stop-loss. Executing short."

Graph-of-Thought — Parallel strategy evaluation. Evaluates multiple approaches (short immediately, wait for higher funding, hedge with a different pair) and selects the strongest branch.

ReAct — Iterative observe-reason-act loops. Observes funding, reasons about trend, acts by checking order book depth, observes liquidity, reasons about slippage, acts by adjusting position size, then executes.

Step 5: Tool Selection#

The AI model decides which tools to call and with what parameters:

1. get_funding_rate(symbol="BTC-PERP") → Returns 0.035%
2. get_account_balance() → Returns $10,000 available
3. calculate_position_size(portfolio_pct=0.05, leverage=2) → Returns $1,000 notional
4. place_order(symbol="BTC-PERP", side="sell", size=$1000, leverage=2, type="market")
5. set_stop_loss(position_id=X, price=entry*1.01)
6. set_take_profit(position_id=X, price=entry*0.98)

Each tool call is validated by the execution layer before it runs.

Step 6: Execution Validation#

Before the order hits Hyperliquid, the execution layer validates against the agent's risk parameters:

• Position size within limits? (5% of $10,000 = $500 base, $1,000 with 2x leverage) ✓
• Leverage within cap? (2x ≤ 5x max) ✓
• Max concurrent positions not exceeded? (0 open < 3 max) ✓
• Daily trade limit not hit? (0 today < 10 max) ✓
• Credit budget sufficient? ✓
• Cooldown period elapsed? ✓

If any check fails, the trade is blocked and the agent receives an error message explaining why.

Step 7: Order Submission#

The validated order is submitted to Hyperliquid via the execution layer:

1. Order constructed with Hyperliquid's API format
2. Signed with the user's authenticated session
3. Submitted and awaiting fill confirmation
4. Fill received with execution price, size, and fees

The entire submission happens in under 200ms.

Step 8: Position Management#

Once filled, the position manager:

• Tracks the open position with real-time PnL
• Monitors stop-loss and take-profit levels
• Updates account state (margin utilization, available balance)
• Logs the decision, reasoning chain, and execution details

Step 9: Real-Time Updates#

The result propagates to every connected client via PubSub → Socket.IO:

1. Backend publishes position update to Redis PubSub
2. Socket.IO server receives and broadcasts to connected clients
3. Frontend SocketProvider receives the event
4. Dashboard, portfolio, and terminal components update in real-time

The user sees the new position appear on their dashboard within seconds of execution.

Infrastructure: BullMQ Processing#

Goal execution doesn't happen on the web server. It's processed by distributed BullMQ workers:

1. Goal triggers → Job is enqueued to the goal execution queue
2. Worker server picks up the job → One of N horizontal workers processes it
3. Distributed locking prevents the same goal from executing simultaneously on multiple workers
4. Checkpoint recovery — If a worker crashes mid-execution, the job resumes from its last checkpoint instead of restarting

This architecture means thousands of agents can fire goals simultaneously without queueing behind each other. Each worker processes independently.

What Gets Logged#

Every execution creates a permanent record:

• Goal ID and trigger that fired
• Full reasoning chain (the AI's analysis)
• Tool calls made with inputs and outputs
• Risk parameter checks (passed/failed)
• Order details (symbol, side, size, price, fees)
• Execution timestamp and duration
• Credit cost of the entire run

This log is searchable, filterable, and exportable. When an agent makes a questionable trade, you can trace exactly why — from trigger to reasoning to execution.

---

From natural language goal to executed trade: trigger evaluation, context assembly, AI reasoning, risk validation, order submission, and real-time updates. Every step logged, every decision traceable.