Quant-Code | Devpost

Home Page with Policy Iteration
The 9 agents: backbone of QuantCode
Browserbase Links extracting relevant Information
Detected Issues with Policy
Simulated Trades with the Policy
Live Compaction Multiplier
Compacted Context
Latex Equation Rendering and Modifying the Iteration Policy
Redis Database with Manual Search

Quant research is still fragmented and manual: ideas live in notebooks, strategy rules get lost in chat logs, and lessons from failed experiments are rarely stored in a reusable way. We wanted to build something that felt like "Claude Code for systematic strategy research" instead of just another trading dashboard or AI wrapper. The idea was to create a local agent that could take a research objective, turn it into structured strategy artifacts, critique its own output, and remember what it learned for the next run.

What inspired us was the gap between how quants actually work and how most AI tools are presented. Real research is iterative, skeptical, and heavily constrained by data availability, leakage risk, and reproducibility. So instead of building a system that pretends to discover alpha autonomously, we built one that is honest about uncertainty and useful as a research assistant. Our guiding idea was simple: broad research, narrow execution.

We built QuantCode as a CLI-first workflow with a read-only dashboard layered on top. The Python pipeline takes a research objective and runs it through a sequence of focused agents: research direction, prior-art discovery, market-mechanism reasoning, hypothesis generation, data-feasibility checks, strategy formalization, validation, critique, experiment planning, memory compaction, and memory curation. The artifacts are written into a local workspace as strategy YAML, run JSON, Markdown reports, and compressed context packs. We also added a Next.js dashboard to visualize the run timeline, critiques, memory, and compaction results in a way judges can inspect quickly.

One of the most important design choices was separating "interesting idea" from "valid strategy." We added an explicit feasibility gate to decide whether a hypothesis is testable now, testable only with a proxy, or blocked by missing data. Then we added a validation gate to reject vague or unsafe strategy definitions before they are ever written as structured specs. That matters in quant because a clever-sounding idea is not the same as a reproducible research artifact.

Another major part of the project was memory. We used a three-tier memory design backed by Redis: short-lived working traces, episodic run memory, and durable semantic lessons. Instead of replaying full agent traces every time, we compact long traces into smaller context packs and promote only the useful lessons. That gave us a practical way to show that the system can avoid repeating prior mistakes rather than just producing long outputs. In simple terms, if run 1 discovers that a signal is too weak, too vague, or too dependent on proxy data, run 2 should start from that lesson instead of making the same mistake again.

The hardest challenge was honesty. It is very easy to make an AI finance demo sound smarter than it is. We deliberately avoided that. QuantCode does not claim to be a live trading bot, does not submit trades, and does not pretend that every generated strategy works. In the hackathon version, experiment execution is explicitly bounded, and where evidence is limited, we say so. We also designed the system around human-in-the-loop review, source-backed claims, and structured outputs so users can inspect what happened rather than trust a black box.

A second challenge was balancing ambition with scope. There were many directions we could have taken: live broker integrations, broader data connectors, fully automated optimization loops, and richer evaluation pipelines. We cut most of that. The version we shipped focuses on the smallest system that still proves the core idea: an AI-assisted research workflow that writes structured artifacts, critiques itself, stores lessons, and improves the next run. That let us spend time on the parts that actually differentiate the product instead of building hackathon theater.

We also learned a lot about where AI is genuinely helpful in quantitative workflows. It is strong at structuring messy research, connecting prior art, generating candidate hypotheses, and summarizing lessons across long traces. It is much weaker when asked to imply empirical validity without proper data, testing, and controls. That pushed us toward a design where AI augments a research process instead of replacing it.

From a technical perspective, we learned that the combination of strict schemas, explicit gates, and memory compaction is more valuable than adding more agent behavior. A simple but well-bounded pipeline is easier to trust, easier to demo, and easier to extend. We also learned that the user experience matters even for a technical tool: the CLI is great for building and iterating, but the dashboard is what makes the system legible to other people.

If we continue this project, the next step is not "make the agent more autonomous." The next step is to tighten the evaluation boundary with a lightweight point-in-time backtester, better data connectors, and stronger measured learning from backtest outcomes. The long-term vision is a research environment where ideas, critiques, evidence, and lessons compound over time instead of disappearing after each run.