What does a trading bot do when it decides not to trade?
Most automated trading systems keep an excellent record of what they did and no record at all of what they decided against.
That sounds like a minor omission until you try to answer a simple question about a bot that has not traded in four days: is it being patient, or is it broken? A log containing only trades gives you an empty file in both cases.
Silence is ambiguous
An automated trader that has placed no trades since Tuesday could be in any of these states:
- Running on schedule, evaluating the market, and correctly finding nothing worth acting on.
- Running, but erroring out before it reaches a decision — and swallowing the error.
- Not running at all, because the scheduler stopped dispatching it.
- Running and deciding to trade, but failing at execution and discarding the attempt.
From the outside these are indistinguishable. All four produce the same thing: nothing. And the failure modes are far more urgent than the healthy case, which is precisely why "no news is good news" is the wrong default for a system trading your money.
The fix is not more alerting. It is recording the decision itself, so that "nothing happened" becomes a positive statement rather than an absence.
Writing down the non-event
On BT365, every agent evaluation resolves to one of three outcomes, and all three are written to the agent's execution diary:
- It traded. The action, its parameters, and the resulting order are recorded.
- It held. A no-action entry is recorded, with the reason the strategy gave.
- It errored. The failure is recorded as an error, not as silence.
The middle case is the one that usually goes missing elsewhere, and it is the one that makes the other two interpretable. A diary showing two hundred hold entries and no trades describes a strategy that is running and choosing to wait. A diary showing nothing at all describes a strategy you have lost track of. Same trade count; completely different situations.
Not every quiet run is a decision
There is a distinction worth drawing carefully, because getting it wrong replaces a useful signal with noise.
An agent configured to act on a four-hour timeframe still gets dispatched more often than that. Most of those runs exit immediately: it is not yet due to act. That is not a judgement about the market — the strategy never looked. Recording it as a decision would bury the real ones under entries that mean nothing more than "the clock has not moved yet".
So evaluations that stop at the interval check are deliberately not recorded as decisions. What gets written down is the case where the strategy actually ran, looked at the market, and concluded it should do nothing. The distinction is between evaluated and chose to wait and was not asked to evaluate.
Holding is proof of life
Recording holds has a second use that only becomes obvious once you rely on it.
Health monitoring on an agent fleet generally works by watching how long it has been since each agent last acted. Miss enough expected cycles and the agent is presumed broken, flagged, and eventually suspended automatically.
That heuristic quietly punishes patience. An agent gated by a trading-session window, or sitting in a cooldown after a loss, is behaving exactly as configured — and to a monitor that only counts trades, it looks progressively more dead the longer it correctly does nothing. The failure mode is a system that automatically shuts off its most disciplined strategies.
Because holds are recorded, they count as evidence the agent is alive. A recent hold proves the scheduler reached the strategy and the strategy reached a conclusion. The agent is gated, not dead — and the distinction is visible instead of inferred.
What the record is worth keeping for
Holds are by far the highest-volume thing an agent fleet produces and the least valuable per row, which makes retention a real design question rather than an afterthought. BT365 keeps three tiers:
- Holds: two weeks. Enough to answer "what has this agent been doing lately", which is the only question they are useful for.
- Trades, errors, and status changes: ninety days. Long enough to investigate a pattern across a quarter.
- Deposits and withdrawals: indefinitely. These are a financial audit trail, and an audit trail with a delete policy is not one.
The diary is owner-only. An agent's reasoning is visible to the person who deployed it and to nobody else — including on a public agent profile, which shows performance without exposing the decision log behind it.
Why this matters when you are evaluating an agent
The practical consequence is about how you read an agent's activity.
A strategy that holds through the overwhelming majority of its evaluations is not underperforming; that is what having an entry condition means. If a strategy trades on every evaluation, its entry condition is not doing any work, and you are paying fees for the privilege. The number worth looking at is not how often an agent trades but whether the trades it does make were preceded by a stated reason for waiting — and whether the reasons look like a strategy rather than a coin flip.
You can only ask that question of a system that wrote the waiting down.
BT365 runs prediction markets, perps, and spot from one self-custodial account, with a full execution diary on every agent you deploy. Explore the platform or read the agent documentation.