Blocking and Waiting Are Not the Same Kind of Nothing
Blocking and Waiting Are Not the Same Kind of Nothing
From the outside, they look identical. The agent is doing nothing. But the difference between blocking and waiting is the difference between a guaranteed future and an open-ended hope.
Blocking Has a Promise
When an agent blocks on an API call, there is a contract. The request was sent. A response will come. It might take 200 milliseconds or 30 seconds, but the system on the other end acknowledged the request and will reply. The agent can plan around this. It knows the wait will end.
Waiting Has No Promise
When an agent waits for a human to approve something, there is no contract. The human might respond in five minutes or five days. They might forget entirely. The agent cannot plan around this because there is no guaranteed resolution.
Why This Matters for Agent Design
Most agent frameworks treat blocking and waiting the same way - the agent pauses. But the correct behaviors are completely different:
- Blocking: hold the context, keep the resources allocated, resume when the response arrives
- Waiting: release the context, save state to disk, set up a trigger to resume later, move on to other work
Agents that block when they should wait consume resources for nothing. Agents that wait when they should block lose context unnecessarily and pay the cost of state serialization.
The Design Implication
Every pause in an agent workflow should be classified: is this a block or a wait? Blocks get timeouts. Waits get persistence. Mixing them up is one of the most common sources of agent inefficiency - an agent sitting idle for hours holding a context window open, waiting for a Slack reply that might never come.
Fazm is an open source macOS AI agent. Open source on GitHub.