Skip to main content

Mercury v2

· 5 min read
Max Kaido
Max Kaido
Architect

Below is a minimalistic system design for a trading engine that leverages two AI models (“cheap” and “expensive”) within a positive feedback loop. This system stores decision history, orders, and trade data, and can iteratively learn from its own performance. The design is intentionally simple and modular.

1. Core Objectives​

  1. Use Two AI Tools

    • Cheap AI (small context window, faster, limited depth).
    • Expensive AI (long context window, more detailed, higher cost).

  2. Repeatable Job

    • Periodically generates summaries (like the trading/portfolio overviews).
    • These summaries feed the AI models.

  3. Decision History & Learning

    • All decisions (recommendations, orders, etc.) and their outcomes must be recorded.
    • The system reuses these records as feedback to refine future decisions.

  4. Minimal & Elegant

    • Small set of components.
    • Light data records for cheap AI.
    • Possibly fuller data records for expensive AI.

  5. Positive Feedback Loop

    • The system aims to optimize selected metrics (e.g., profitability, risk-adjusted returns).
    • Over time, the engine uses feedback to adjust trading strategies.

2. High-Level Flow​

Explanation of Flow​

  1. Job Scheduler triggers a Data Aggregator periodically (e.g., every X hours).
  2. Data Aggregator collects all relevant data:
    • Market data, portfolio data, technical signals, previous decisions, performance metrics, etc.
    • Summaries are tailored for each AI’s context window:
      • Cheap AI gets a concise state (e.g., short bullet points, minimal numeric detail).
      • Expensive AI can handle richer data (deeper historical context, broader numeric detail).
  3. Data Store is a simple database or even a structured file system storing:
    • Trade/Order history
    • Decision logs (what was recommended, by which AI, with which parameters)
    • Performance outcomes (PnL, drawdown, etc.)
    • System states (market data snapshots, fundamental data, etc.)
  4. Decision Maker is a logic layer that:
    • Chooses whether to call the cheap AI or the expensive AI (based on conditions like time constraints, cost, or need for deeper analysis).
    • Passes the correct summary (short or long) to the chosen AI.
    • Receives the AI’s recommended trades or position management steps.
  5. Trading Engine:
    • Validates or refines AI outputs (e.g., checks max risk, ensures it obeys basic rules like “max 30% of USDT per asset”).
    • Submits or modifies orders in the Execution Layer (API calls to exchange/broker).
  6. Order & Trade History is continuously updated.
  7. Feedback & Learning Module:
    • At each iteration, it compares the AI’s decisions vs. actual performance (profit/loss, risk metrics).
    • Summarizes results into a minimal record (for cheap AI) or a more complete record (for expensive AI).
    • Flags major divergences or issues to refine policy/rules.
  8. The positive feedback loop occurs as each iteration’s decisions feed future analysis, adjusting AI prompts or internal system parameters.

3. Components Breakdown​

3.1 Job Scheduler​

  • Function: Triggers the entire pipeline (e.g., every 15 minutes or hour).
  • Minimal Implementation: Cron job or background service with a single scheduler_task() function that calls the aggregator.

3.2 Data Aggregator​

  • Function: Collects:
    1. Market Data (live quotes, order book snapshots).
    2. Portfolio & Position Data (current holdings, open positions, PnL).
    3. Order & Trade History (from the Data Store).
    4. Decision Logs (previous AI decisions, outcomes).
  • Output: Two structures:
    • cheap_summary (highly compressed; fewer data points).
    • expensive_summary (full detail; deeper time range).

3.3 Data Store​

  • Function: Minimal DB or file system.
  • Key Tables/Collections:
    1. Trades (symbol, side, quantity, price, timestamp, resulting PnL).
    2. Decisions (which AI made a recommendation, what was recommended, final action).
    3. Performance (KPIs: total PnL, drawdown, success rate, etc.).
    4. System States (snapshots of aggregator data, if needed for the expensive AI).
  • Minimal Implementation:
    • Could be SQLite with 3–4 tables or even a set of JSON files with consistent structure.

