344 browser tool calls, 62.8 minutes, zero Clarity funnels saved

The work log line said 213 calls, 40.0 minutes, and the last thing the agent did was hit a hard budget of 211 calls and 252k tokens of context. It saved zero funnels.

We had sent two browser-driver dispatches to set up three funnels in Microsoft Clarity, the analytics tool we use to measure activation on our platform. A person does this by hand in about five minutes: dashboard, Funnels tile, New funnel, pick the steps, save. We wanted an agent to do it instead, twice in a row. By the end we had burned 344 tool calls and 62.8 minutes and had nothing to show for it.

Where the 344 calls went

We bucketed both transcripts by keyword, and it wasn’t close. Real task actions, the navigate/fill/click/select calls that moved the funnel forward, were 97 calls and 15.8 minutes. Everything else, 247 calls and 47 minutes, was our own overhead:

• screenshot-then-read-the-png pairs (78 calls)
• DOM spelunking with querySelectorAll hunts, because there was no accessibility tree to query (66 calls)
• an 8-call, 8.7-minute wait on our own MCP identity lock
• viewport resets, JSON escaping through Bash heredocs, and a hand-rolled trusted-click harness

The site itself cost us almost nothing. A stale filter in Clarity’s Recordings view and some async regex validation that kept an Add button disabled added maybe 5 minutes, and even that only showed up after we had ruled out our own plumbing.

The site was expensive to reach because Clarity’s login only exists in the browser window we keep signed in on port 9222. Our profile pool doesn’t carry that cookie in any slot, and the only tool that can reach 9222 is a home-grown wrapper called chrome_script. That wrapper has no accessibility snapshot, no text or role targeting and no wait-until-enabled. It clicks with plain el.click() on the first DOM match it finds, hidden duplicates included. Every “click the button” turned into a five-step negotiation: screenshot, read the png, guess a selector, eval it, screenshot again to confirm.

The debrief that pointed the wrong way

Run B’s own debrief blamed part of the failure on viewport. It measured 663px on the signed-in tab and concluded that Clarity’s mobile layout has no funnel UI at that width. That is a checkable claim, and it was wrong. Run A had opened the create-funnel modal at that exact 663px width forty minutes earlier in the same session.

We only caught it by diffing the two transcripts against each other after the fact. At 13:20, run B spent 16 minutes and 83 calls re-finding a modal that run A had already reached and reported in prose at 13:07. Nothing about “step 1 succeeded” made it out of the first agent’s context and into the second’s.

The debrief had a second wrong explanation too: “Fluent buttons ignore JS .click().” A plain chrome_script click on button.eventPageVisitsAddButton worked fine. What stalled was the Add button staying disabled during Clarity’s async regex validation, which resolved on its own nine minutes later.

Neither stated root cause was correct. Acting on either would have sent the next fix in the wrong direction: hardening a click harness that wasn’t broken, instead of fixing the memory gap that cost 16 minutes.

What closed it

Both real causes traced back to us running our own browser tooling against a site with no cookie in our pool. So instead of upgrading chrome_script, we pointed the session at Microsoft’s own Playwright MCP, attached to the same Chrome window on 9222 that was already signed into Clarity.

There was no pool slot, no identity lock and no screenshot-then-read loop. It gets an accessibility snapshot natively, and it clicks by role and text instead of the first matching selector in the DOM.

Same site, same login, same three funnels. About ten minutes.

The fix was seeing that the 247 overhead calls, out of 344, were the cost of a tool that couldn’t see the page, built by us, for a login only one browser window had. Once the agent could see what it was clicking, the site stopped being the bottleneck. The other loss, the 16 minutes, came from a result that never travelled from run A to run B. When an agent takes far longer than a person would on the same task, look at the tooling it runs on and at how results pass from one run to the next.

dxdev LESSON · paste into your AI coding agent
LESSON: Give Browser Agents A Tool That Can See The Page, Not One That Guesses At It
SOURCE: dxdev.com/blog/344-calls-to-save-zero-funnels
WHAT HAPPENED: An agent was dispatched twice to create three funnels in Microsoft Clarity, a five-minute manual task, and burned 344 calls across both runs without saving anything. Bucketing the transcripts showed only 97 calls actually moved the task forward; the other 247 were screenshot-then-read loops, DOM selector hunts, and waits caused by chrome_script, a wrapper with no accessibility snapshot that clicks the first matching element via el.click(). The second run's debrief blamed a mobile viewport width and a supposed Fluent button click incompatibility, both wrong: run A had already opened the same modal at that width, and the real stall was an async validation delay. Switching to Microsoft's own Playwright MCP, attached to the same signed-in Chrome window, let the agent see the page via accessibility snapshot and click by role and text, finishing the same task in about ten minutes.
THE RULE: When an agent burns most of its calls on screenshot-read loops or DOM guesswork instead of task actions, the fix is to replace the blind tool with one that exposes an accessibility snapshot and semantic targeting, not to add retries or budget to the blind tool.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. Bucket agent tool-call transcripts by keyword to see what fraction of calls are real task actions versus screenshot/DOM/wait overhead
      2. Check whether the browser tool used exposes an accessibility snapshot and can target elements by role/text rather than first-DOM-match selectors
      3. Before trusting an agent's stated root cause for a stall, diff it against other transcripts or logs of the same task to confirm the claim is actually true
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.