About Quandora
Inspiration. The biggest shift in AI isn't better software — it's moving from selling tools to delivering outcomes. A company doesn't want a CRM; it wants qualified leads. A quant doesn't want another backtesting dashboard; they want validated signals. Finance is the perfect proving ground for outcome-driven AI because the output is measurable: a trading idea can be tested, a signal scored, a weak factor rejected. I'd also felt the other side of this personally — trading on vibes, watching AI agents give confident market takes with zero proof, and seeing how gatekept real quant research still is. Quandora is the outcome engine for agentic finance.
How I built it. Quandora gives an AI agent the finance infrastructure it's missing. A Claude Code skill (via MCP) lets a local agent generate a factor as runnable plugin.py code, auto-uploads it, and binds it to supported market data. A server-side backtest evaluation engine scores it (Sharpe, RankIC, drawdown, cost-viability) and returns a structured pass/fail card. Utility endpoints handle dedup/memory, error-repair, and pricing.
What I learned & the challenges. The hard part wasn't prompting — it was infrastructure. Getting a local agent to reliably submit, read errors, and iterate is the real challenge. Making backtests trustworthy (costs, decay, dedup, no curve-fitting) mattered more than making them pass. Above all: building the evidence rails so the agent returns proof, not confident hallucination.
How It Works — The Closed Loop
Quandora is a closed agentic validation loop. The user brings a market question; their agent turns it into a tested research card. End to end:
task card -> memory check -> factor generation (plugin.py + formula) -> upload to Quandora server -> server-side data binding -> backtest / evaluation -> result card (with stats or error info) -> agent reads result, explains, iterates
A factor is the unit of work — an executable artifact: plugin.py (the runnable implementation) plus a human-readable formula.
The task card (the agent's work order)
The agent picks an open task and receives a card with 8 operational fields: task_id, title, category, description, hints, allowed_data, fwd_period, status. It tells the agent what to build without exposing the live market data.
A key design choice is the data-header blindbox: the agent sees only the allowed field headers (e.g. close, volume, taker_buy_volume, funding_rate_close, open_interest_close, liquidation_long_usd). It never sees the changing values locally — those are bound server-side at evaluation time. This keeps the agent focused on logic while Quandora's server stays the source of truth for the data and the result.
The Core Layers
Quandora's infrastructure is three layers plus utility endpoints — the harness that turns an opinion-machine into an evidence-machine.
| Layer | Role |
|---|---|
| Data source | Supplies supported market inputs the factor may use — OHLCV, taker buy/sell flow, open interest, funding rates, long/short ratios, liquidations, Binance premium index. The factor can only be tested against data Quandora supports. |
| Backtest / evaluation | The quality gate. Binds the factor to data, runs the backtest, and scores it — currently led by Sharpe ratio, alongside RankIC/ICIR, IC win rate, autocorrelation, return, max drawdown, turnover, and cost-viability. Outputs a pass/fail decision: |
| Utility endpoints | The reliability glue: memory (has this task or a similar factor been done?), error-info return (actionable failure detail so the agent can repair and resubmit, not just "failed"), and pricing (turns the technical result into a game-credit price based on rarity, similarity, and supply/demand). |
Why the loop matters
The magic isn't that the first idea wins. Even a rejected idea is useful: the result card shows why it failed and what to test next, so the loop compounds. The boundary is deliberate — reporting rails, not trade calls. Quandora supplies the data, the test, the risk/decay context, and the evidence; the user's own agent interprets it and decides what to do.
