u/Simone_Crosta

A quick update on the v2 of my trading architecture (moving away from LLM "distributed vetoes" to a strict State Machine).

​I just finished building the Phase 2 component: a purely Python, deterministic Multi-Timeframe Cascade.

Before the AI even gets to look at the market, a Python feature extractor reads the D1, H4, and H1 timeframes concurrently. It maps out the smart money concepts (the strategy I choose to test).

​If D1 is Bearish, H4 is Bearish, but H1 is Bullish... the JSON outputs:

aligned: false

reason: "Timeframes disagree"

​A major lesson learned during this phase:

While building this with my coding assistant, the tool tried to silently map an UNKNOWN market state into a NEUTRAL state to make the code run smoother.

I caught it and realized this is exactly how "black boxes" are born. If I let the system silently normalize data without telling me, debugging a live failure in 3 months would be impossible.

So, I implemented a strict bias_source tracker. Every single output now has an exact audit trail of why it decided a trend exists (e.g., BOS_EVENT vs NO_BOS_HISTORY).

​My question for the Quants and System Builders here:

Right now, my alignment rule is brutal:

STRICT_ALL_THREE_AGREE.

If D1, H4, and H1 aren't pointig in the exact same direction, the system stays in IDLE.

Is requiring a perfect 3-timeframe alignment too paranoid?

My fear is that by doing this, the bot will completely ignore highly profitable intraday pullbacks (e.g., D1 Bullish, H4 Bearish retracement, H1 Bearish continuation) and starve for trades.

How do you usually balance MTF alignment vs.

execution starvation in your deterministic systems?

​What's next (Phase 3):

Now that I have a rock-solid, verifiable Python JSON acting as the "ground truth", it's time to bring the LLM back into the game. Its new job?

Just reading this JSON to extract the institutional narrative and pick the best H1 Point of Interest. No math allowed.

​Would love to hear your thoughts on the alignment strictness!

A quick update on the v2 of my trading architecture (moving away from LLM "distributed vetoes" to a strict State Machine).

​I just finished building the Phase 2 component: a purely Python, deterministic Multi-Timeframe Cascade.

Before the AI even gets to look at the market, a Python feature extractor reads the D1, H4, and H1 timeframes concurrently. It maps out the smart money concepts (the strategy I choose to test).

​If D1 is Bearish, H4 is Bearish, but H1 is Bullish... the JSON outputs:

aligned: false

reason: "Timeframes disagree"

​A major lesson learned during this phase:

While building this with my coding assistant, the tool tried to silently map an UNKNOWN market state into a NEUTRAL state to make the code run smoother.

I caught it and realized this is exactly how "black boxes" are born. If I let the system silently normalize data without telling me, debugging a live failure in 3 months would be impossible.

So, I implemented a strict bias_source tracker. Every single output now has an exact audit trail of why it decided a trend exists (e.g., BOS_EVENT vs NO_BOS_HISTORY).

​My question for the Quants and System Builders here:

Right now, my alignment rule is brutal:

STRICT_ALL_THREE_AGREE.

If D1, H4, and H1 aren't pointig in the exact same direction, the system stays in IDLE.

Is requiring a perfect 3-timeframe alignment too paranoid?

My fear is that by doing this, the bot will completely ignore highly profitable intraday pullbacks (e.g., D1 Bullish, H4 Bearish retracement, H1 Bearish continuation) and starve for trades.

How do you usually balance MTF alignment vs.

execution starvation in your deterministic systems?

​What's next (Phase 3):

Now that I have a rock-solid, verifiable Python JSON acting as the "ground truth", it's time to bring the LLM back into the game. Its new job?

Just reading this JSON to extract the institutional narrative and pick the best H1 Point of Interest. No math allowed.

​Would love to hear your thoughts on the alignment strictness!

Thanks to the incredible feedback on my last post, I’m officially moving away from the "distributed veto" system (where 8 LLM agents argue until they agree to trade).

For v2, I am implementing a strict State Machine using a deterministic runtime (llm-nano-vm).

​The new rule is simple: Python owns the math and the execution contract. The LLM only interprets the context.

​I've sketched out a 5-module architecture, but before I start coding the new Python feature extractors, I want to sanity-check the exact roles I’m giving to the AI.

Here is the blueprint:

​1. The HTF Agent (Higher Timeframe - D1/H4)

​Python: Extracts structural levels, BOS/CHoCH, and premium/discount zones.

