If an agent's backtest report shows a high win rate but live performance is much worse, which stage is most likely the culprit?
The most common gap comes from perception and decision-stage latency being hidden in the backtest environment. Backtests typically run simulations on historical data, and that data has no "latency" problem — every historical price point you get is complete and instantly usable. But in a live environment, data-source latency, network congestion, and computation time are all real variables that never appear during backtesting, causing the backtested win rate to systematically overestimate actual performance.
To check, look at whether the agent's testing included "latency-aware simulation" (deliberately injecting random delays into backtest data to mimic real network conditions). If the developer documentation doesn't mention this layer at all, the gap between backtest and live performance is usually more pronounced than expected.
Does an underestimated gas fee causing a transaction to get stuck in the mempool have anything to do with the sandwich attacks mentioned earlier?
There's some relationship, but they're different risk sources. A sandwich attack involves an attacker actively exploiting mempool transparency to cut in line around your transaction and profit; a transaction stuck due to underestimated gas is typically a passive execution failure — the transaction itself isn't being targeted, it's simply bid too low to get included in a block during network congestion. But the two can genuinely amplify each other: a large transaction sitting unconfirmed in the mempool for a long time is itself an easier target for a sandwich attack, since it gives the attacker more time to observe and calculate.
This is exactly why private transaction pools help with both problems at once — avoiding long exposure in the public mempool both reduces the chance of being front-run and, by negotiating directly with block builders, improves the situation where a transaction was simply outbid and stuck.
If decision-stage computation is too complex, wouldn't simplifying the strategy logic solve the latency problem?
Simplifying logic does shorten computation time, but that trades "strategy quality" for "execution speed" — it's not a free solution. An overly simplified decision logic might react fast enough during normal market fluctuations, but when facing complex multi-variable scenarios (evaluating price spreads across multiple chains simultaneously while also factoring in gas cost comparisons), decision quality can drop noticeably — execution is fast, but the decision itself isn't precise enough, so losses still happen, just for a different reason.
A more practical approach isn't to simply simplify the logic, but to engineer the computation pipeline itself — pre-computing parts that don't need real-time calculation, keeping complex computation only where a real-time reaction is genuinely required, or upgrading the computing infrastructure itself (faster hardware, servers located closer to nodes). The solution to latency problems usually lives at the engineering level, not in sacrificing strategy depth.
As an ordinary user, I can't see an agent's internal execution speed at all — how can I indirectly judge whether this is a problem?
You don't need to understand code-level detail, but you can watch a few indirect indicators: whether the product has publicly disclosed the gap between live and backtested performance (a product willing to honestly disclose that gap usually indicates the team is taking execution latency seriously); whether the historical transaction log frequently shows trades that are "confirmed but with noticeably worse-than-expected slippage" (usually concrete evidence of execution latency); and whether the agent's performance visibly deteriorates during periods of sharp market volatility (latency problems are typically most exposed during fast market moves).
None of these observations require a technical background — just a willingness to spend time looking at historical data instead of trusting only the average return figure on a marketing page.
When a DeFAI agent's strategy logic is sound but it still keeps losing money, the problem is often not "whether this trade should happen" — it's hidden in the delays between the three stages of the execution loop. This article breaks down where each of the perceive, decide, and act stages can get stuck, helping you judge whether an underperforming agent is a strategy design problem or an execution mechanism problem.
Before an agent makes any judgment, its first step is reading on-chain state and market data. This sounds simple, but it's riddled with latency traps: if the agent's price source pulls from a centralized API instead of reading directly from the chain, there can be a lag of several seconds; if the agent monitors pending mempool transactions to anticipate price moves, network congestion slows down the mempool's own propagation speed, meaning the "real-time state" the agent sees has already fallen behind what's actually happening on-chain. Perception-stage latency doesn't crash the agent or throw an error — it just makes the agent decide based on data that looks normal but is actually stale. This is one of the hardest failure modes to detect, because on the surface, everything looks like it's running fine.
Even if perception-stage data is fresh enough, the decision logic itself can slow the entire loop's rhythm if it's too computationally heavy. The more complex a strategy is (comparing multiple candidate paths simultaneously, running probabilistic models to evaluate expected returns), the longer computation takes — and if that computation time exceeds the speed of market movement, the opportunity window may have already closed by the time the agent finishes concluding "execute now." Decision-stage latency is a cost often underestimated during strategy design — developers tend to focus only on whether the logic is correct, without evaluating how long that logic takes to produce a result.
Even with fast, accurate perception and decisions, a submitted transaction still has to face the blockchain's own uncertainty: if gas fees are underestimated, the transaction can sit stuck in the mempool for a long time without being included; if another transaction in the same block executes first and changes on-chain state, the previously calculated slippage and price may no longer hold, causing the transaction to fail or execute on worse terms. This is exactly why many legitimate products have adopted private transaction pools — not to game the system, but to reduce the structural risk of "the decision was right, but execution fell apart."
In practice, these three delays often occur simultaneously and amplify each other: perception lags by a few hundred milliseconds, decision-making burns additional time on heavy computation, and by the time the transaction finally gets submitted, it may already be several blocks behind the ideal moment. When evaluating a DeFAI product's execution mechanism, it's not enough to look at how clever the strategy logic sounds — it matters just as much whether the total delay across all three stages has been seriously optimized, and whether the team has publicly disclosed any performance data on it.
If you're using or evaluating a DeFAI product, reading the strategy documentation alone isn't enough to judge real-world performance. Worth asking: does this agent's data come directly from the chain or through a third-party API, how long does decision computation typically take, and does the submitted transaction route through the public mempool or a private transaction pool? These three answers can tell you whether the product's execution mechanism can genuinely keep up with the market's actual speed, rather than only performing well in an idealized backtest report.