Agents need semantic summaries because raw trace files can overwhelm their context and prevent useful reasoning.
2
Interface quality can be measured with tokens per successful outcome, while error messages and playbooks help agents recover without a human.
3
Tool descriptions, skills, and security boundaries need deliberate design because adding tools or removing friction can create new problems.
Summary
Michael Hablich explains how the Chrome DevTools team built an interface for coding agents and had to redesign it several times. Their first approach exposed large performance traces as tens of thousands of lines of JSON. Agents could not reason over that volume, so the team added Markdown and semantic summaries that pointed to relevant metrics. The team then measured interface efficiency with tokens per successful outcome, separating token cost from whether the task was completed. Hablich also covers recovery through useful errors, proactive detours, and troubleshooting skills. Tool discovery created another problem when one monolithic tool became 25 separate tools. Better descriptions and carefully scoped skills helped agents choose among them. The final section explains why autoconnect keeps a consent step. In browser automation, convenience can cross trust boundaries, especially when prompt injection and sensitive browser data are involved.
Chrome DevTools initially sent agents large performance trace files containing multiple megabytes and about 50,000 lines of JSON. The team assumed models could handle the data because they were machines, but the traces consumed the context window and left the agent unable to reason effectively. They changed the performance tracing endpoints to return Markdown and semantic summaries. A summary can surface metrics such as largest contentful paint and point the agent toward the relevant finding. Hablich describes this as pointing the agent at the right sentence instead of making it read the entire book.
Agents and humans share goals but have different bottlenecks
Hablich argues that agents are a separate user segment. Humans and agents can have the same intent, such as finding and fixing errors on a web page, while processing information differently. Humans depend heavily on visual signals such as layout and color. Agents need interfaces that expose the relevant information in a form they can inspect and act on. This changes how a developer tool should present data. The tool has to account for the agent's cognitive bottlenecks rather than simply exposing the same information that a human sees in DevTools.
Tokens per successful outcome measures interface fuel efficiency
The team separates effectiveness from efficiency. Effectiveness asks whether the agent completed the user journey and fulfilled the functional intent. Efficiency covers token cost, tool calls, and duration. Their metric, tokens per successful outcome, combines the fuel used by the interface with whether the agent reached its destination. Hablich warns that the metric should be compared within a user journey or task class. Web scraping may be relatively cheap, while debugging a responsive layout can require more tokens because the session is more interactive. Even imperfect measurement is better than decisions based only on intuition.
Tool exposure changes token cost and agent capability
Chrome DevTools for Agents reduces unnecessary context in several ways. Niche tools, such as Chrome extension debugging tools, can be hidden behind command-line parameters. Slim mode exposes only select page, navigate page, and evaluate script. That saves context, but the agent may need extra turns or may lack a tool it needs, such as one for retrieving network requests. The team also provides a command-line interface. Agents can pipe the result of one command into another, such as extracting an accessibility tree with grep and passing a control ID into a click command. Local post-processing avoids sending all those tokens through the model.
Every failed tool call can cost tokens because the agent must understand the failure and retry. Hablich gives an example from page history navigation. The original error said, "Unable to navigate back in currently selected page." The revised message explained that no previous page existed in the history. That extra information allowed the agent to self-heal without a human fixing the problem. Chrome DevTools for Agents also uses proactive detours, such as sending performance profiling requests to start performance trace instead of Lighthouse audit, and diagnostic playbooks such as a troubleshooting skill for setup problems.
Splitting one tool into many creates a discovery problem
The first Chrome DevTools agent interface exposed one monolithic tool called debug_webpage. It was simple to build, but agents did not reliably use it for concrete tasks. The team decomposed it into 25 focused tools, then found that agents had no dependable way to choose among them. Hablich cites research reporting that 97% of MCP tool descriptions have quality smells and says the schema is the agent's user interface. Descriptions should state the tool's purpose and clear activation criteria. The performance start trace description names front-end performance issues and metrics such as LCP, INP, and CLS, giving the agent signals for when to select it.
More descriptions and skills bring their own costs
Improving tool descriptions increases their context size, and smaller models can become biased toward tools they should not use when they receive too much description text. Hablich describes this as a trade-off space rather than a problem with one permanent answer, since models and agent harnesses keep changing. Skills can help with intricate workflows, but piling on too many skills recreates the same discovery problem. Agents may call skills when they should not, and the context window grows. The team is still searching for a minimum viable description for each tool.
Autoconnect lets a human share an active Chrome screen with an agent for debugging. Users asked the team to remember their approval so they would not need to click allow each time. Hablich says the team kept that friction because browser agents can cross trust boundaries. He discusses three settings: local development with a human in the loop, controlled CI environments with separated data and Chrome profiles, and agents with full internet access. The last setting needs domain allow lists and prompt injection mitigations. A local agent and a browsing-agent fleet may use the same tool, but they should not share the same security model.
"What tokens per successful outcome tell you is the fuel efficiency of your interface."08:38
Who should watch
You are building an MCP server or CLI interface and need agents to choose tools without wasting context.
Your agent can call tools but gets stuck on errors, retries needlessly, or depends on a person to recover.
You are connecting browser automation to local data, CI systems, or the open internet and need to reason about consent and prompt injection.
