Market Monitor (Multi-Agent Market Intelligence Network)

Role: Solo, end-to-end
Tech Stack: Python 3.12+, Anthropic Claude, PostgreSQL 16, InspIRCd, Docker Compose, asyncio
Repository: Private. Demo available on request

Overview

Market Monitor is an adaptive intelligence system for monitoring rare earth and critical minerals markets. Three independently deployable services share state through PostgreSQL and narrate what they’re doing over an IRC server: a collector gathers market data, an intelligence service detects anomalies and runs investigations, and a trader executes paper options trades based on system signals.

The system adapts its behavior in real time. When the sentinel detects an anomaly, it escalates monitoring intensity, polling frequency goes up, investigation hypotheses are generated, and the LLM gets pulled in for multi-pass analysis. Calibration happens continuously rather than in a special phase: every 6 hours the chronicler checks resolved events against their predictions and computes the error, and a weekly review grades each trading strategy A through F, adjusting a confidence scalar the trader applies at trade time.

System Architecture

Three Docker services, loosely coupled through a shared PostgreSQL database, with IRC channels for live narration:

graph TD
    subgraph "metals-collector"
    A[yfinance Poller] -->|prices| D[(PostgreSQL)]
    B[Finnhub + RSS News] -->|articles| D
    end

    subgraph "metals-intelligence"
    D --> E[Sentinel]
    E -->|anomaly detected| F[Researcher]
    F -->|hypothesis-evidence loop| G[Converged Investigation]
    D --> H[Chronicler]
    H -->|event synthesis| D
    H -->|resolution tracking| D
    D --> I[Digest]
    end

    subgraph "metals-trader"
    G -->|trade signal| J[Trade Evaluator]
    E -->|critical alert| J
    J -->|LLM evaluation| K[Strategy Selector]
    K --> L[Paper Execution]
    L -->|P&L tracking| M[Performance Analyzer]
    M -->|calibration feedback| D
    end

    N[IRC Server] <-.->|all services| D

IRC Channels: #prices #news #alerts #digest #chronicle #investigate #trades #ops

How It Works

1. Escalation State Machine

Markets are noisy. Monitoring everything at high intensity wastes API calls and LLM tokens. But under-monitoring during a genuine event means missing the signal entirely. So I built a four-level state machine that adapts monitoring intensity based on computed escalation scores.

LevelPrices PollNews PollLLM Usage
Normal15 min30 minNone
Elevated5 min15 minHypothesis generation
Intensive2 min10 minFull scenario modeling
Retrospective15 min30 minAssessment only

Transitions are driven by alert severity and a composite escalation score. The system decays back to normal after 8 hours of calm, or automatically enters retrospective after 48 hours at intensive.

2. Multi-Turn Investigation Engine

A single LLM call can’t reliably diagnose a market anomaly. It needs to gather evidence, test hypotheses, and refine its assessment iteratively, same way an analyst would. So I built a hypothesis-evidence loop that runs until convergence.

  • The researcher generates 2-4 distinct hypotheses explaining the anomaly.
  • Each iteration queries the database for evidence: price patterns, news search, historical event comparisons, volume analysis.
  • The LLM updates probability estimates based on new evidence. Hypotheses below 10% get eliminated; above 70% are marked as leading.
  • Convergence happens when a leading hypothesis exceeds 70% confidence or all but one are eliminated (max 3 iterations for elevated, 5 for intensive).
  • The concluded investigation generates bull/base/bear scenarios with specific price predictions and validation signals.

3. Calibration Feedback Loop

LLM confidence scores are often poorly calibrated. A model that says “80% confident” isn’t right 80% of the time, which is a problem if you’re sizing positions based on that number. So I built a closed-loop system that tracks prediction accuracy and adjusts future behavior.

  • The chronicler synthesizes significant market events weekly and tracks them with predicted impact.
  • Every 6 hours, resolution tracking compares current conditions to predictions and calculates prediction error.
  • The trader’s weekly performance review grades each strategy (A/B/C/D/F) and feeds accuracy metrics back into the system’s confidence scalar.
  • Future position sizing and investigation depth are influenced by historical calibration performance. The system learns to trust itself less when it’s been overconfident.

4. Paper Options Trading

Testing market intelligence quality means putting it into action, but with real money at risk you can’t iterate freely. Paper trading with confidence-scaled position sizing and strict risk management lets me actually measure the system.

  • Four strategies matched to signal type: 0DTE momentum (high conviction), weekly directional, event straddles (uncertainty plays), and investigation-based spreads.
  • Position sizing scales with confidence tier: high (3-5% portfolio), medium (1.5-3%), low (0.5-1%).
  • Circuit breakers: 20% drawdown limit, 10% daily risk cap, 8 concurrent position maximum, 0.40 confidence floor (0.60 for 0DTE).
  • Simplified delta + theta premium model for paper-trade P&L, deliberately not full Black-Scholes.

5. IRC as Live Narration

Postgres is the actual data bus; the services coordinate through the database. IRC is the narration layer on top, the part that makes the system observable in real time, and yes, it’s a little unusual, but it’s perfect for this.

  • Each service is an IRC bot that emits structured messages to topic-specific channels. The only inbound handling is a human command; services don’t talk to each other over IRC.
  • A human operator can join with any IRC client (WeeChat, irssi) and watch the system in real time, reading investigations as they converge, watching trades execute, monitoring escalation transitions.
  • All state persists in PostgreSQL. IRC is ephemeral communication, so services can restart independently without losing data.

Testing

1,000+ tests across 42 files following strict TDD (red-green-refactor). Tests mirror the source structure: tests/sdk/, tests/agents/, tests/backtest/, tests/dashboard/, tests/scripts/.

Tech Stack

  • Language: Python 3.12+, asyncio
  • AI/LLM: Anthropic Claude (investigations, synthesis, trade evaluation, calibration)
  • Database: PostgreSQL 16 (asyncpg), 361-line schema
  • Communication: InspIRCd IRC server (Docker)
  • Market Data: yfinance (OHLCV), Finnhub (news), Google News RSS
  • Validation: Pydantic v2
  • Infrastructure: Docker Compose (6 services by default: InspIRCd, PostgreSQL, the three agents, and a dashboard; Metabase behind an optional profile), YAML-driven configuration
  • Testing: Pytest (1,000+ tests, 42 files, TDD)