​LLM Role: Reads this hard data to determine the institutional narrative and select the most relevant Draw on Liquidity (DOL).

​2. The Structure Agent (H1)

​Python: Identifies all valid Order Blocks (OB) and Fair Value Gaps (FVG) with displacement.

​LLM Role: Selects the highest-probability Point of Interest (POI) based on the HTF Agent's narrative.

​3. The Trigger Agent (M15/M5)

​100% Python (NO LLM): Purely deterministic. It checks for liquidity sweeps and LTF CHoCH inside the selected POI.

​4. The Context Agent

​LLM Role: Cross-references active killzones, news blackouts, and currency correlations to either greenlight or veto the setup.

​5. The Risk Agent

​100% Python (NO LLM): Calculates Entry, SL, TP, Expected Value (EV), and position sizing.

​The state machine will only transition to EXECUTING if the deterministic Trigger and Risk modules say yes. The LLMs are basically just "context providers" for the state machine.

​My questions for the quants/architects here:

​Does this division of labor make sense? Am I giving the LLMs too much or too little responsibility in step 1 and 2?

​By making the Trigger layer (M15/M5) 100% deterministic, am I losing the core advantage of having an AI, or is this the standard way to avoid execution paralysis?

​Would you merge the HTF and Structure agents to reduce token constraints/hallucinations, or is separating them better for debugging?

​Would love to hear your thoughts before I dive into the codebase.

Thanks to the incredible feedback on my last post, I’m officially moving away from the "distributed veto" system (where 8 LLM agents argue until they agree to trade).

For v2, I am implementing a strict State Machine using a deterministic runtime (llm-nano-vm).

​The new rule is simple: Python owns the math and the execution contract. The LLM only interprets the context.

​I've sketched out a 5-module architecture, but before I start coding the new Python feature extractors, I want to sanity-check the exact roles I’m giving to the AI.

Here is the blueprint:

​1. The HTF Agent (Higher Timeframe - D1/H4)

​Python: Extracts structural levels, BOS/CHoCH, and premium/discount zones.

​LLM Role: Reads this hard data to determine the institutional narrative and select the most relevant Draw on Liquidity (DOL).

​2. The Structure Agent (H1)

​Python: Identifies all valid Order Blocks (OB) and Fair Value Gaps (FVG) with displacement.

​LLM Role: Selects the highest-probability Point of Interest (POI) based on the HTF Agent's narrative.

​3. The Trigger Agent (M15/M5)

​100% Python (NO LLM): Purely deterministic. It checks for liquidity sweeps and LTF CHoCH inside the selected POI.

​4. The Context Agent

​LLM Role: Cross-references active killzones, news blackouts, and currency correlations to either greenlight or veto the setup.

​5. The Risk Agent

​100% Python (NO LLM): Calculates Entry, SL, TP, Expected Value (EV), and position sizing.

​The state machine will only transition to EXECUTING if the deterministic Trigger and Risk modules say yes. The LLMs are basically just "context providers" for the state machine.

​My questions for the quants/architects here:

​Does this division of labor make sense? Am I giving the LLMs too much or too little responsibility in step 1 and 2?

​By making the Trigger layer (M15/M5) 100% deterministic, am I losing the core advantage of having an AI, or is this the standard way to avoid execution paralysis?

​Would you merge the HTF and Structure agents to reduce token constraints/hallucinations, or is separating them better for debugging?

​Would love to hear your thoughts before I dive into the codebase.

Thanks to the incredible feedback on my last post, I’m officially moving away from the "distributed veto" system (where 8 LLM agents argue until they agree to trade).

For v2, I am implementing a strict State Machine using a deterministic runtime (llm-nano-vm).

​The new rule is simple: Python owns the math and the execution contract. The LLM only interprets the context.

​I've sketched out a 5-module architecture, but before I start coding the new Python feature extractors, I want to sanity-check the exact roles I’m giving to the AI.

Here is the blueprint:

​1. The HTF Agent (Higher Timeframe - D1/H4)

​Python: Extracts structural levels, BOS/CHoCH, and premium/discount zones.

​LLM Role: Reads this hard data to determine the institutional narrative and select the most relevant Draw on Liquidity (DOL).

​2. The Structure Agent (H1)

​Python: Identifies all valid Order Blocks (OB) and Fair Value Gaps (FVG) with displacement.

​LLM Role: Selects the highest-probability Point of Interest (POI) based on the HTF Agent's narrative.

