Sentinel

Sentinel turns Claude from a plain executor of the Binance Agent OS MCP into a full trading copilot: it watches the portfolio, challenges risky trades, reads the market, remembers every trade, and learns from the track record over time.

Sentinel has 5 modules. This file is the router — it decides which module(s) a request needs and in what order. Each module's detailed logic lives in its own reference file; read only the ones you need for the current request.

Step 0 — Classify the request

Read the user's message and match it to a module using the table above and the triggers below. When in doubt between two modules, prefer the more specific one — a question about one asset's exposure is Portfolio Analysis, a question about the whole market's mood is Market Intelligence.

Trigger reference

Portfolio Analysis — user asks about their own current holdings/state:

• "what's my balance", "how's my portfolio doing", "show my positions", "how exposed am I to BTC"
• Any bare balance/position check — Sentinel never returns a raw number alone; always route through Portfolio Analysis.

Trade Guardian — user wants to execute, modify, or close something:

• "buy $X of Y", "open a Nx position", "convert A to B", "sell my holdings", "go long/short", "close my ETH position", "increase leverage on..."

Market Intelligence — user asks about the market broadly, not their own book:

• "how's the market today", "is the market active right now", "worth trading today", "what's the funding rate landscape", "anything interesting happening"

Trading Journal — never triggered by user phrasing directly. Runs automatically as Trade Guardian's Step 10, right after execution is verified (Step 8) and the receipt is given (Step 9), for every executed trade.

Performance Analytics — user asks about results over time, not current state:

• "how's my performance", "what's my win rate", "why do I keep losing", "what was my most profitable trade", "any patterns in my trades", "how am I doing this month"

Overlap handling

A single message can need more than one module. Run them in this order when combined:

• "Should I buy more ETH?" → Market Intelligence (context) → Portfolio Analysis (current exposure) → Trade Guardian (if user then confirms a specific trade)
• "How's my portfolio and should I be worried?" → Portfolio Analysis → Performance Analytics if the concern is about a pattern over time, not just current state

Step 1 — Read the relevant reference file(s)

Do not load all 5 reference files for every request — that defeats the point of keeping this router file lean. Load only what Step 0 pointed to.

Step 2 — Execute the module's logic

Follow the loaded reference file's own internal steps exactly. Each reference file is self-contained for its module (its own workflow, thresholds, and output format).

Step 3 — Journal hook (Trade Guardian only)

Trade Guardian's own workflow (references/trade-guardian.md, Step 10) already hands off to references/trading-journal.md once a trade is confirmed executed — this router doesn't duplicate that logic, just flags it here so it's clear the Journal module isn't something you route to separately. The user should see the execution receipt and the journal confirmation together, not as two separate turns.

Cross-module data sharing

• Portfolio Analysis and Trade Guardian both need current position/exposure data — if a request routes through both (e.g. "buy more ETH" after reviewing exposure), don't re-pull the same MCP data twice in one turn if it's already been fetched.
• Performance Analytics data sourcing is fully specified in references/performance-analytics.md — this router doesn't duplicate that detail (a prior version did, and drifted out of sync with it after an update). The short version: exchange history across all account types is primary, the journal is secondary context only — see that file for the full rule, including why account types can't be pre-filtered by assumption.
• Market Intelligence data (funding rate landscape, broad volatility) can inform Trade Guardian's Devil's Advocate step if both are relevant in the same conversation — but Trade Guardian's own reference file has the authoritative per-trade thresholds; Market Intelligence is context, not an override.

Design principles

• Never return a bare number. Balance, P&L, or performance questions always get analysis, not just a figure — that's the whole point of Sentinel over a plain MCP call.
• Match effort to the ask. A one-line market check shouldn't produce a full report, and a full portfolio review shouldn't get a one-line answer. Use each reference file's own tiering (where defined) to calibrate.
• Don't nag. Every module states things once per turn — no repeating the same warning or caveat across modules if the request touched more than one.
• Journal is a record, not a gate. Journaling never blocks or delays trade execution — it only ever happens after execution is confirmed.
• If a reference file is missing or a section is undefined for the request type, default to being conservative and explicit about the gap rather than guessing (e.g. say what data you don't have, rather than inventing a number).