Repository navigation
Agents: make one tool round trip reachable from the CLI, or retire the dormant agent code #331
Description
What happens
AutoGen is gone (#606). The agents' LLM path is now BaseAgent.process_with_tools (src/autogen_agents/core/base_agent.py:161), an Agent Framework tool loop. Nothing reaches it.
- It is called only from the agents'
generate_replymethods (src/autogen_agents/agents/voter_agent.py:259,executor_agent.py:636,scanner_agent.py:791) and fromVoterAgent._fetch_and_evaluate(voter_agent.py:267), which onlygenerate_replycalls (voter_agent.py:227). generate_replyis defined five times (base_agent.py:250,risk_agent.py:565,executor_agent.py:560,scanner_agent.py:704,voter_agent.py:176) and called nowhere insrc/,main.py,scripts/orexamples/.- Typed CLI input goes through
IntentClassifierandTradeHandler(src/cli/cli_session.py:359,587) to the core orchestrator, whose parser isLLMParser(src/core/factory.py:108). It doesn't reach an agent's tool loop.RealVoterStrategycallsVoterAgent's scoring methods directly (src/strategies/real_voter_strategy.py:164,173). - The workflows of the agent orchestrator (
TradingOrchestrator.run_morning_routine,run_continuous_monitoring,monitor_positions,run_evening_summaryinsrc/autogen_agents/orchestration/trading_orchestrator.py) have no callers either, except thatrun_continuous_monitoringcallsmonitor_positions(line 395).
So the tool loop, the approval flow for agent-run tools (#430) and the ScannerAgent (#304) can't run from anything a user does. The CLI still calls the flagged tools directly. The design this issue first described, a multi-agent debate in an AutoGen GroupChat, went with AutoGen. This issue now asks for the first step. The original text is kept below.
Proposal
Pick one.
- Wire one flow. A CLI command that sends a request to one agent through
process_with_toolswith read-only tools, prints the reply, and shows approval requests for flagged tools (Approval flow for state-changing CLI tools under Agent Framework #430). It proves the path end to end. No multi-agent design until it exists. - Retire the dormant code. Remove the
generate_replymethods, the tool loop and the orchestrator workflows that nothing calls. Keep what the live path imports:BaseAgent,VoterAgentandMultiTimeframeVoter(used byRealVoterStrategy,src/strategies/real_voter_strategy.py:16-17),src/autogen_agents/tools,scanner_config(src/cli/commands/slash_commands.py:548), andTradingOrchestrator,ExecutionMode,AgentFactory,AgentBusandExecutorAgent(the CLI's cancel and execution-mode tools,src/cli/tools/order_tools.py:72,310andexecution_mode_tools.py:118).
Acceptance
- Option 1: a typed command reaches
process_with_tools(tested with the fake model server intests/unit/agents/test_base_agent_framework.py), prints the reply, and runs no state-changing tool without approval. - Option 2: nothing in
src/imports the removed code, the suite passes, and the docs that describe it are updated.
Original issue body
Summary
Implement multi-agent coordination architecture where multiple AutoGen agents can debate, discuss, and collaborate on trade analysis before presenting unified recommendations to the user.
Context
Current system uses single-agent analysis (VoterAgent). This issue explores multi-agent collaboration patterns using Microsoft AutoGen's group chat capabilities.
Vision
Instead of: Single agent analyzes → Suggests trade
Enable: Multiple agents debate → Reach consensus → Suggest trade
Example scenario:
User: "review SPY at 600"
ScannerAgent: "SPY showing bullish MACD cross, RSI neutral at 52"
RiskAgent: "Market volatility elevated (VIX 18), suggest smaller position"
VoterAgent: "Technical setup is strong, vote: BUY"
SentimentAgent: "News sentiment mixed, Fed meeting next week"
Orchestrator: [synthesizes] "Agents suggest BUY with reduced position size due to event risk. Entry: $600, Size: 50% normal, Stop: $588"
Requirements
Agent Roles
- ScannerAgent: Identifies opportunities, technical patterns
- VoterAgent: MACD+RSI voting system (already exists)
- RiskAgent: Position sizing, portfolio impact, risk limits
- SentimentAgent (optional): News/market sentiment context
- TradingOrchestrator: Moderates discussion, synthesizes recommendations
Coordination Patterns
Pattern 1: Sequential Analysis (simplest)
1. ScannerAgent analyzes → passes to VoterAgent
2. VoterAgent votes → passes to RiskAgent
3. RiskAgent sizes → Orchestrator presents to user
Pattern 2: Group Chat Debate (AutoGen native)
1. Orchestrator poses question to group
2. Agents discuss asynchronously (3-5 rounds)
3. Orchestrator synthesizes consensus
4. Present to user
Pattern 3: Voting System (democratic)
1. All agents analyze independently
2. Each casts vote (BUY/SELL/HOLD) with confidence
3. Orchestrator aggregates votes (weighted by confidence)
4. Present majority decision + dissenting opinions
Question for discussion: Which pattern fits best? Start with Pattern 1 (sequential), evolve to Pattern 2?
Output Format
User should see:
- Unified recommendation (clear action)
- Agent consensus (who voted what)
- Key reasoning (2-3 bullet points)
- Dissenting views (if significant disagreement)
Example Output
━━━━━━━━━━━━━━━━━━━━━━
📊 SPY @ $600 Analysis
━━━━━━━━━━━━━━━━━━━━━━
✅ RECOMMENDATION: BUY (Consensus: 3/4 agents)
📈 VoterAgent: STRONG BUY (MACD bullish cross, RSI 52)
⚠️ RiskAgent: BUY with caution (reduce position 50% due to VIX 18)
🔍 ScannerAgent: BUY (support at $595, resistance at $615)
📰 SentimentAgent: HOLD (Fed meeting uncertainty next week)
💡 Orchestrator: Agents suggest entry with reduced risk due to event uncertainty.
→ Entry: $600 | Size: 25 shares (50% normal) | Stop: $588
Continue? [yes/no]
Technical Implementation
AutoGen Group Chat Setup
from autogen import GroupChat, GroupChatManager
# Define agents
scanner = ScannerAgent(...)
voter = VoterAgent(...) # existing
risk = RiskAgent(...)
orchestrator = TradingOrchestrator(...)
# Create group chat
group_chat = GroupChat(
agents=[scanner, voter, risk, orchestrator],
messages=[],
max_round=5
)
# Manager coordinates discussion
manager = GroupChatManager(groupchat=group_chat, llm_config=llm_config)
# User request triggers group analysis
user_request = "review SPY at 600"
orchestrator.initiate_chat(manager, message=user_request)Event Bus Integration
- Consider Implement Event Bus for Market Events and Trade Signals #316 (Event Bus) for decoupled agent messaging
- Agents publish analysis events → Orchestrator subscribes and synthesizes
- Enables async agent execution (faster responses)
Dependencies
Depends on:
- CLI Human-in-Loop Trading Interface - Text-based decision approval #308 - CLI Human-in-Loop Interface (need basic interface first)
- Complete remaining AutoGen agents - Focus on Integration #310 - Complete Remaining AutoGen Agents (need RiskAgent, ScannerAgent implementations)
Optionally depends on:
- Implement Event Bus for Market Events and Trade Signals #316 - Event Bus (for decoupled coordination)
Related:
- [Future][Feature] Portfolio Management Suite - Multi-asset Coordination #329 - Options Analysis (would benefit from multi-agent debate)
Priority & Timeline
Priority: P2 - MEDIUM
Target: Q1-Q2 2026 (after core agents are implemented)
Size: Extra Large (XL)
Component: Multi-Agent System, Orchestration
Open Questions
- Coordination pattern: Sequential, group chat, or voting? (needs discussion)
- Performance: Will multi-agent debate be too slow for "fast entry" UX goal?
- Disagreement handling: What if agents strongly disagree? Show debate to user or hide it?
- Agent weights: Should VoterAgent (proven 0.856 Sharpe) have higher weight than new agents?
Notes
- This is an exploration issue - requires design discussion before implementation
- Start with simple sequential pattern, evolve to group chat if needed
- Preserve human-in-loop principle: agents suggest, humans decide
- Don't overcomplicate: if single VoterAgent works well, multi-agent adds complexity
Next Steps
- Discuss coordination pattern preference
- Implement remaining agents (Complete remaining AutoGen agents - Focus on Integration #310)
- Prototype simple sequential coordination
- Test with paper trading, measure performance impact
- Iterate based on user feedback
Activity
docs: update project status with new Phase 2 issues and #308 MVP scope
feat: add plugin-based architecture foundation for #308 CLI
SQLite Cache System & Documentation Overhaul (#363)
[-]Multi-Agent Coordination & Debate System[/-][+][Agent][Feature] Multi-Agent Coordination & Debate System[/+]iAmGiG commentedon Dec 1, 2025
Status Update
Infrastructure Foundation Complete:
Remaining Work:
Timeline: Q1-Q2 2026 - after remaining agents (#310) are implemented.
Adding 'future' label.
[-][Agent][Feature] Multi-Agent Coordination & Debate System[/-][+][Future][Agent][Feature] Multi-Agent Coordination & Debate System[/+]iAmGiG commentedon Mar 18, 2026
Status (March 2026): Long-term agent coordination. Multi-agent debate system for consensus trading decisions.
[-][Future][Agent][Feature] Multi-Agent Coordination & Debate System[/-][+]Agents: make one tool round trip reachable from the CLI, or retire the dormant agent code[/+]iAmGiG commentedon Oct 31, 2026
From the #625 audit (read-only, 310cc07). This decision now also settles these:
process_with_tools. Its four call sites are ingenerate_replyand_fetch_and_evaluate, and nothing calls those.ExecutorAgentis reached only through the three cancel tools.src/autogen_agents/orchestration/orchestrator.pyhas no importer and calls methods that don't exist.voter_agent._fetch_and_evaluatemakes a model call, discards the result and returns a fixed HOLD.process_with_tools_asyncreturns every failure as an ordinary string (base_agent.py:202-205).generate_replypromises astr(:174-178).ExecutorAgent's prompt promises trades and cancels, but its model tools are market data only.AgentConfig.tools,model_nameandtemperaturenever reachBaseAgent.OrderManagercalls broker methods theAlpacaTradingClientwrapper doesn't have (see the cancel issue).iAmGiG commentedon Nov 1, 2026
The owner chose stage 1 on 2026-11-01: remove what's dead whichever way this goes (#650). Still open: keep the rest, or build on it.
What a read-only mapping found, at 8623bab:
main.pyand the scheduler finds none, andimport maindoesn't load it.FunctionTools has a production caller as a tool. The CLI calls plain functions directly, and 68 of the tools wrap a function no command reaches.VoterAgentdoesn't needBaseAgent. It uses onlyself.name, to publish to a bus nothing reads. The signal maths is inVotingSignal.LLMParserkeeps both framework packages.The remaining choice:
BaseAgent, the market tools and the tool layer. Approval flow for state-changing CLI tools under Agent Framework #430 becomes moot, and much of fix(tools): make each tool's words match what it does #646 goes with it./ask, about 200 lines plus tests. It's the first path from model output to tools, so it needs a read-only allow-list, an overall deadline, and errors that don't read as answers. Approvals (Approval flow for state-changing CLI tools under Agent Framework #430) would come later, if at all.Whether a natural-language agent feature is wanted is the owner's call. Either way, 21 tools are flagged now, not the 22 #430 lists, as the execution-mode tools were removed in #644.
Merge pull request #655 from iAmGiG/feat/cli-commands-331
Merge pull request #656 from iAmGiG/refactor/retire-agents-331
Merge pull request #663 from iAmGiG/docs/after-331