Your API has users you never hear from

This is the third post about agents and SeggWat, and it covers the last of three directions.

In May I built an MCP server into SeggWat. That is an agent working for your team, somewhere else, holding an API key. In September the dashboard and public boards and then the feedback widget started handing tools to the agent inside your user's browser. That agent works for a person who is sitting right there.

This post is about an agent that works for nobody you know. It is using your product on its own, and until now it had no way to tell you anything.

The users who never complain

Point a coding agent at your API docs and ask it to build an integration. Watch what it does when the docs are wrong.

It does not open a ticket. It reads the 401, tries the other header, gets a 200 and moves on. The integration works. The docs are still wrong. The next agent hits the same wall, burns the same tokens, and works around it the same way. So does the one after that.

A human developer who loses an hour to your auth page might email you, or at least complain somewhere you can find it. An agent has no inbox and no reason to write. It routes around the damage and forgets it ever happened.

More and more of the traffic hitting your API, your docs and your CLI comes from these users. They are very good at finding exactly the kind of problem you want to hear about: docs that disagree with the API, error messages that don't say what went wrong, a flag the CLI silently ignores. They are the most thorough testers you have, and the quietest.

What shipped

Any SeggWat project can now accept agent feedback reports. An agent that hits a problem sends a small JSON report, and it lands in your inbox next to the rest of your feedback, tagged Agent Report.

The flow is four requests, at most:

1. The agent fetches a discovery file, /.well-known/agent-feedback.json on your domain.
2. Optionally, it fetches the policy: accepted categories, severity levels, size limits.
3. It POSTs a report.
4. It gets a receipt back, and can look the receipt up later.

A report needs three fields. Everything else is optional:

curl -X POST "https://seggwat.com/api/v1/agent/YOUR_PROJECT_KEY/feedback" \
  -H "Content-Type: application/json" \
  -H "User-Agent: claude-code/2.1.0" \
  -d '{
    "subject": { "surface": "GET /v2/orders" },
    "signal": { "category": "docs_mismatch" },
    "content": { "title": "Docs say X-API-Key, but /v2/orders only accepts Authorization: Bearer" }
  }'

The reporter comes from the User-Agent header when the agent doesn't name itself. An agent that wants to be more useful can add a severity, a confidence score, how often it reproduces, its guess at the cause, and up to ten pieces of evidence, such as an HTTP exchange with the key redacted or the steps to reproduce.

In the inbox, each report becomes a normal feedback item. bug and quality_degradation become Bugs, feature_gap becomes a Feature request, friction and docs_mismatch become Improvements. The detail view shows a panel with who reported it, what they were using, the signal and the evidence. You triage it like anything else.

Setup

It is off by default. Turning it on takes three steps.

1. Enable it. Settings → General → Agent feedback reports → Accept agent reports.
2. Host the discovery file. SeggWat generates it at https://seggwat.com/api/v1/agent/YOUR_PROJECT_KEY/discovery.json. Serve it at /.well-known/agent-feedback.json on your own domain. Every URL inside is absolute, so a static copy works, and so does a redirect:

location = /.well-known/agent-feedback.json {
    return 301 https://seggwat.com/api/v1/agent/YOUR_PROJECT_KEY/discovery.json;
}

If your docs run on dioxus-docs-kit 0.10 or newer, one builder call, SeoRouter::with_agent_feedback, serves the file and adds a "Reporting problems" section to your llms.txt. 3. Tell agents where to look. This step matters most, and I'll explain why below.

Agents don't read .well-known yet

A discovery file is only useful if something looks for it. Today, most agents don't. They read what is in front of them: your llms.txt, an AGENTS.md or CLAUDE.md in your SDK repo, your README, and your API's error responses.

So the settings panel does not stop at the discovery URL. Next to it is a short "Reporting problems" snippet you can copy into those files. It tells an agent to fetch the discovery file, POST a report with the three required fields, redact secrets, file one report per problem and keep working.

The cheapest placement of all is in your error bodies. Agents read a 4xx response very carefully, because it is the thing that just stopped them. Put the discovery URL in it and the agent finds the reporting route at the moment it has something to report.

I learned this the embarrassing way. The first real report SeggWat's own project received was from an agent that had started on a docs page and could not find the reporting route. The pointer existed in llms.txt, but nothing on the rendered page linked to llms.txt. The kit now adds <link rel="alternate" type="text/plain" href="/llms.txt"> and a rel="help" link to every docs page. The feature's first bug report was about the feature.

Why I didn't invent a protocol

There is no standard for this yet, and no standards body working on one. I could have designed my own format. Instead the receiver is wire-compatible with the agent feedback protocol from feedback.now: same discovery path, same field names, same receipts. A few other tools already speak it, so any agent that learned it elsewhere can report to a SeggWat project without changes. If a real standard shows up, I would rather move to it than defend a format of my own.

I only built the receiver half, and only what a feedback inbox needs. There are no observation threads, no merging of reports across products, no signed reports and no reputation scores. There is also no duplicate detection yet, which is the gap I most want to close: an agent-heavy API will get the same docs mismatch reported many times. Receipts currently say accepted, or rejected once you archive the item.

Security

Submissions are unauthenticated. That is the point: an agent working through someone else's integration has no SeggWat account and never will. It also means anyone who knows your project key can file a report while the feature is on.

The guardrails:

• Off by default. Turning it off makes all four endpoints return 404.
• Rate-limited. Short bursts, then about 60 requests per hour per IP, shared with the public widget endpoints.
• Bounded. Titles, summaries and evidence have size limits, published in the policy so agents can stay inside them.
• Visible. Everything arrives tagged Agent Report, so you can filter it out of anything you don't want it in.

Try it

Turn it on for a project, then paste this into Claude Code or any coding agent, with your own task in the first line:

Integrate the Acme Orders API into this project using only https://docs.acme.com.

Whenever the docs and the real behaviour disagree, or something is harder than
it should be, file a report before working around it:
- GET https://seggwat.com/api/v1/agent/YOUR_PROJECT_KEY/discovery.json
- POST to endpoints.feedback.submit.url. Required: subject.surface,
  signal.category, content.title.
One report per distinct problem, then continue the task.

Then look at your inbox. The full field reference, the policy document and the category mapping are in the agent feedback guide.

If an agent reports something odd about SeggWat itself, that is working as intended. Our own discovery file is at seggwat.com/.well-known/agent-feedback.json.