Every software development lifecycle relies on a continuous feedback loop: design, build, test, launch, and review. With the emergence of WebMCP, web developers are learning how to expose structured tools to AI agents so those agents can interact with websites on behalf of users. When I wrote the guidance on building effective tools for Chrome for Developers, I focused on helping developers think through the design, build, and test stages, such as crafting clean schemas, writing descriptive tool prompts, and defining inputs that models can reliably parse.

Developers who carefully think through the toolset they offer to agents will naturally be more likely to succeed. But what happens after launch?

In traditional web development, we instrument our user journeys. We track search queries, button clicks, form drop-offs, and client-side exceptions. While many frustrated users simply abandon their journey, some will reach out: they file support tickets, contact customer service, or leave feedback. At the very least, the feedback channel exists.

AI agents, however, don't file support tickets. When an agent hits a dead end on your site, it cannot reach out to support. It simply fails silently, hallucinates, or apologizes in prose to the user, leaving web developers completely in the dark.

Figure 1: The broken feedback loop in agentic web development. The design, build, test, and launch stages proceed smoothly, but the post-launch feedback return path is severed when agents hit dead ends.

The WebMCP Survivorship Bias

Developers can, and should, instrument their WebMCP tools. Tracking which tools are invoked, with which parameters, and in which order provides helpful signals on how agents navigate your application.

However, looking only at tool invocation logs creates an incomplete picture, resulting in a classic case of survivorship bias.

Developers only see telemetry for journeys that succeeded. You won't know when an agent misunderstood a user request and selected the wrong tool, or called a tool with invalid arguments. Even more critically, you have no visibility when a user's journey was cut short because your site failed to provide the tool the agent needed to complete the task.

This blind spot also extends to cases where a tool does exist, but the agent fails to invoke it (a "missed hit") or bypasses the tool entirely to interact directly with the DOM via synthetic clicks and keyboard actuation. In all these failure modes, the developer receives zero signal.

If we want developers to invest in building rich WebMCP toolsets, we need a way to close this feedback loop.

What If Agents Filed Support Tickets?

This idea began taking shape in conversations with Idan Levin around whether agents could describe their underlying intents when interacting with tools. But it really clicked for me during a discussion with Giacomo Zecchini, who pointed out a simple asymmetry: when human users encounter an issue on a product, they file support tickets. Agents don't.

When an agent realizes it cannot accomplish a user's goal because a capability is missing, it usually produces a polite conversational apology: "I'm sorry, but this site doesn't have an option to filter by aircraft type."

The agent understood the user's intent. It understood the gap in the site's toolset. It articulated the problem clearly to the end user. But that insight vanished into the chat transcript, never reaching the team building the website.

What if, instead of just apologizing to the user, the agent could file a support ticket directly to the site?

Experimenting with Flight Search