​3. The Trigger Agent (M15/M5)

​100% Python (NO LLM): Purely deterministic. It checks for liquidity sweeps and LTF CHoCH inside the selected POI.

​4. The Context Agent

​LLM Role: Cross-references active killzones, news blackouts, and currency correlations to either greenlight or veto the setup.

​5. The Risk Agent

​100% Python (NO LLM): Calculates Entry, SL, TP, Expected Value (EV), and position sizing.

​The state machine will only transition to EXECUTING if the deterministic Trigger and Risk modules say yes. The LLMs are basically just "context providers" for the state machine.

​My questions for the quants/architects here:

​Does this division of labor make sense? Am I giving the LLMs too much or too little responsibility in step 1 and 2?

​By making the Trigger layer (M15/M5) 100% deterministic, am I losing the core advantage of having an AI, or is this the standard way to avoid execution paralysis?

​Would you merge the HTF and Structure agents to reduce token constraints/hallucinations, or is separating them better for debugging?

​Would love to hear your thoughts before I dive into the codebase.

Thanks to the incredible feedback on my last post, I’m officially moving away from the "distributed veto" system (where 8 LLM agents argue until they agree to trade).

For v2, I am implementing a strict State Machine using a deterministic runtime (llm-nano-vm).

​The new rule is simple: Python owns the math and the execution contract. The LLM only interprets the context.

​I've sketched out a 5-module architecture, but before I start coding the new Python feature extractors, I want to sanity-check the exact roles I’m giving to the AI.

Here is the blueprint:

​1. The HTF Agent (Higher Timeframe - D1/H4)

​Python: Extracts structural levels, BOS/CHoCH, and premium/discount zones.

​LLM Role: Reads this hard data to determine the institutional narrative and select the most relevant Draw on Liquidity (DOL).

​2. The Structure Agent (H1)

​Python: Identifies all valid Order Blocks (OB) and Fair Value Gaps (FVG) with displacement.

​LLM Role: Selects the highest-probability Point of Interest (POI) based on the HTF Agent's narrative.

​3. The Trigger Agent (M15/M5)

​100% Python (NO LLM): Purely deterministic. It checks for liquidity sweeps and LTF CHoCH inside the selected POI.

​4. The Context Agent

​LLM Role: Cross-references active killzones, news blackouts, and currency correlations to either greenlight or veto the setup.

​5. The Risk Agent

​100% Python (NO LLM): Calculates Entry, SL, TP, Expected Value (EV), and position sizing.

​The state machine will only transition to EXECUTING if the deterministic Trigger and Risk modules say yes. The LLMs are basically just "context providers" for the state machine.

​My questions for the quants/architects here:

​Does this division of labor make sense? Am I giving the LLMs too much or too little responsibility in step 1 and 2?

​By making the Trigger layer (M15/M5) 100% deterministic, am I losing the core advantage of having an AI, or is this the standard way to avoid execution paralysis?

​Would you merge the HTF and Structure agents to reduce token constraints/hallucinations, or is separating them better for debugging?

​Would love to hear your thoughts before I dive into the codebase.

Thanks to the incredible feedback on my last post, I’m officially moving away from the "distributed veto" system (where 8 LLM agents argue until they agree to trade).

For v2, I am implementing a strict State Machine using a deterministic runtime (llm-nano-vm).

​The new rule is simple: Python owns the math and the execution contract. The LLM only interprets the context.

​I've sketched out a 5-module architecture, but before I start coding the new Python feature extractors, I want to sanity-check the exact roles I’m giving to the AI.

Here is the blueprint:

​1. The HTF Agent (Higher Timeframe - D1/H4)

​Python: Extracts structural levels, BOS/CHoCH, and premium/discount zones.

​LLM Role: Reads this hard data to determine the institutional narrative and select the most relevant Draw on Liquidity (DOL).

​2. The Structure Agent (H1)

​Python: Identifies all valid Order Blocks (OB) and Fair Value Gaps (FVG) with displacement.

​LLM Role: Selects the highest-probability Point of Interest (POI) based on the HTF Agent's narrative.

​3. The Trigger Agent (M15/M5)

​100% Python (NO LLM): Purely deterministic. It checks for liquidity sweeps and LTF CHoCH inside the selected POI.

​4. The Context Agent

​LLM Role: Cross-references active killzones, news blackouts, and currency correlations to either greenlight or veto the setup.

​5. The Risk Agent