3.4 Decision Maker​

  • Function: Decides:
    1. Which AI to invoke (cheap vs. expensive).
    2. How to structure the prompt.
    3. When to skip or do partial updates.
  • Logic:
    • Example condition: “If it’s daytime and I have enough resources, use the expensive AI; otherwise, use cheap AI.”
    • Or “Use cheap AI for incremental updates every 15 minutes, expensive AI once daily for deeper analysis.”

3.5 AI Modules​

  • Cheap AI:
    • Input: cheap_summary (small context).
    • Output: Quick recommendations (e.g., short triggers, basic TPs/SL).
  • Expensive AI:
    • Input: expensive_summary (long context).
    • Output: More elaborate strategy (multi-timeframe analysis, advanced hedging, etc.).

3.6 Trading Engine​

  • Function:
    • Receives recommended trades from the chosen AI.
    • Applies rule checks (max 30% allocation, total 80% exposure limit, etc.).
    • Creates final orders (limit or market).
  • Output: Actual orders placed via an Execution Layer (exchange or broker API).
  • Minimal Implementation:
    • Could be a single function that merges AI output with rules and then calls placeOrder(...) for each new trade.

3.7 Order & Trade History​

  • Function: Logs everything in the Data Store.
  • Minimal Implementation:
    • Straight inserts into the “orders” or “trade history” table whenever a new order is placed or filled.

3.8 Feedback & Learning Module​

  • Function:

    • Monitors how each recommended action performed (TP hits, SL hits, PnL, etc.).
    • Produces a short summarized “lesson learned” record:
      • “The short on BTC at $95k triggered a stop loss at $98k. Next time, incorporate new data about short squeezes.”
    • Stores these lessons in DB.
    • On subsequent runs, these lessons can be appended to the aggregator’s output.

  • Positive Feedback Mechanism:

    • The cheap AI sees a minimal summary of recent lessons in its prompt to gently steer short-term refinements.
    • The expensive AI sees the more complete feedback logs in order to more substantially adjust the strategy.

4. Minimal “Decision History” Handling​

  1. Each Decision is an entry with:

    • Timestamp
    • AI Used (cheap or expensive)
    • Prompt (optional, or a truncated version for references)
    • Recommended Actions (Buy/Sell, price, risk parameters)
    • Final Execution (actual order placed or not)

  2. Each Outcome references the Decision ID and logs:

    • Actual Fill (price, time)
    • PnL (if closed)
    • Hit TP/SL

  3. Periodic Summaries incorporate these outcomes back into aggregator data.

5. Minimal & Elegant Design Principles​

  • Small Number of Components: A single aggregator for data input, two AI “endpoints” (cheap and expensive), one decision maker, one trading engine, and a single store.
  • Lightweight Summaries: Summaries are tailored to each AI’s capacity. No large prompts for the cheap AI.
  • Simple Learning: A basic “lessons” table or JSON. Next aggregator run appends it to the AI prompt in a condensed manner.
  • Positive Feedback: Over time, the system sees which trades performed well, keeps a record of success/failure, and adapts.

6. Example Pseudocode (High-Level)​

function scheduler_task():
    data = collect_market_data()
    portfolio = get_portfolio_state()
    history = get_recent_order_trade_history()
    feedback = get_lessons_summary()

    cheap_summary = summarize_for_cheapAI(data, portfolio, history, feedback)
    expensive_summary = summarize_for_expensiveAI(data, portfolio, history, feedback)

    chosenAI = pickAI(cheap_summary, expensive_summary)  # decides cheap vs. expensive

    if chosenAI == 'cheap':
        recommendation = cheapAI_inference(cheap_summary)
    else:
        recommendation = expensiveAI_inference(expensive_summary)

    final_orders = apply_risk_rules(recommendation, portfolio)
    place_orders(final_orders)

    record_decision_in_db(recommendation, final_orders)
    # subsequent execution updates trade outcomes

    analyze_outcomes_update_lessons(final_orders)

7. Conclusion​

This minimalistic architecture supports:

  • Periodic Summaries (repeatable job).
  • Two-tier AI approach (cheap & expensive).
  • Decision History with learning (feedback loop).
  • High-Level Trading Rules (exposure limits, risk constraints).
  • Positive Feedback refining results over time.

By keeping the design small—one aggregator, one store, two AI endpoints, a simple decision maker, and a feedback loop—the system remains elegant yet meets all specified requirements.