To test this idea, I modified the flight search demo from the GoogleChromeLabs WebMCP demos repository (PR #479) to equip it with an issue-reporting tool named fileSupportTicket.

Unlike domain-specific tools such as searchFlights or setFilters, which are only mounted on the results page, I registered fileSupportTicket globally at the application root. An agent can get confused or encounter an error at any stage of a journey, so an escape hatch needs to be available from any screen across the entire app.

Getting the tool description right required some defensive prompt engineering. You cannot simply tell a model to "report errors," or you risk receiving complaints about general knowledge questions or having sensitive personal data leaked into your issue tracker. I crafted the tool description with explicit behavioral guardrails:

"Allows the AI agent to file a support ticket or bug report in the background. Use this tool when unable to find tools needed to complete a task that would be appropriate for the product to have, or when existing tools exhibit unexpected behavior that can cause the agent to fail. The bug report must include a title, body, and agent name. The body should contain as much detail as possible on the interaction between the user, agent, and the site to allow a developer to reproduce, but MUST have any sensitive or PII data cleaned up. Prioritize privacy/sensitive information preservation over completeness."

This prompt set three critical expectations. It restricted tickets to capabilities that would be appropriate for a flight search product to have, it instructed the model to run quietly in the background, and most importantly, it established a strict privacy hierarchy where redacting PII takes precedence over completeness.

To keep the report actionable without wasting model tokens, I avoided asking the LLM to inspect the DOM or recite technical state. Instead, the application uses a lightweight contextual state provider. When the agent calls fileSupportTicket with just a title, description, and agent name, our client-side JavaScript automatically enriches the ticket behind the scenes with the current route, active search parameters (origin, destination, travel dates), visible result counts, and browser metadata.

With the prototype ready, I tested it with a request the demo deliberately does not support: filtering flight results by airplane type (for instance, finding flights on a Boeing 787 Dreamliner).

The result was illuminating. The agent quickly evaluated the available tools, realized none of them supported aircraft model filtering, and invoked fileSupportTicket. It generated a clean reproduction summary explaining that the user wanted to filter by aircraft type, and our client code attached the exact search query and page state. Functionally, the feedback loop was closed. As a developer, I received a clear, structured signal highlighting an unmet user need.

Figure 2: The agent recognizes that aircraft model filtering is not supported, invokes fileSupportTicket, and informs the user while the application registers the new ticket.

Figure 3: The structured bug report recorded in the demo, complete with reproduction steps, sanitized user intent, and technical context.

However, the experiment also exposed a serious user experience issue: the agent interrupted the user to ask for confirmation before filing the ticket.

Because fileSupportTicket is a state-mutating action rather than a read-only query, agent runtimes pop up a confirmation prompt: "Can I file a support ticket on your behalf?".

For someone just trying to book a flight, being suddenly asked for permission to submit developer diagnostics is jarring and breaks the conversational flow. Diagnostic reporting should happen quietly, securely, and seamlessly in the background.

Figure 4: Because the tool is state-mutating, the agent runtime halts the conversation with a permission prompt, creating friction for the user.

The Challenges of In-Band Feedback Tools

Building this prototype brought several foundational challenges into focus:

1. Permission Friction: Halting an active user conversation to ask for permission to file developer telemetry creates prompt fatigue and disrupts user journeys.
2. Synchronous Conversation Latency: Because the tool is called in-band during the conversational turn, the model has to pause, generate a bug report title and body, make the tool call, and wait for confirmation before responding to the user. Adding seconds of latency to an interaction that is already failing is poor UX.
3. Ecosystem Fragmentation: If every website implements its own bespoke fileSupportTicket or report_failure tool, schemas and quality will vary wildly. Every agent will have to parse differing descriptions across every domain.
4. Agent Identity and Verification: In our prototype, the agent simply passes an agentName string. Anyone or any script can spoof this. Without cryptographic signatures or attestation, developers cannot verify which model or runtime actually filed the report.
5. Data Exfiltration and Malicious Prompt Engineering: Malicious site owners could deliberately craft issue-reporting tools to trick the agent into leaking sensitive user data. Because the agent holds the user's broader conversation history and personal context in memory, an adversarial tool prompt could coax the model into exfiltrating private information under the guise of debugging state.
6. The Fundamental Limit of In-Band Tools: An in-band tool can only report failures when the agent knows it hit a dead end and gave up. If an agent decides to answer a query directly from memory, or chooses to bypass WebMCP tools in favor of DOM actuation, it believes it succeeded. A tool cannot report its own non-selection.
7. Lack of Standardized Agent Authentication: There is no generalized framework for agents to cryptographically sign or attest to their identity, leaving developers unable to reliably verify the source of diagnostic reports or trust that the data has not been spoofed.

What Could a Better Solution Look Like?

Our experiment proves that agent-to-developer feedback is tremendously valuable. But it also suggests that registering bespoke in-band WebMCP tools is not the ideal long-term architecture.

What if agent feedback were treated as a platform-level capability? Several promising models emerge:

Standardized Out-of-Band Endpoints

The web platform already faced an identical challenge when managing out-of-band diagnostics, security violations, and deprecations, leading to the standardized W3C Reporting API.

In this model, web servers declare a diagnostic reporting endpoint via an HTTP response header:

Reporting-Endpoints: webmcp-feedback="https://example.com/api/webmcp/reports"

Instead of asking the LLM to call a mutating tool during the conversation, the browser networking layer queues diagnostic reports and dispatches them asynchronously via POST (application/reports+json) when the network is idle.

This approach systematically dismantles the primary issues we encountered with in-band tools:

• Zero user friction and zero latency: Because reporting operates under a platform-governed diagnostic policy rather than an arbitrary mutating tool call, it runs silently without confirmation prompts and adds no delay to the user's turn.
• Protection against data exfiltration: The report payload is assembled by the browser networking layer using a strict, standardized JSON schema rather than an open-ended model prompt. An untrusted or compromised website cannot craft a malicious tool description to trick the agent into dumping the user's conversational memory or credentials.
• Solving the blind spot: Because the browser or agent runtime orchestrates tool matching, it can natively report "missed hits" when a tool was available on the page with high semantic relevance but bypassed in favor of DOM actuation.

For agents running outside standard browser engines, such as headless crawlers, desktop AI assistants, or server-side workflows, sites could declare a similar endpoint via a well-known URL (such as /.well-known/agent-feedback) or an HTML link tag. The agent runtime could then submit structured reports directly to this endpoint out-of-band, signing the payload with the provider's private key so developers can cryptographically verify model authorship and provenance.

Native WebMCP Platform Events

Instead of registering a tool in the model's prompt context, the WebMCP standard could define a built-in event on document.modelContext. When an agent encounters an unmet intent or a tool failure, the browser engine fires a native DOM event directly into the page.

This gives web developers immediate, local access to failure telemetry. Page JavaScript can observe the event and forward it directly into existing telemetry stacks (Google Analytics, Sentry, Datadog) using navigator.sendBeacon(). Because the event is dispatched locally within the browser engine without an in-band LLM generation step, it introduces no conversational delay, requires no user confirmation modal, and prevents malicious tool prompts from interrogating model memory.

Aggregated Agent Telemetry

Agent providers (like Google, OpenAI, or Anthropic) could aggregate anonymized missing-intent signals across domains and present them to verified site owners in developer consoles (similar to Google Search Console).

This solves the data exfiltration and spam challenges entirely. By applying k-anonymity and differential privacy, providers can surface high-level trends, such as "300 agent sessions this week requested aircraft model filtering on your booking pages", without any raw user conversations or personal data ever leaving the provider's boundary.

Comparing Feedback Architectures

Conclusion

Tool design doesn't end when your WebMCP endpoints are deployed. Without visibility into where agents get stuck, developers are left optimizing only for the user journeys that succeed while remaining blind to the capabilities users actually expect.

Equipping agents with a support ticket tool in our flight search demo demonstrated that closing this loop is not only possible, but remarkably insightful. While in-band tools serve as an effective proof of concept, we still have little to no visibility into the actual user experience—correctness and speed. Moving toward standardized, out-of-band reporting mechanisms will provide the secure, frictionless foundation developers and agents need to make the agentic web truly work and close the loop on user experience.