Your agent user cannot file a bug.

The world of agentic usage is changing too fast.

Somewhere in your product today, assuming you are among the ones leading this world rather than following it, there is now a user who will never fill in a survey. It reads your field names, follows your error strings, accepts whatever you set as the default, and forms something functionally equivalent to an impression of your product within about four hundred milliseconds. Then it acts. When it gets confused, it does not write an angry reddit post. It retries, or it picks the wrong endpoint, or it tells the human who called it that the task could not be completed. Grr.

The problem is that every research instrument we own is built for the real humans. Interviews, session recordings, satisfaction scores, the support inbox I have called an eval set, all of it assumes a user who can be asked, "does it suck?".

Human user, confused

Hesitates, clicks around, gives up, and eventually complains to somebody. Every one of those behaviours leaves a trace in a tool you already pay for.

Agent user, confused

Retries the same call with a slightly different argument, silently, at machine speed, and your dashboard reads it as healthy traffic because the status codes are fine.

What makes this a product problem rather than an engineering one is where you and I expect the solutioning to happen in the future. What agents actually need is well documented CLIs and better APIs, which is why the instinct in most organisations is to hand the whole surface to whoever owns the API, on the grounds that agents call APIs. But the things that decide whether an agent succeeds are not questions about the API contract, they are the same questions we have always asked about interfaces. Is this parameter named the way a stupid 4B parameter agent would guess, does the error say what to do next rather than only what went wrong, and is the destructive option sitting right next to the safe one, sorted alphabetically, waiting for a bad guess?

We spent twenty years treating error copy as the bleh that nobody bothers about, done in a hurry by engineering. It has quietly become one of the most consequential surfaces in the product, because it is now instructions, read by something that will act on them immediately and has no way to ask a second question once it has read them.

I do not think this belongs to a new role. I think it belongs to the designer and the PM who already own the rest of the interface. The relatively awkward part of that claim is that almost none of us have looked at our own error strings this year.

I checked ours today. Four of the top ten say invalid request.