[Feature Request] Pluggable ML Signal Providers + Broker Execution Interface

Hi TradingAgents team,

I've been building an automated trading pipeline with a goal similar to TradingAgents, but using a hybrid ML/LLM architecture.

My current architecture is roughly:

Market / News Data ↓ BERT-based classifier ↓ Structured ML signals ↓ Gemini ↓ Schema-constrained JSON decision ↓ Deterministic validation / risk layer ↓ Alpaca ↓ Order execution

After looking through TradingAgents, I think there may be an interesting opportunity to make two boundaries in the framework more extensible:

1. External / non-LLM signal providers

2. Broker execution adapters

3. Pluggable ML Signal Providers

TradingAgents currently has specialized LLM-powered analysts, including the Sentiment Analyst.

Rather than replacing that architecture, I think it could be useful to allow optional external ML models to contribute structured signals.

For example, a FinBERT/BERT-style classifier could emit:

{ "source": "finbert", "symbol": "NVDA", "signal_type": "sentiment", "score": -0.72, "confidence": 0.91, "timestamp": "..." }

Other providers could potentially emit technical, fundamental, macro, or custom quantitative signals using the same interface.

Conceptually:

         ┌─ Sentiment Analyst (LLM)
         │

Market Data ─┼─ FinBERT / BERT │ ├─ Quant Model │ └─ Custom User Model ↓ Normalized Signal Schema ↓ TradingAgents ↓ Bull / Bear Debate ↓ Trader

This could allow users to combine deterministic/specialized ML models with TradingAgents' LLM reasoning instead of requiring every analytical step to be performed by an LLM.

It may also improve reproducibility for tasks such as sentiment classification, where a specialized classifier can provide a stable numeric signal.

1. Broker Execution Interface

Another useful abstraction might be separating the final portfolio decision from execution.

Currently, TradingAgents produces the final trading decision inside the framework.

An optional execution interface could look conceptually like:

class BrokerAdapter: def submit_order(self, order): ... def cancel_order(self, order_id): ... def get_positions(self): ... def get_account(self): ...

Implementations could then include:

BrokerAdapter ├── SimulatedBroker ├── AlpacaPaperBroker └── CustomBroker

I would strongly suggest starting with paper trading only, rather than enabling live execution by default.

1. Deterministic Risk Gate

One reason I use this architecture is that I don't want the LLM to have unrestricted authority over the brokerage account.

The LLM produces a structured proposal:

{ "symbol": "NVDA", "action": "BUY", "confidence": 0.78 }

But deterministic code decides whether that proposal is executable:

TradingAgents Decision ↓ Schema validation ↓ Allowed symbol? ↓ Position limit? ↓ Daily loss limit? ↓ Exposure limit? ↓ Duplicate order? ↓ Market / liquidity checks? ↓ BrokerAdapter

In other words:

LLM / ML models propose. Deterministic code authorizes. Broker adapter executes.

I think keeping these responsibilities separate could be valuable if TradingAgents eventually supports external execution.

Possible Integration

Putting the pieces together:

External Data ↓ ┌─────────────────────┐ │ TradingAgents │ │ Analysts │ │ │ │ + External Signals │ ← BERT / FinBERT / Quant models └──────────┬──────────┘ ↓ Bull / Bear Debate ↓ Trader ↓ Risk Management ↓ Portfolio Manager ↓ Structured Decision ↓ Deterministic Risk Gate ↓ BrokerAdapter ↓ Simulated / Alpaca

This would preserve TradingAgents' multi-agent architecture while making it possible to experiment with hybrid ML + LLM systems and paper-trading execution.

Questions

Would maintainers be interested in either of these abstractions?

• "SignalProvider" / external structured signals
• "BrokerAdapter" for execution

If so, I would be interested in discussing the interface design before attempting an implementation.

Related work/issues appear to already be moving toward more deterministic structured outputs, so I thought this might be a natural extension of that direction.