A single goal handles a single task. Goal chaining connects multiple goals into workflows — where one goal's outcome triggers another goal's execution. Scan, analyze, execute, monitor, react — all automated.
[!NOTE] This feature was designed when older models had limited context capacity, requiring workflows to be split across multiple goals. With Sonnet 4.6 and Opus 4.6, a single goal can now handle an entire scan-analyze-execute workflow in one run. Most users today run one goal per trigger or asset. Goal chaining remains available for specialized cases — emergency exits, cross-asset coordination, and failure recovery — but is no longer required for typical trading workflows.
How Chaining Works#
Every goal can define three trigger connections:
Triggers point to other goals. When the condition is met, the target goal fires automatically.
Example: Scan → Analyze → Execute#
A three-step workflow for systematic market entry:
Goal 1: Market Scanner (ReAct mode)#
Scan all Hyperliquid perpetual markets. Identify the top 3 markets by ADX strength where ADX > 25 and a momentum setup is forming on the 15m timeframe. Return the symbols and their ADX values.
on_success → triggers Goal 2 with the scanner's output
Goal 2: Setup Analyzer (Graph-of-Thought mode)#
For each of the provided markets, evaluate three entry approaches: momentum pullback to EMA, breakout above recent high, and Bollinger Band squeeze breakout. Select the single best setup across all markets and approaches. Return the symbol, direction, entry price, stop-loss, and take-profit.
on_success → triggers Goal 3 with the analyzer's output
Goal 3: Trade Executor (Direct mode)#
Execute the trade: open a position on the specified symbol, direction, and size. Set the stop-loss and take-profit as provided. Use 3x leverage and 5% position size.
on_failure → triggers Goal 4
Goal 4: Notification (Direct mode)#
Send an alert that the execution failed. Include the error message and the intended trade details.
The scanner uses ReAct (expensive, iterative) because it needs to explore 50+ markets. The analyzer uses GoT (parallel evaluation) because it's comparing strategies. The executor uses Direct (fast, cheap) because the decision is already made. Each mode is used where it's strongest — see Reasoning Modes Explained and Comparing Reasoning Modes for a deeper look.
Fallback Logic#
Goal chaining isn't just for linear workflows. The on_failure trigger enables defensive strategies:
Primary + Fallback Strategy#
Goal A: Aggressive Momentum (CoT)
Enter BTC long when ADX > 30 and RSI is between 45-55 with price at the 21 EMA. 5% position, 3x leverage, 2:1 R:R.
on_failure → Goal B
Goal B: Conservative Trend Follow (CoT)
If the momentum entry failed (market too choppy), switch to a conservative approach: wait for a 4h EMA crossover on BTC. Enter with 3% position, 2x leverage, 3:1 R:R. Only trigger if 4h ADX > 20.
The primary strategy fires first. If conditions aren't right (ADX below threshold, no pullback, too volatile), it fails gracefully and the conservative fallback activates.
Risk Monitoring Chain#
Continuous Risk Monitor#
Goal: Risk Monitor (Direct mode, runs every 5 minutes)
Check current portfolio drawdown. If total unrealized + realized losses exceed 8% from daily peak, trigger emergency exit.
on_failure (drawdown exceeded) → Goal: Emergency Exit
Goal: Emergency Exit (Direct mode)
Close all open positions at market price immediately. Pause all other goals.
on_success → Goal: Alert
Goal: Alert (Direct mode)
Send notification: "Emergency exit triggered. All positions closed. Daily drawdown limit reached. Agent paused."
This creates an automated circuit breaker. The risk monitor runs on a 5-minute loop. If drawdown exceeds the threshold, it "fails" (by design), triggering the emergency exit chain. No human intervention needed.
Configuring Chains#
From the goal settings panel:
- Open the goal you want to chain from
- Navigate to the "Triggers" section
- Select the trigger type (on_start, on_success, on_failure)
- Choose the target goal from a dropdown of existing goals
- Optionally configure data passing (output from the source goal becomes input for the target)
Data Passing#
Chains can pass data between goals. The scanner's output (list of top 3 markets) becomes the analyzer's input. The analyzer's output (selected trade) becomes the executor's input.
This is handled automatically — the execution system captures each goal's output and makes it available to the next goal in the chain via the context window.
Chain Constraints#
- Max depth: 5 levels — Chains can go 5 goals deep. This prevents infinite chains.
- Circular reference prevention — If Goal A triggers Goal B on success, Goal B cannot trigger Goal A. The system detects and rejects circular references during configuration.
- Independent credit budgets — Each goal in the chain has its own credit allocation. An expensive ReAct scanner doesn't eat into the executor's budget.
When to Use Chains#
With modern model capacity, the use cases for chaining have narrowed to situations where a single goal genuinely can't cover the workflow:
Emergency exit circuits — A risk monitor goal that fires every few minutes and triggers a separate emergency exit goal on failure. The monitor and the exit have different lifecycles — one is periodic, the other is event-driven. This is still the cleanest pattern for automated circuit breakers.
Cross-asset coordination — When an event in one market should trigger analysis in another. A macro event scanner triggering per-asset analysis goals lets you fan out across multiple assets in parallel rather than processing them sequentially in one goal.
Failure recovery with different strategies — When the fallback approach is fundamentally different from the primary (different assets, different timeframes, different risk parameters). A conservative fallback goal with its own credit budget and reasoning mode is cleaner than branching logic inside one goal.
When Not to Use Chains (Most Cases)#
Single-asset strategies — One CoT or ReAct goal per asset handles the full scan-analyze-execute loop. This is how most users run their agents today. The model holds the entire workflow in context without losing coherence.
Scan-analyze-execute workflows — This was the original showcase for chaining (ReAct scanner → GoT analyzer → Direct executor). With Sonnet 4.6 and Opus 4.6, a single goal handles this in one pass. Breaking it into three goals adds configuration overhead and latency between steps with no quality gain.
Low-frequency trading — A single CoT goal running on a schedule covers daily or weekly strategies without chaining.
Most users should start with one goal per trigger or asset. Only add chaining when you hit a specific limitation that a single goal can't solve.
Goals can trigger other goals via on_start, on_success, and on_failure. Originally essential for multi-step workflows, chaining is now optional for most strategies thanks to expanded model context. Use it for emergency exits, cross-asset coordination, and failure recovery.
