344 Tool Calls to Save Zero Funnels, Then Ten Minutes

The alert wasn’t an alert. It was a work log line: 213 calls, 40.0 minutes, and the last thing it did was hit a hard budget of 211 calls and 252k tokens of context. It saved zero funnels.

We’d 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, and by the end we’d burned 344 tool calls and 62.8 minutes and had nothing to show for it.

Where the 344 calls actually went

I bucketed both transcripts by keyword and it wasn’t close. Real task actions, the navigate/fill/click/select calls that actually moved the funnel forward, were 97 calls and 15.8 minutes. Everything else, 247 calls and 47 minutes, was us: screenshot-then-read-the-png pairs (78 calls), DOM spelunking with querySelectorAll hunts because there was no accessibility tree to query instead (66 calls), an 8-call, 8.7-minute wait on our own MCP identity lock, plus 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 I’d ruled out our own plumbing first.

The reason the site was expensive to reach at all: 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, no wait-until-enabled, and 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 wrong turn, and what it cost

Run B’s own debrief blamed a chunk of the failure on viewport: it measured 663px on the signed-in tab and concluded Clarity’s mobile layout has no funnel UI at that width. That’s a real, checkable claim, and it was wrong. Run A had opened the create-funnel modal at that exact same 663px width forty minutes earlier in the same session. I 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 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 actually stalled was the Add button staying disabled during Clarity’s async regex validation, which resolved on its own nine minutes later. Neither of the agent’s stated root causes was the real one. Trusting 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 actually cost 16 minutes.

What actually closed it

Both root 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. No pool slot, no identity lock, no screenshot-then-read loop: it gets an accessibility snapshot natively and 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 wasn’t a smarter agent or a longer budget. It was recognizing that 182 of 344 calls 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 actually see what it was clicking, the site stopped being the bottleneck it never really was.

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/2026-09-22_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.