The web was built for visitors who click. Now it is getting visitors who act.
Agents need doorbells, front desks, and switchboards: identity, permissions, discovery, routing, rate limits, and the ability to respect no.
Machine Room Claims The web was built for visitors who click. Now it is getting visitors who act. Agents will not just read pages. They will ask questions, book appointments, compare prices, file requests, negotiate access, summarize disputes, check policies, retrieve records, and talk to other agents. Some will represent companies. Some will represent people. Some will be helpful. Some will be spam with better manners. The web does not yet know how to greet them. Right now, automated visitors are treated mostly as ghosts or burglars. Either they slip through silently, pretending to be normal browsers, or they trigger defenses built to keep bad bots out. That made sense when “bot” usually meant crawler, scraper, spammer, credential stuffer, or fraud engine. But the agent web will be stranger than that. Some automated visitors will be legitimate. Some will be authorized. Some will be acting on behalf of a human. Some will need to ask permission before proceeding. Some should be routed to an API instead of scraping a page. Some should be told no. For that world, robots.txt is not enough. robots.txt was a Do Not Disturb sign. It gave crawlers a simple way to see which paths a site preferred they avoid. It was useful, elegant, and culturally important. But it is one-way, unauthenticated, and blunt. It cannot tell a site who is knocking. It cannot prove an agent’s owner. It cannot negotiate purpose. It cannot route the visitor to a better interface. Agents need an intercom. A useful agent-facing web needs three things: a doorbell, a front desk, and a switchboard. The doorbell lets an agent announce itself: here is who I am, here is who I represent, here is my signed identity, here is my purpose, and here is how you can verify me. The front desk tells the agent the house rules: what is allowed, what is forbidden, what requires approval, what rates are acceptable, what contact or appeal path exists, and what interfaces should be used. The switchboard routes the request: go to this API, use this MCP server, submit this form, enter this queue, contact this human, or stop here. That sounds futuristic, but the web already has pieces of it. The /.well-known/ pattern gives sites a standard place to publish machine-readable facts. security.txt uses that pattern so researchers can find vulnerability disclosure contacts. WebFinger gives a precedent for discovering information about identities. DNS service discovery and SRV records show older ways to locate services. OpenAPI gives mature vocabulary for describing what an API can do. The missing piece is not imagination. It is integration. A site should be able to publish something like an agent front desk: “If you are an automated agent, start here.” Not because every agent deserves entry, but because a clean knock is better than a silent crawl. That front desk could point to policies, identity requirements, signed-request rules, rate limits, API descriptions, public data feeds, paid-access terms, human approval flows, or refusal instructions. It could say: “Personal shopping agents may query this endpoint.” Or: “Training crawlers are not allowed.” Or: “Customer agents need delegated user authorization.” Or: “Press agents should submit questions here.” Or simply: “No agents.” The important thing is that the answer becomes legible. Identity matters because without it, every agent interaction becomes theater. User-Agent strings can be spoofed. IP allowlists are brittle. Browser fingerprints are hostile to privacy and still imperfect. If an agent claims to be acting for a person, company, crawler, research project, or marketplace, the server needs a way to verify that claim. 
