How a Trade Idea Becomes a Strategy

At OpenPond, we think there is a big difference between talking about a trade and building a strategy.

A trade idea is just a thesis. A strategy is something you can inspect as code, backtest against historical conditions, deploy into a real runtime, and review later based on what actually happened. Most of the product is built around making that transition feel natural instead of forcing people to jump between chat, scripts, hosting, and portfolio tooling.

The rough path looks like this: you start in the builder, describe what you want in plain language, let the AI turn that idea into an app, backtest the app, deploy a preview, and then monitor live activity through the same app once it is running.

Start with a real prompt

The best prompts in OpenPond are usually specific about three things: the market, the signal, and the action. The current prompt guidance in the create flow leans in that direction for a reason.

Some real examples from the product are:

Those are much more useful than something vague like “make me a trading bot.” They tell the system what market to care about, what kind of signal matters, and what the strategy should do when the condition is met.

If you are not ready to build yet, the same builder also works well for earlier-stage prompts like “I want to trade big market news events. What strategy family fits best?” That is still part of the same workflow. The point is to move from a rough idea into a concrete implementation path without leaving the product.

The idea becomes an app

Once the prompt is good enough, the AI stops being just a market explainer and starts acting like an authoring tool. It can select a starting template, write TypeScript files, shape the config surface, and explain the strategy it is building.

The result is an app, not a disposable chat response.

That matters because the app is the main strategy container in OpenPond. It holds the code, the AI history, the deployment history, the config, and the activity tied to that strategy. For internal apps, the code lives in our hosted git-backed repo system, which means changes have a real history and can be revised over time. For GitHub apps, the code stays in your repo and OpenPond deploys from there.

Either way, the important thing is that the strategy becomes a codebase early. Once it is code, it can be inspected, changed, and tested like any other software project.

Backtesting is part of the same loop

After the app exists, the next useful step is usually backtesting. In our system, the backtest is not a detached artifact sitting in a different workflow. It is tied to the app and its deployment context, so the same strategy you were just discussing in chat becomes the thing you are now evaluating historically.

That gives you a much cleaner loop:

You start with the idea, let the AI write the first version, run the backtest, look at the results, change the app, and run it again. Sometimes the change is in code. Sometimes it is in config. Sometimes the backtest shows that the thesis was fine but the execution rules were wrong. The important part is that the app stays at the center of the loop.

This is also why we care about keeping the strategy in code rather than burying it in a long prompt. Once the logic is in the app, you can ask much better questions. What did the strategy actually decide? How often did it trade? What was the drawdown? Did the exit logic do what you expected? Those are software questions as much as trading questions.

OpenTool is the code layer

OpenTool is the framework that makes this workflow practical. It gives the strategy a stable server shape with typed tools, metadata, config, exchange integrations, and a standard runtime contract.

That means the same strategy code can move through a fairly clean path:

The AI writes or updates the app, OpenTool packages the tools and metadata, OpenPond deploys the app, and the resulting deployment can be executed and observed in a way that still points back to the same codebase.

Without that layer, you tend to end up with strategy logic scattered across scripts, notebooks, API glue, and chat transcripts. With OpenTool, the app remains a real thing you can version and deploy.

Deployments are the execution checkpoints

Once the app is in good enough shape, it gets deployed. In practice, we think about deployments as checkpoints of the strategy rather than just hosting details.

A deployment gives you a specific code and config state, a runnable endpoint, logs, status, and a version you can compare against later. In day-to-day use, preview and production are the two environments that matter most. Preview is where you verify and iterate. Production is where a strategy ends up once you trust the current version enough to run it live.

That is a more useful structure than treating every iteration as a fresh script or every change as an abstract chat refinement. The strategy has named checkpoints and runtime history. You can see what was running, when it was deployed, and how it differed from the version before it.

Live activity is part of the product, not an afterthought

One of the harder parts of strategy software is not placing an order. It is being able to understand later what the strategy intended to do, what it actually did, and what state that left the portfolio in.

OpenTool strategies can emit structured events with store(). Those events land in OpenPond as app_store_events, which gives the app a consistent activity stream across decisions, execution attempts, and lifecycle updates. That is the first layer of live strategy history.

From there, the system derives more structured records. tradeFacts normalize trade-level execution details. Positions and snapshots tell you what is open and how the portfolio evolved. PnL and funding context can then be tied back to the same strategy path.

That separation is important. app_store_events are useful for understanding what the app reported and why. tradeFacts, positions, and snapshots are useful for understanding portfolio state. Together they give you a more complete picture of strategy behavior than either one would alone.

Why we built it this way

The main goal is to keep the path from idea to execution continuous.

The prompt should lead into code. The code should lead into backtests. The backtests should lead into deployments. The deployments should lead into live events and portfolio state. Once that loop is in place, both the user and the AI have a much better foundation for improving the strategy over time.

That is the workflow we have been trying to make more coherent inside OpenPond. You can start with a trade idea in the builder, but the important part is that it does not stay there. It turns into an app with code, history, deployments, and live state attached to it.

That is how we think about the difference between a trade idea and a strategy.