Depth limits are the main knob that trades decision quality for runtime. Deeper search tends to produce stronger moves because you see further consequences, but the number of nodes expands exponentially with depth in most games. If the branching factor is b and you search d plies, a naive Minimax explores on the order of b^d leaf nodes. That means going from depth 6 to depth 8 can be far more expensive than it sounds. Depth limits let you keep response time stable, which is often more important than squeezing out the last bit of strength.
Accuracy drops with shallow depth because you stop before you can see decisive tactics or long-term traps. The most common failure is the horizon effect: a bad event is just beyond the cutoff, so the evaluation function doesn’t see it and the agent makes a move that postpones the problem rather than solving it. Another issue is depth parity: stopping on different players’ turns can change evaluations because the backed-up min/max structure interacts with the heuristic. Practical engines mitigate this with techniques like iterative deepening (so you get “best-so-far” results and often reach one extra ply), quiescence search (extend search in “noisy” positions like captures), and better evaluation functions that don’t overreact to short-term noise.
A concrete example: in a chess-like game, a sacrifice might look bad at depth 2 (material down) but wins at depth 4 (forced tactic). A shallow depth will reject it; a deeper depth finds it. But deeper depth is only feasible if you prune and order moves well, otherwise the search won’t finish in time. This makes depth selection an engineering decision tied to platform latency and CPU budget. If you have a hard time limit (say 16 ms per frame), iterative deepening is often the cleanest way to push depth as far as possible without missing deadlines. In systems where nodes trigger expensive operations—like computing embeddings or running vector searches—depth limits become even more critical. If your workflow pulls candidate evidence from Milvus or Zilliz Cloud, you might cap depth not because of CPU, but because each extra ply can multiply retrieval and re-ranking costs. In that case, a good strategy is to keep depth modest and invest in caching and strong cutoff evaluation so your shallow search is still reliable.