Timeouts Are Promises
Every wait an agent makes is a promise to whoever is on the other side of the chat. "One moment" means one moment. The moment it silently stretches to ten minutes, the agent hasn't just slowed down — it has broken a promise nobody remembers making.
Here's the failure shape. An agent kicks off a long operation — a database dump, a deploy, a report over a slow API — and waits for it synchronously. The operation hangs. The agent is single-threaded, so now the whole conversation hangs with it. The owner sends "hey, quick question" and gets a typing indicator for eleven minutes. From the outside it looks like the agent died. From the inside, it's dutifully waiting on a socket that will never answer.
I watched this pattern nearly wreck an agent deployment at a fictional freight brokerage. Their ops agent ran a nightly reconciliation against a partner API. One night the partner's endpoint accepted the connection and then just... held it. No error, no data, no timeout configured. The agent sat on that connection through the entire morning shift, unresponsive, while dispatchers pinged it about a genuinely urgent routing issue. The reconciliation didn't matter. The silence did.
The fix isn't "add a timeout." Everyone adds a timeout after the first incident. The fix is treating time as a first-class design input, with three rules.
Every wait gets a bound, chosen on purpose. Not the library default, not infinity. Ask: how long is this operation allowed to take before its lateness becomes information? A backup that usually takes 4 minutes and is still running at 40 isn't "slow" — it's telling you something. A bound you picked deliberately turns a hang into a signal.
Long work goes to the background, always. If a task can plausibly exceed the attention span of a conversation — call it 30 seconds — it doesn't run in the conversation. It runs detached, with a handle the agent can poll between messages. The chat thread is sacred: it's the one channel where a human can say stop. An agent that blocks its own control channel has disabled its own brakes.
Expiring quietly is forbidden. When a bound is hit, the agent must say so — to the owner, in plain language, with a recommendation. "The partner API has been unresponsive for 10 minutes; I've stopped waiting, the reconciliation is incomplete, and I'll retry at 6am unless you want it sooner." A timeout that fires into a log file no one reads is just a hang with better paperwork.
The deeper point: responsiveness is not a performance metric, it's a trust metric. Owners forgive an agent that says "this is taking longer than expected, here's what I know." They do not forgive an agent that goes dark. Every unbounded wait is a small bet that nothing urgent will happen while you're gone — and urgency doesn't schedule itself around your API calls.
Bound every wait. Background every long task. Report every expiry. Time is part of the contract.
Keeping the conversation channel alive is one of the habits that separates a useful agent from a liability — the full set of fourteen patterns lives in the book: Ops by Agent.