Our GTM agents drive a real Chrome browser through one shared browser-control tool. They use it to read pages, click through sign-up flows, and fill forms while they research prospects and do outreach. Every browser action is expected to either do the thing or say why it couldn’t.
On September 13, the tool’s p50 latency dropped from 30.1 seconds to 1.1 seconds. In the same window, its error rate went from 2.4% to 6.2%.
Those two numbers describe the same change. Most of the old 30-second calls hung for a while and then worked. Most of the new 1-second calls failed right away.
The errors were mostly one message: the tool was trying to act on a page that belonged to a different browser extension than the one the run had attached to. A related tool we use to batch browser actions had shown the same message six days earlier, with its error rate going from 4.2% to 19.1%.
How we caught it
We run Tessary on our own agents, and two of its classifiers fired on this tool. Duration drift compares a tool’s recent latency against its own baseline, and it flagged the drop in p50 as “faster”. Tool error compares failure rates week over week, and it flagged the rise. Both opened a finding on September 14 with the before and after numbers attached.
Either finding on its own is easy to dismiss. A latency finding labelled “faster” reads like good news, and an error rate going from 2.4% to 6.2% is easy to put off for a week. Together, on the same tool in the same window, with the errors pointing at the cause, they were clearly one issue. The tool got less reliable, and the latency chart hid it.
What we think caused it
Our best guess is that concurrent runs were sharing one Chrome profile and resolving actions against the wrong extension context. We haven’t confirmed that directly. We worked from the evidence in the findings and didn’t re-pull the traces, so treat it as likely rather than proven.
Where the fix is
We haven’t shipped a fix yet. The cause sits in upstream browser extension and session behaviour, not in code we can change ourselves. We’re looking at two mitigations:
- Check that the browser connection is alive and attached to the right tab before every action, so a bad connection fails fast and recovers on a fresh tab.
- Serialise browser use across agents, so runs stop sharing one profile at the same time.
Both touch every agent that uses the browser, so we haven’t made that call yet.
If you track tool latency
When a tool suddenly gets much faster, check its error rate over the same window before you count it as a win. A tool that fails fast looks fast. If you track p50 latency per tool, put the error rate next to it and look at what the quicker calls are actually returning.