​100% Python (NO LLM): Calculates Entry, SL, TP, Expected Value (EV), and position sizing.

​The state machine will only transition to EXECUTING if the deterministic Trigger and Risk modules say yes. The LLMs are basically just "context providers" for the state machine.

​My questions for the quants/architects here:

​Does this division of labor make sense? Am I giving the LLMs too much or too little responsibility in step 1 and 2?

​By making the Trigger layer (M15/M5) 100% deterministic, am I losing the core advantage of having an AI, or is this the standard way to avoid execution paralysis?

​Would you merge the HTF and Structure agents to reduce token constraints/hallucinations, or is separating them better for debugging?

​Would love to hear your thoughts before I dive into the codebase.

Following the amazing feedback on my last post about "distributed vetoes" vs "execution contracts", I’ve decided to split my AI trading project into two parallel tracks starting today.

​Track 1: v1 Forward Testing

I’m fixing a final minor crash on Agent 3's geometry parser, and then... hands off. I will let the current 8-agent pipeline run live on Oanda to wait for its first real EXECUTE. The goal here is purely data collection. Let it gather trades to see if the "generalist" approach actually has an edge or just execution paralysis

​Track 2: v2 planned (The State Machine)

While v1 gathers data, I’m starting to build the v2 architecture from scratch. No more "agents voting on a trade". The new system will be a strict State Machine testing hyper-specialized strategies.

​Before I write a single line of code for v2, I want to sanity-check the blueprint with you guys.

I have 3 specific questions:

​1. The Explicit States

My proposed state flow for the machine is:

IDLE → SCANNING → STALKING → CONFIRMED → EXECUTING → COOLDOWN

Are these states sufficient for a trading loop, or am I missing any crucial intermediate state (e.g., managing open positions vs just executing)?

​2. State Transitions (The Execution Contract)

My plan to prevent LLM hallucinations: The LLMs act purely as a "Context Engine" (extracting structure, macro, correlations). They output structured variables, but they never decide the state transition.

A deterministic Python script reads those variables and hard-transitions the state.

Is this the best way to enforce an execution contract while keeping AI in the loop?

​3. Picking the First 'Specialist' Strategy

To build and stress-test v2, I need to implement one single, strict mechanical edge (unlike the generalist v1).

What would you recommend as the best mechanical strategy to test a state machine pipeline?

(e.g., London Breakout, ICT Kill Zones, simple OB rejection in a clear trend).

I need something with tested and documentable rules.

​Let me know if this architecture makes sense or if I'm walking into a new trap.

Following the amazing feedback on my last post about "distributed vetoes" vs "execution contracts", I’ve decided to split my AI trading project into two parallel tracks starting today.

​Track 1: v1 Forward Testing

I’m fixing a final minor crash on Agent 3's geometry parser, and then... hands off. I will let the current 8-agent pipeline run live on Oanda to wait for its first real EXECUTE. The goal here is purely data collection. Let it gather trades to see if the "generalist" approach actually has an edge or just execution paralysis

​Track 2: v2 planned (The State Machine)

While v1 gathers data, I’m starting to build the v2 architecture from scratch. No more "agents voting on a trade". The new system will be a strict State Machine testing hyper-specialized strategies.

​Before I write a single line of code for v2, I want to sanity-check the blueprint with you guys.

I have 3 specific questions:

​1. The Explicit States

My proposed state flow for the machine is:

IDLE → SCANNING → STALKING → CONFIRMED → EXECUTING → COOLDOWN

Are these states sufficient for a trading loop, or am I missing any crucial intermediate state (e.g., managing open positions vs just executing)?

​2. State Transitions (The Execution Contract)

My plan to prevent LLM hallucinations: The LLMs act purely as a "Context Engine" (extracting structure, macro, correlations). They output structured variables, but they never decide the state transition.

A deterministic Python script reads those variables and hard-transitions the state.

Is this the best way to enforce an execution contract while keeping AI in the loop?

​3. Picking the First 'Specialist' Strategy

To build and stress-test v2, I need to implement one single, strict mechanical edge (unlike the generalist v1).

What would you recommend as the best mechanical strategy to test a state machine pipeline?

(e.g., London Breakout, ICT Kill Zones, simple OB rejection in a clear trend).

I need something with tested and documentable rules.

​Let me know if this architecture makes sense or if I'm walking into a new trap.

Following the amazing feedback on my last post about "distributed vetoes" vs "execution contracts", I’ve decided to split my AI trading project into two parallel tracks starting today.

