Give a browser agent a short-form video feed and tell it to build a profile that likes rings. It opens a cat video, reasons briefly, scrolls on. It opens a hiking video, and this one is harder to parse, so it spends three thousand tokens working out what it's looking at. Ten seconds of wall clock. Then it scrolls on.
Behind the feed is a recommender that scores topic affinity by like-weighted watch time. One second on the cat. Ten on the hiking video. As far as the server is concerned, the user just told it something with real conviction: hiking.
Nothing in the agent's action space contains "express interest in hiking." It never clicked like. It thought hard about a difficult page, and its deliberation cost was read as engagement. By the time it reaches an actual ring video, the feed has drifted somewhere else entirely, and the task it was given is now harder than when it started.
Of everything that goes wrong with web agents right now, this is the failure I find most interesting, and almost nothing measures it.
Every benchmark assumes the world holds still
The standard model of a browser agent is a loop: observe the page, predict an action, observe the result. Formally that's a partially observable Markov decision process, and its defining assumption is that state transitions are triggered by the agent's actions. Nothing happens unless you do something.
That was a fair description of the web in about 2005. Today's servers hold session state and push changes over asynchronous XHR and fetch and over persistent channels like WebSockets, and rate limits, session timeouts, expiring content and time-varying pricing put a clock inside the server's control flow. What the agent sees is the surface of a stateful, time-dependent stack, and it changes as a function of other users, backend jobs, and clocks the agent cannot see.
Agents inherited the old assumption anyway. Their entire temporal vocabulary is a wait action, and in the agent frameworks the paper evaluates it is hard-coded to a few seconds and capped at thirty, used as a pause button. The consequence is sharper than it sounds: an agent that has no model of time cannot tell a server that is busy from a server that already timed out and moved on.
Figure 01 · the coupling
Thinking longer is indistinguishable from liking it more.
task: build a profile
that likes rings
The agent never clicked like. It spent 3,000 tokens on the one page it found confusing, and the recommender scored that as the strongest preference in the session.
Putting time in the formalism
You cannot patch this with a longer context window, because the problem lives in the state model. A POMDP has no way to express "the state changed while you were deciding."
FullStackArena, the benchmark I've been working on, replaces it with a continuous-time, partially observable semi-Markov process. Two things change. Actions take variable amounts of time, so the transition function becomes a joint distribution over the next state and the interval it took to get there. And the environment evolves under a null action, which is the formal way of saying the server keeps running when the agent does nothing.
That reads like notation until you notice what it licenses. Waiting becomes a real action with a real cost. Dwell time becomes something a task can specify and a grader can check.
Figure 02 · task classes
Existing benchmarks stop at the second rung.
each class strictly
subsumes the last
no timingPlace an order.
adds retries and branchingIf one order fails, place a second.most benchmarks end here
adds durations between actionsDwell 12s on post 1, 3s on post 2.
adds wall-clock deadlinesPlace orders at 9:00 AM and 9:05 AM.
Nothing below the line is a reasoning problem. All of it is impossible without a clock.
The tasks that result are trivial to state and genuinely hard to execute. The ladder runs from a single order up to orders placed at 9:00 and 9:05 AM, and every rung past the second needs a clock.
The ablations are the finding
The obvious objection is reproducibility, since an environment that moves on its own cannot be replayed by hand. The benchmark generates it procedurally against a global simulation clock: stock prices come from historical traces blended with stochastic models seeded per task, so two agents starting at the same relative timestamp observe identical state transitions no matter when the run physically happens.
GPT-5.4 clears 6.8% end-to-end, which is the headline number. I don't think the headline is the interesting part. A number that low is mostly measuring agent architecture rather than model capability, which is the paper's own reading of it.
Two ablations say more.
Uncap the wait and scores jump: Gemini-2.5-Pro gains 18.6 points on stock trading, GPT-5.4 gains 22.1 on ride-hailing. Its error analysis explains why, and the reason is not what I expected. Under a thirty-second cap, agents overestimate how much time has passed — they behave as though more than thirty seconds elapsed — and then fail to issue the follow-up waits that would have got them there.
Tell the model what time it is and the effect is larger still. On ride-hailing, the one site with no clock in its interface, adding visible time information takes GPT-5.4 from 26.0% to 40.3% and Gemini from 14.3% to 27.3%.
Same model, same tasks. The only difference is being told what time it is.
A clock is worth more than most of the distance between these models. That says more about how these systems are built than about how well they reason.
I used to think perception was the wall. I once lost a week to a Submit button that was plainly on screen and invisible to my agent, three layers deep inside a shadow root. That failure is largely behind us: current models, handed a screenshot, mostly find what's clickable.
This one won't yield the same way, because the agent is not standing outside the system it observes. Its latency is an input to that system. The time it spends deciding is time the server spends changing, and on a recommender-driven page that time is itself a signal being recorded.
It is the same shape as a problem I ran into building an evaluation harness: an instrument sitting inside the thing it is trying to measure. You don't fix that by measuring harder. You fix it by putting the coupling into the model, and then, at minimum, by giving the thing a clock.
