Why We Use Multiple LLM Agents Instead of One

A deep dive into our Technical Analyst → Risk Manager → Executor pipeline, and why separation of concerns matters in algorithmic trading.

The Single-Model Trap

When people first build LLM-powered trading systems, they typically do this:

prompt = f"Should I buy {pair} at {price}? Here are the indicators: {data}"
response = llm.ask(prompt)
if response == "BUY":
    execute_trade()

This has three fatal flaws:

1. No separation of analysis and risk — the same model that says "this looks good" also decides "how much to bet"
2. No accountability — when a trade goes wrong, you can't tell if the analysis was bad or the risk sizing was wrong
3. No learning — there's no structured way to review what went wrong

Our Solution: The Agent Pipeline

We split the decision into three distinct roles, each with a different model and different responsibilities:

Signal Generator (code) → Technical Analyst (LLM) → Risk Manager (LLM) → Executor (code)

Role 1: Technical Analyst

Model: Gemini 2.5 Flash (via OpenRouter)

Input: - 8 technical indicators (RSI, MACD, EMA, Bollinger, ATR, Volume, ADX, CMF) - Support/resistance levels - Market regime classification - Candlestick chart image (vision analysis) - Daily macro trend direction

Output: Structured JSON analysis

{
  "analysis": {
    "setup_type": "pullback",
    "trend": "bullish",
    "trend_strength": 0.72,
    "recommendation": "BUY",
    "confidence": 0.68,
    "entry_zone": {"low": 1.04, "high": 1.06},
    "stop_loss_suggestion": 1.02,
    "take_profit_suggestion": 1.15,
    "reasoning": "Price pulling back to EMA(21) support in a daily bullish trend..."
  }
}

Why Gemini? It has strong vision capabilities for chart analysis and is cost-effective (~$0.15/M tokens). For a bot that analyzes every 4 hours across 3 pairs, this keeps LLM costs under $1/month.

Role 2: Risk Manager

Model: Claude Sonnet 4 (via OpenRouter)

Input: - The Technical Analyst's full analysis - Current portfolio state (open positions, total risk) - Budget constraints (€83/pair, 2% max risk) - Market regime (trending/choppy/volatile) - Past trade reflections (lessons learned)

Output: Approve or Reject with position sizing

{
  "decision": "APPROVE",
  "risk_assessment": "medium",
  "position": {
    "entry_price": 1.05,
    "stop_loss": 1.02,
    "take_profit": 1.15,
    "quantity": 24.3,
    "risk_eur": 1.50,
    "risk_reward_ratio": 2.2
  },
  "warnings": ["Volume below average — monitor closely"]
}

Why Claude Sonnet? It excels at structured reasoning and following complex rules. Risk management requires careful calculation and constraint checking — Claude's strength.

Role 3: Trade Executor

Model: None. Pure deterministic code.

Responsibilities: - Validate the Risk Manager's position data - Check total risk budget (6% max concurrent) - Place market order via CCXT - Track the position (entry, SL, TP) - Monitor for stop-loss / take-profit hits

Why no LLM? Execution should be 100% deterministic. No creativity, no interpretation. If the Risk Manager approved it and the numbers check out, execute. Period.

The Veto Power

The Risk Manager can reject any trade. This is critical because:

• The Technical Analyst might be overly optimistic about a setup
• Market conditions might have changed since the analysis
• Portfolio risk might already be too high
• The daily macro trend might contradict the 4h signal

All rejections are logged with reasoning. The Self-Updater reviews these later to check if rejections were too conservative.

How Reflections Flow Back

After a trade closes (win or loss), the Self-Updater generates reflections:

Trade: SUI/USDT BUY → EXIT at stop-loss
P&L: -€1.50
Reflection: "Stop-loss was placed at 2.5× ATR but below a clear support level. 
             Price wicked 1% below the stop before bouncing. Consider wider stops 
             or visual stop placement near swing lows."

This reflection gets stored and injected into future prompts:

## Lessons Learned from Past Trades
- 🔴 [EXIT] Stop-loss was placed at 2.5× ATR but below a clear support level...
- 🟡 [RISK] In choppy markets, reduce position size by 50%...

Now the Technical Analyst knows to suggest visual stops near support levels, and the Risk Manager knows to reduce size in choppy conditions.

Why This Architecture Works

1. Separation of Concerns

Each agent has a single responsibility: - Analyst reads the market - Risk Manager protects the portfolio - Executor places orders

When something goes wrong, you know exactly which layer failed.

2. Model Specialization

Different models for different tasks: - Gemini for vision + pattern recognition - Claude for structured reasoning + constraint checking - No model for execution (deterministic code)

3. Auditability

Every decision is logged with: - Which agent made it - Which model was used - The full reasoning - Token usage and cost

This creates a complete audit trail for every trade.

4. Continuous Improvement

The Self-Updater closes the loop: - Reviews completed trades - Analyzes missed opportunities - Generates actionable reflections - Injects them into future decisions

The bot literally gets smarter over time.

Cost Analysis

For a bot running 24/7 with 4-hour analysis cycles:

That's about $0.50/month in LLM costs. The entire system runs on less than the cost of a single coffee per year.

What We Learned

Building a multi-agent trading system taught us:

1. LLMs are great at context, terrible at math — always validate calculations in code
2. Separation of concerns is even more important with LLMs — they're persuasive, so you need a separate risk layer
3. Reflections need to be specific — "be more careful" is useless; "require ADX > 25 for breakouts" is actionable
4. Missed opportunities matter — reviewing rejected trades is as important as reviewing executed ones
5. Cost is not a concern — with modern models, LLM-powered trading is surprisingly cheap

What's Next

• Live trading with real capital
• Adding a Sentiment Analysis agent for news/social data
• TradingView webhook integration
• Telegram alerts for trade notifications

This is part of the crypto-loco development series. Read the full project on GitHub.