The Trading Agent Loop: How to build Claude Code for trading_

Seven years ago, I sat in a meeting like this and described Hummingbot for the first time. Hummingbot is open-source software: public software that people can download and use. A lot of users are projects looking to market make their own token; others are individuals looking to farm rewards, or market makers who want to start with some piece of software. Because we already connect to lots of exchanges and have open-source strategies, it is a natural place to start.

A coding agent changes that calculation. I asked Claude to build a simple Binance market-making bot; soon afterward I had code that basically worked. It was not Hummingbot, but I owned it and could customize it. For a narrow task, that may be enough to skip the packaged framework.

“Ten minutes later, you have a simple market-making bot that basically works.”

We have seen that change in our own revenue as people use AI to bypass the framework. It is not only Hummingbot’s problem; much of open-source software risks being disintermediated in the same way. The question for us is what to build when generating a first version of the software becomes cheap.

To me, the breakthrough is the coding-agent loop. Its tools do four things really well. First, the agent takes a prompt and figures out what you are trying to do: it determines your intent. Second, it reads the files and accesses other context. Third, it edits those files. Fourth, it tests the changes. Those steps turn a chatbot response into a process that can act on an existing system and use feedback instead of stopping after one plausible answer.

For me, testing is essential because a unit test or browser check tells the agent whether its change worked. If it did not, the agent returns to the loop. Trading needs an equivalent test, not merely plausible strategy text.

“That fourth step is very critical because when running unit tests, by verifying what they did in Playwright, they can know whether the change they made actually solved what they’re trying to do.”

The first step is to define something you can actually test. If the user simply says to make money, the agent should ask whether that means a directional strategy, an arbitrage strategy, or a market-making strategy. What is the goal? What is the time frame? What metrics will evaluate it? Those choices define the target that data collection, backtesting, and live evaluation will later test.

Next, the agent defines the strategy logic and what it must do when its conditions are met. It separates parameters that can change—such as trade amounts and spreads—from the parts that cannot. That gives the later backtest a specific strategy to evaluate instead of an instruction that changes with every result.

Finally, the same specification needs guardrails: the risk limit and the conditions under which the agent must stop trading. At the end of this first step, I want a Markdown strategy file plus configuration. The loop now has an artifact it can test and revise rather than an intention trapped inside a chat.

The second step is to collect whatever data is driving the hypothesis: candles, liquidations, open interest, or another market signal. The loop has to make sure it can access that data, sample and convert the raw observations into signals, clean and deduplicate the records, and verify that the result is usable. It also has to keep collecting the data over time rather than stop at one convenient snapshot.

Backtesting then runs the specification through history. The loop splits in-sample and out-of-sample periods, executes the strategy logic, checks the guardrails, measures the chosen metric, and sweeps parameters without letting the search simply overfit the data it already saw.

Promotion begins with a paper trade and then a small amount of capital. The loop monitors fills, P&L, and other real data points, compares them with the backtest, and asks whether the strategy assumptions were actually validated. Historical execution cannot reproduce every live condition. The staged rollout supplies the next test: scale what works and kill the strategy when its assumptions do not hold.

This has to be a loop because the first version usually fails. A live failure may send the process back to the strategy, the data, or the backtest. Deployment is another source of feedback, not the end of the process.

Quantitative hedge funds already run this process by putting researchers, engineers, data scientists, and traders around it. That would turn one sequential workflow into a portfolio-scale research process. The immediate question is how much of that loop Claude can actually handle.

“Ideally, what you want is a harness that can help you do all these steps in isolation, and then do that in parallel across different strategies.”

In my experience, Claude does not run this whole loop very well. It does not really have the domain expertise to help define a proper strategy, and a serious loop can burn through an entire token budget in half an hour. How much data is available to it? Can it run over a long period of time autonomously? Can it actually execute trades? Each gap can interrupt the feedback loop before it reaches live operation.

Security is the most important gap. If the server signs transactions automatically, how do we keep its private key from being compromised? A model that proposes a trade still needs a safe path to execution before this loop can control real capital.

Those questions are why we built Condor. It is a generic harness that uses Hummingbot as the execution layer and is meant to supply the missing environment around a trading agent. The goal is to let people exercise the loop, encounter the operational gaps, and tell us what the harness still needs.

Condor is open source and available to try, but I warn users that it remains experimental and ask them to expect issues. The release is an invitation to test the architecture and give us feedback, not evidence that autonomous trading has already been solved.

“It’s very much a work in progress though, so don’t be surprised if you have any issues.”

We are also running a builder competition with exchange partners. It takes place over a one-month period, during which participants build agents for the participating exchanges. Afterwards, we work with the exchanges to select the top agents for a live trading competition. This is our way to get feedback on Condor, see what people build, and use what they encounter to make a better harness.

That competition is part of the same test cycle as the trading-agent loop. Condor is still a work in progress; putting it in builders’ hands is how we expose what the harness can and cannot yet support.