The next “user” who creates an account in your product may not be a human. It’s an agent, acting on a person’s behalf — and it won’t touch your sign-up form the way you designed it to be touched.
That’s not a forecast. The standard that lets it happen is already forming. In late May 2026, WorkOS published auth.md, an open protocol that lets AI agents register for an app and act inside it for a user — think robots.txt, but for agent sign-up: a file you host at your domain that tells agents how to register your users, which flows you support, and how credentials get issued. It composes existing OAuth standards, it isn’t tied to WorkOS, and it launched with Cloudflare and Firecrawl as early adopters. The plumbing for a non-human user is being poured right now.
Here’s what that means for the bet you’re making on your own work. Agents don’t click. They read, decide, and call. So the entire human layer of operating software — finding the right screen, filling the form, navigating the dashboard — is exactly the layer now being automated. The durable move is to stop being the operator and become the one who decides what the software should do and checks that it did it.
This is for you if your day is mostly spent inside applications — or if you build them. If you already spend your time deciding what’s worth doing and verifying the result, you’re already standing where this is going. If most of your hours go to driving tools by hand, this is the part worth reading slowly.
Apps were built end to end for a human clicking
Look at almost any product and you’ll find the same assumption baked into every layer: a person is sitting there, clicking.
- Identity assumes a human at a sign-up form, solving a CAPTCHA, clicking a link in an email.
- Permissions assume one human account with one set of rights, toggled in a settings page.
- Billing assumes a person reading a pricing page and entering a card.
- The interface — the whole polished surface — assumes eyes scanning and a cursor moving.
That stack is the human-operation layer. It exists so a person can operate the software. And it’s precisely that layer an agent now does for itself: auth.md’s flows let an agent either present a verified identity assertion from its provider — OpenAI, Anthropic, Cursor — or walk a user through a short code-confirmation step, and then receive scoped, short-lived credentials to act. No form. No dashboard tour. The agent reads what the app supports and calls it.
So the skill of knowing your way around the software — which menu, which toggle, which screen — is being handed to the machine. That changes the job on both sides of the screen.
Builder track: if your user is an agent, build for a reader, not a clicker
If a real share of your sign-ups will be agents, the things you’d polish for a human stop being the edge.
A clicker needs an onboarding tour, tooltips, an empty-state illustration, a beautiful settings page. A reader — which is what an agent is — needs none of that. It needs:
- Machine-readable access. A clear, discoverable description of what your app does and how to register, the way auth.md publishes registration at a known path. An agent shouldn’t have to scrape your UI to figure out how to act.
- A real API behind the buttons. Every action a human can take by clicking should be callable directly. If a workflow only exists as a sequence of screen clicks, an agent can’t do it cleanly — and a competitor whose version is callable will win that user’s agent.
- Per-agent permissions and billing. One human account holding one card no longer fits. You’ll need to grant a specific agent a scoped, revocable set of rights, meter what it does, and bill for it — closer to how you’d issue an API key than how you’d add a teammate.
None of this means the interface dies. Humans still sign in, still look at things, still decide. But the pretty click-through dashboard stops being the advantage, because a growing share of your most active “users” never see it. The edge moves to whoever makes their product usable by an agent first.
The pretty click-through dashboard stops being the advantage, because a growing share of your most active users never see it.
Worker track: the clicking is the part that gets automated
Now the other side of the screen — and this is the uncomfortable part.
A large share of knowledge work is operating software. Pulling a report from one dashboard and pasting numbers into another. Filling the same form with slightly different inputs. Chasing an approval through three tools. Reconciling two systems that don’t talk. If you wrote down your week honestly, a real fraction of it is you being the human who moves data between applications by hand.
That fraction is the automatable layer. It’s the same work auth.md and its kin are built to let an agent do for itself — log in, read the screen’s worth of state, take the action, move on. Being the human operator of software was a stable, well-paid role for thirty years. It is not the durable role for the next ten.
This isn’t dread, and it isn’t “learn to code.” It’s a relocation. The value isn’t leaving the work — it’s moving to a different part of it.
What agents still can’t do: decide, and confirm
Here’s the part that’s easy to miss in the worry: agents are very good at doing the operation and still bad at two things around it.
They can’t reliably decide what’s worth doing. An agent will happily generate the report nobody needed, automate the process that should have been deleted, optimize the form that should never have existed. Choosing the goal — and choosing against the busywork — is still a human call.
And they can’t reliably confirm it was done right. An agent that signs into ten apps and takes a hundred actions can be confidently, completely wrong, and it will not feel the wrongness. Someone has to define what “right” looks like and check the output against it. That checking is judgment, and judgment doesn’t come from the model.
So the move is concrete: shift your weight from operating tools to directing them and verifying them. Decide what should happen. Let the agent do the clicking. Then check the result like it’s your name on it — because it is.
This is the same pattern across every track The Augmented Work watches: the typing got cheap, the deciding and the checking got valuable. Operating software is just the latest skill to cross that line.
What to do this week
Two moves, depending on which side of the screen you’re on.
If you operate software all day: audit one real week. Mark each block as either operating — clicking, filling, navigating, moving data by hand — or deciding and verifying — choosing what’s worth doing, defining what “done right” means, checking that it is. Then start shifting weight from the first column to the second. Hand the operating to a tool where you safely can, and spend the freed time getting better at the judgment calls a model can’t make. The goal isn’t to do more operating faster. It’s to do less of it, and more of the part that’s still yours.
If you build software: ship an agent-usable path into your product before a competitor does. Pick your single most-used workflow and make it callable, discoverable, and safely permissioned for an agent — not a screen-scrape of your UI, a real door. The first product in your category that an agent can use well gets the agent’s user. The prettiest dashboard doesn’t.
The account that signs up tomorrow might be a person. It might be a person’s agent. Build for the second, work like the first can’t be replaced at the part that matters — deciding and checking — and you’re standing on the half of the job that’s still yours.
Sources
- 1auth.md — Open Protocol for Agent Registration (WorkOS) — the protocol spec: discovery at a hosted path, the agent-verified and user-claimed flows, scoped short-lived credentials, “isn’t tied to WorkOS infrastructure.”
- 2WorkOS Releases auth.md: An Open Agent Registration Protocol Built on OAuth Standards (MarkTechPost, 2026-05-25) — independent coverage of the launch and the OAuth/RFC underpinnings.
- 3Agent Registration with auth.md (WorkOS blog) — the “robots.txt for agent registration” framing and the early adopters (Cloudflare, Firecrawl).