I built an AI trading agent where the AI is NOT allowed to trade
I've been building InnerOS Alpha for the Alpaca AI Trading Agents Hackathon, and I ended up making a design decision that sounds almost backwards:
The AI does not control the broker.
I didn't want to build another demo where an LLM gets an API key and somebody calls it an "autonomous trading agent."
Instead, I separated reasoning from authority.
The current architecture looks like this:
Alpaca market data → Local Qwen3-Coder → Options Contract Selector → Deterministic Risk Engine → Execution Gate → Alpaca PAPER → Evidence Trace
Qwen runs locally on our own AMD machine. It receives live Alpaca context and proposes a structured trading intent.
But after that, deterministic code takes over.
The model cannot freely choose a broker symbol, bypass portfolio limits, disable risk controls, or directly submit an order.
Contract selection, maximum-loss calculation, portfolio limits and execution permissions are enforced outside the LLM.
I also connected the official Alpaca MCP server, but deliberately configured it as read-only for account, assets, stock data, options data and news.
Trading is excluded from the MCP tools.
We eventually completed a real end-to-end Alpaca PAPER test:
dedicated PAPER account starting from the $100k hackathon baseline
live options data
local Qwen reasoning
deterministic contract selection
Risk Engine: PASS
real Alpaca PAPER order ID
one correlation ID across the entire workflow
persisted evidence
kill switch re-armed after the test
There was also a very Indie-Hackers-compatible failure along the way: two agents briefly collided on the same Alpaca task and we ended up discovering exactly why multi-agent systems need proper locks and execution ownership. 😅
That incident actually made the architecture better. New broker execution is now frozen for the demo, and the public interface separates live reasoning from historical execution proof.
I built two buttons for judges/builders:
RUN LIVE MARKET DECISION
Pulls current Alpaca data and runs the full AI + options + risk pipeline, but with execute=false.
REPLAY VERIFIED PAPER PROOF
Shows the sanitized evidence from the controlled PAPER execution without placing another order.
The thing I'm most interested in isn't whether an LLM can generate a trade idea. We already know it can.
The harder question is:
How do you build agentic financial systems where the AI can be useful without giving it unlimited authority?
My current answer is:
The AI may propose. Policy owns the final authority.
Demo:
https://alpaca.creatorcore.ai/console/
GitHub:
https://github.com/Rafa-Innerchispa/inneros-alpha-alpaca
I'd especially be interested in feedback from people building multi-agent systems, local AI infrastructure, MCP integrations or fintech tooling. I'm curious how others are handling the boundary between model reasoning and deterministic execution.
#buildinpublic #ai #agents #fintech #localai #opensource #mcp #alpaca
The separation of reasoning from authority is the part I find most interesting here.
There’s a harder case immediately after the execution gate: suppose the trade is validly authorised, but the authority behind it is revoked or changes before the broker actually executes it.
The model hasn’t bypassed anything. The risk engine may have passed. The original approval can be genuine. Yet the downstream action may no longer be authorised at the moment of consequence.
That stale-authority boundary is what we’ve been testing with OpsWatch.
In financial-agent systems, I think the difficult question becomes: where does authority finally get revalidated — at the agent, the gate, or the resource actually performing the transaction?
For auditability, do you also preserve the exact market-data state behind each recommendation? A decision can look very different when reviewed later if you only have the current data rather than what the agent actually saw at that moment.
Yes, at the decision boundary we do.
Every run gets a unique correlation ID, and we persist the normalized market snapshot that the agent actually saw at that moment together with the resulting thesis, selected options contract, portfolio state, risk decision, execution result, and full decision trace.
The market snapshot includes its timestamp, source, price, freshness, and the technical packet derived from the Alpaca data used for that run. So when we review a recommendation later, we are not asking the system to evaluate it against today’s market state.
One distinction though: today we preserve the exact decision snapshot, not every raw market tick or the complete raw options chain. For example, we retain the computed 5m/15m/60m returns, volatility, volume, trend, bar timestamp, option-chain filtering summary, and the exact selected contract with its quote/Greeks.
Full raw-input archival is the next level we’re considering for forensic replay, where you could reproduce the decision from the original raw bars and option snapshots rather than only audit the normalized evidence packet.
That distinction matters to us because we want an audit trail to answer not just “what did the agent decide?” but “what exactly did it know when it decided?”
The separation between reasoning and execution is interesting, but I’m curious whether users actually value that boundary as a product feature. Have you seen anyone prefer this architecture over a more autonomous agent, or is that distinction mainly driven by your own risk requirements so far?
That’s a fair question. We haven’t yet proven that users will pay specifically for the reasoning/execution boundary as a standalone feature. Right now, it is partly a deliberate risk and architecture decision.
What we believe users may value is not “less autonomy,” but governed autonomy: letting the agent do more without giving the model unrestricted authority over capital.
In practice, that means audit trails, deterministic risk limits, approval gates, a kill switch, and the ability to keep sensitive reasoning local.
The next thing we want to validate is exactly what you’re asking: whether users prefer analysis-only, approval-required, or bounded autonomous execution. I suspect different users will want different autonomy levels rather than one universal mode.
So today the boundary is a design principle. The product question we still need to prove is how much that boundary increases trust and adoption.