Your visitors' AI agents can now draft feedback in the widget

Three weeks ago I wrote that the dashboard and public boards are agent-ready. That post ended with a promise: the feedback widget was a separate post. This is it.

The widget is the part of SeggWat your users actually meet. It sits on your site, not ours. So when it talks to an AI agent, it is talking to an agent that belongs to one of your users. That changes the design.

What shipped

The feedback widget now registers one WebMCP tool, send_feedback. An agent driving the visitor's browser can call it with two arguments:

• kind: bug or feature
• message: the report itself, up to 1,000 characters

The widget then opens its own form, on the right tab, with the agent's draft already in the text box. That is all the tool does. It does not submit anything.

The visitor reads the draft, fixes what the agent got wrong, and clicks Send. Or closes the form and nothing happens.

Why the agent can't press Send

On the dashboard, an agent acts for you, on your data, in your session. On a board, an agent votes the way a click votes. In both cases the person and the agent want the same thing, and a tool that acts directly is fine.

The widget is different. A bug report goes to a team the visitor has never met, under the visitor's name, sometimes with their email attached. An agent that got the wrong idea about which button was broken would send your team noise, and send it as your user.

So the tool stops one step short. The result it hands back to the agent says so plainly: the form is open, nothing is sent yet, the visitor must review it and click Send. The tool description asks the agent to tell the visitor the draft is waiting. A good agent will. A careless one still can't file anything by itself.

It costs the visitor one click.

Written for someone else's agent

Every word in the tool definition ends up in an agent's context, and that agent works for your user, not for you or me. So the tool is brand-neutral. It is called send_feedback, not seggwat_send_feedback, and its description talks about "the team behind this website". An end user asking their assistant to report a bug should not suddenly hear about a feedback vendor.

The description also does some quiet coaching. It asks for the visitor's own words, facts over adjectives, and for bugs: what they did, what happened, and what they expected. That is the report your team wishes every user wrote. An agent is better placed than most people to write it, because it just watched the whole thing happen.

You can tell which reports an agent wrote

Drafts sent through the tool arrive with the source Browser Agent instead of Widget. That holds even if the visitor rewrote every word. You can filter them, count them, and decide for yourself whether agent-drafted reports are better or worse than typed ones. I don't know yet which way that goes.

They still count in the widget funnel as a normal Opened → Submitted, because that is what happened: a person opened the form and sent it.

Why not the declarative API

In the last post I said the declarative half of WebMCP, where a plain HTML form becomes a tool through a few attributes, looked interesting for the widget. I ended up using the same registerTool call as everywhere else.

The reason is boring. The widget's forms don't exist until someone opens it. The floating button is all that lives in the page; the bug and feature forms are rendered into the modal on demand. There is no form for the attributes to sit on when an agent comes looking. Registering the tool in script also lets it check the input with the same validation the form uses, and return a clear error instead of a half-filled form.

Turning it off

It is on by default. Your options:

• Whole project: Settings → Widgets → Browser agent tools (WebMCP).
• One page: add data-agent-tools="false" to the script tag.

<script src="https://seggwat.com/static/widgets/v1/seggwat-feedback.js"
        data-project-key="your-project-key"
        data-agent-tools="false"></script>

The tool also only offers the kinds you have enabled. If you switched off feature requests, the agent only sees bug. If both are off, there is no tool. Browsers without WebMCP never see any of it; the feature check fails and the widget carries on as before.

Try it

WebMCP is still behind a flag. In Chrome 149 or newer:

1. Enable chrome://flags/#enable-webmcp-testing.
2. Install the Model Context Tool Inspector extension.
3. Open any page with the SeggWat widget, the demo for example, and call send_feedback from the inspector.

The form opens with your text in it. On your own site, clicking Send puts the report in your inbox, tagged Browser Agent.

The full attribute reference is in the widget docs. If an agent drafts something odd on your site, use the widget to tell me. A person will read it.