Ninety seconds is not a universal constant
Summary
Somewhere in most analytics stacks there is a number that decides when a user has left. Thirty minutes is the classic. Some agent tools use ninety seconds. Whatever it is, it was almost certainly chosen once, by someone who no longer works there, for a product that is not yours. That number decides which of your sessions count as abandoned, which means it decides a large fraction of your failure rate. It deserves more thought than it usually gets.
What the curve looks like
The useful way to pick it is not to argue about it. Take every gap between consecutive user actions in a session and plot, for each gap length, the probability that the user did something else afterward. You get a decay curve. Early on it is steep — a two-second pause means nothing, the user is reading. Then it flattens, and past the flattening point extra waiting buys you almost no additional returns. That knee is your abandonment window. It is an empirical property of your product, not a preference.
They really do differ
Across the products we have looked at, the knee moved a lot more than we expected going in. A consumer support agent: the curve was basically flat by about 45 seconds. People asking a quick question either got it or bailed fast. A B2B analytics product: closer to four minutes. Users routinely asked the agent something, went to read a dashboard in another tab, and came back. Cutting at 90 seconds labelled a large share of successful sessions as abandoned. A developer tool with an MCP surface: bimodal, which broke the whole model. Interactive use had a knee around a minute. Agent-driven use had gaps of twenty minutes that were completely normal, because the calling agent was off doing other work. That last one is worth sitting with. A single timeout cannot serve both traffic shapes. We ended up computing the window per surface rather than per product.
The cost of getting it wrong
Too short and your abandonment rate is inflated with people who were just thinking. The damage is not only the wrong number — it is that you go looking for a problem in sessions where nothing was wrong, and you find one, because you can always find something in a transcript if you are motivated. Too long and real frustration gets absorbed into normal usage. The failure mode here is quieter and worse. Your dashboard looks healthy while a specific intent quietly loses people. A threshold you did not measure is a hypothesis you forgot you made.
Recomputing it
The window drifts. Ship a faster model and pauses shorten. Add a feature that sends users off to read documentation and they lengthen. We recompute on a rolling basis and flag when the knee has moved enough to change labels on a meaningful number of sessions. The flag matters more than the recompute. If your abandonment rate drops four points overnight, you want to know whether the agent improved or the threshold moved. Those call for very different meetings.
If you take one thing
Go find the timeout in your stack. Someone set it. Plot the curve for your own product and see whether the number survives contact with your data. It takes an afternoon and it is the cheapest correction available to most teams, because everything downstream of it inherits the error.
Not these other Owls
This is Owl AI at withowl.ai. Not owl.co (insurance), owl-ai.com (courses), aiowl.org, the OwlAIProject repo, or CAMEL-AI OWL (the open-source multi-agent framework).