​Track 1: v1 Forward Testing

I’m fixing a final minor crash on Agent 3's geometry parser, and then... hands off. I will let the current 8-agent pipeline run live on Oanda to wait for its first real EXECUTE. The goal here is purely data collection. Let it gather trades to see if the "generalist" approach actually has an edge or just execution paralysis

​Track 2: v2 planned (The State Machine)

While v1 gathers data, I’m starting to build the v2 architecture from scratch. No more "agents voting on a trade". The new system will be a strict State Machine testing hyper-specialized strategies.

​Before I write a single line of code for v2, I want to sanity-check the blueprint with you guys.

I have 3 specific questions:

​1. The Explicit States:

My proposed state flow for the machine is:

IDLE → SCANNING → STALKING → CONFIRMED → EXECUTING → COOLDOWN

Are these states sufficient for a trading loop, or am I missing any crucial intermediate state (e.g., managing open positions vs just executing)?

​2. State Transitions (The Execution Contract)

My plan to prevent LLM hallucinations: The LLMs act purely as a "Context Engine" (extracting structure, macro, correlations). They output structured variables, but they never decide the state transition.

A deterministic Python script reads those variables and hard-transitions the state.

Is this the best way to enforce an execution contract while keeping AI in the loop?

​3. Picking the First 'Specialist' Strategy

To build and stress-test v2, I need to implement one single, strict mechanical edge (unlike the generalist v1).

What would you recommend as the best mechanical strategy to test a state machine pipeline?

(e.g., London Breakout, ICT Kill Zones, simple OB rejection in a clear trend).

I need something with tested and documentable rules.

​Let me know if this architecture makes sense or if I'm walking into a new trap.

I spent the last few months building my multi-agent trading system. It's a "Generalist" system. It doesn't trade a single pattern. Try to read the context: evaluate whether we are trending or ranged, cross-reference macroeconomic data, analyze correlations between currencies, and mathematically calculate Expected Value before acting.

On paper, it's fascinating. But in reality, having 8 agents line up to press "EXECUTE" is a logical nightmare.

The system has to overcome so many cross vetoes that it is almost paranoid. I even had to create a debugging framework (if it doesn't trade for 7 days, I investigate) just to see if the market is at a standstill or if my confirmation rules are simply too strict.

All this effort has given me a huge question:

is it really worth building an "adaptive" intelligence?

The alternative is the opposite extreme, and it's much simpler: a hyper-specialized bot.

A system that is blind to 90% of the market that does only one thing very well. Wait for a specific time (e.g. London Breakout, ICT Kill Zones), search for a single mechanical setup, run it and turn it off. Zero macro, zero correlations, zero mental blowjobs on the global context.

For now, the plan is to let the generalist turn live forward-testing and collect the track record. If the data proves to me that all this effort to make him "understand" the market does not beat a simple mechanical edge, the next bot I will build will be a single-strategy sniper.

Who among you automates your logic (with AI or traditional code) on which side are you on?

Do you prefer complex systems that fit the regime, or stupid but relentless executors over a single strategy?

I spent the last few months building the my personal multi-agent trading system. It's a "Generalist" system. It doesn't trade a single pattern. Try to read the context: evaluate whether we are trending or ranged, cross-reference macroeconomic data, analyze correlations between currencies, and mathematically calculate Expected Value before acting.

On paper, it's fascinating. But in reality, having 8 agents line up to press "EXECUTE" is a logical nightmare.

The system has to overcome so many cross vetoes that it is almost paranoid. I even had to create a debugging framework (if it doesn't trade for 7 days, I investigate) just to see if the market is at a standstill or if my confirmation rules are simply too strict.

All this effort has given me a huge question:

Is it really worth building an "adaptive" intelligence?

The alternative is the opposite extreme, and it's much simpler: a hyper-specialized bot.

A system that is blind to 90% of the market that does only one thing very well. Wait for a specific time (e.g. London Breakout, ICT Kill Zones), search for a single mechanical setup, run it and turn it off.

Zero macro, zero correlations, zero mental blowjobs on the global context.

For now, the plan is to let the generalist turn live forward-testing and collect the track record. If the data proves to me that all this effort to make him "understand" the market does not beat a simple mechanical edge, the next bot I will build will be a single-strategy sniper.

Who among you automates your logic (with AI or traditional code) on which side are you on?

Do you prefer complex systems that fit the regime, or stupid but relentless executors over a single strategy?