Software has always assumed a human on the other side. Every button, form, and login was built for someone who could see a screen and click through it. That assumption is breaking.
Agents already read your documentation and call your APIs. They do it without becoming the person your product was designed for.
The human was the design constraint
For a long time, software could treat "user" as a person with a browser. Sessions, cookies, consent screens, and "click Continue" all made sense under that rule. If a step was unclear, a person could hover, guess, or open a support chat.
An agent does not hover. It parses what you published, picks a next call, and either finishes the job or stops. The product still ran. The user still left.
This is not a demo you will see next year. Coding agents inside editors already fetch your docs, mint tokens when they can, and write the integration while a developer watches the diff. The developer is still the buyer. The hands on your product are not theirs.
You can keep calling that "automation" if you want. It does not change the relationship. Something is using your software to complete a job on behalf of a customer. That is a user. The label you pick does not change what it did on your endpoints.
What counts as a user now
A user is whoever tries to complete a job with your product. That used to be a person. It is increasingly software acting for a person.
An agent is not a crawler. A crawler indexes. An agent has a goal: add webhooks, create a project, send a test event, install an SDK. It can succeed or fail at that goal. Failure looks like a few retries and then silence.
A bot you block and an agent you want are easy to confuse in logs. Both arrive fast. Both skip your marketing pages. Only one is trying to finish work a customer asked for.
That difference is the thesis. Treat the agent as noise and you will keep polishing the human path while the evaluation happens somewhere else. Treat it as a new kind of experience and the questions change: what did it come to do, and did it finish?
The category also is not "your chatbot." A copilot you embedded is a feature. An outside agent hitting your public surfaces is a visitor. You do not get to interview it. You get the request trail it leaves, and that trail is the whole conversation.
The coding agent that never made it past OAuth
Last month I watched a coding agent try to add a payments SDK from inside an editor. The developer typed one line: wire up checkout. The agent opened the official docs, found the OAuth section, and followed it like a literal intern.
The flow wanted a redirect URI, a browser consent screen, and a human to click Allow. The agent had a terminal and a file tree. It tried the authorize URL anyway. The response was a redirect. Then a 401. Then the same 401 with a different header the docs mentioned in a sidebar.
Three attempts. No ticket. The agent switched to a second provider whose quickstart used a test key in a code block. The competitor's snippet compiled. That was the evaluation.
I used to file that pattern as bot noise on /oauth. It was a buyer.
Your logs would have shown a docs fetch, an authorize hit, and a couple of 401s. Nothing about checkout. Nothing about the other vendor winning in the same chat. The person who asked for the integration never visited your homepage. They accepted the snippet that worked. From their side, your product never entered the shortlist. From yours, it looked like junk traffic.
If you later asked that developer why they picked the other API, they would shrug. The agent already had it working. People do not narrate failed machine attempts. They ship.
How this user breaks the old categories
Human | Crawler | Agent | |
|---|---|---|---|
Has a job to finish | Yes | No | Yes |
Needs a screen | Yes | No | No |
Shows up in sessions | Yes | Sometimes | Rarely |
Leaves a complaint when stuck | Sometimes | No | No |
Product analytics was built for row one. Security tooling was built for row two. Row three sits in both dashboards and belongs to neither.
Observability will tell you the 401 was correct. Analytics will tell you nobody converted. Both are true. Both miss the job.
Teams still file this under "integrations" or "API hygiene." Those labels make it sound like plumbing. Plumbing does not choose a vendor in a chat. A user does. If the actor completing the job is software, the product has a software user, whether you named the segment or not.
This is why "we already have bot filtering" is not an answer. Filtering is a security decision. User design is a product decision. You can block scrapers and still need a path for the agent a customer sent.
You already ship the surfaces they use
You do not need a new product line for this to be real. Agents use what you already published: reference docs, error bodies, token endpoints, example requests. If those paths assume eyes and a mouse, the agent stalls on infrastructure you think of as finished.
The homepage can still be excellent. It just is not the room where this user decides. The decision is whether the next call is obvious.
When the next call is not obvious, agents fail quietly. Your uptime stays green. The task does not.
Teams keep looking for a new channel dashboard. The channel is the public surface you already maintain. Docs that say "see the dashboard." Errors that say "invalid request." Tokens that only exist after a human clicks email. Those are product decisions now, not copy nits.
I do not think every company needs an "agent strategy" slide. I do think you need to stop pretending the only real user will eventually appear in a browser and explain themselves.
The assumption to drop
Some buyers will still land on marketing, book a demo, and click around. That path is not gone. It is no longer the only path that counts as demand.
A growing share will send software first. That software will not introduce itself. It will not wait for your onboarding modal. It will not fill the "how did you hear about us" field. It will not tell sales why the other SDK won. The person who sent it may not know either. They will remember the snippet that compiled.
If your product only works when a person is in the loop, you still have a product. You have a narrower set of users than you think. The loop you designed for is optional now. The request still arrives.
Software assumed a human. The new class of user does not need to be one.