ai agents make the web feel weird now

# The Web Is Becoming an API for AI Agents Source: [https://medium.com/ai-engineering-collective/the-web-is-becoming-an-api-for-ai-agents-fd057e098cd6](https://medium.com/ai-engineering-collective/the-web-is-becoming-an-api-for-ai-agents-fd057e098cd6) ## MCP, A2A, WebMCP, and the traffic inversion that arrived early [](https://medium.com/@debjitdey_59101?source=post_page---byline--fd057e098cd6---------------------------------------) Press enter or click to view image in full size Source: Photo by Igor Omilaev on UnsplashThe web was built around one basic assumption: a human is looking at the page\. A person reads the headline, scans the menu, clicks the button, fills out the form, compares options, checks the price, opens another tab, hesitates for a moment, and eventually does something\. Nearly every part of the consumer web grew around that loop\. Pages were designed for eyes\. Buttons were designed for fingers\. Forms were designed for people who understand when “continue” means “show me the next step” and when it means “commit me to this action\.” That assumption is no longer holding\. In June 2026, reporting based on Cloudflare data made a lot of infrastructure people pause: bots were estimated to account for about 57\.5% of HTTP requests to web content, while humans accounted for the remaining 42\.5%\. That number needs context\. HTTP requests are not the same thing as human attention, total internet value, mobile app usage, streaming time, or economic importance\. A bot loading pages is not equivalent to a person reading, buying, learning, or deciding\. Still, as a signal, it is hard to ignore\. By this measurement, automated traffic has crossed human traffic\. Tom’s Hardware reported the Cloudflare figure[here](https://www.tomshardware.com/tech-industry/artificial-intelligence/bots-have-now-passed-human-traffic-online-cloudflare-boss-laments-says-agentic-traffic-wasnt-expected-to-eclipse-real-people-until-next-year)\. The more important story is not just that automated traffic is growing\. The web has always had bots\. Search crawlers, uptime monitors, SEO tools, spam scripts, scrapers, fraud networks, and training\-data collectors have lived on the internet for years\. What is changing now is the kind of automation\. A new software consumer is arriving: the AI agent\. Not a crawler that fetches documents\. Not a script that checks whether a server is alive\. Not a scraper that extracts a table\. An agent can navigate, compare, summarize, fill forms, check availability, authenticate, ask follow\-up questions, and increasingly act on behalf of a user\. HUMAN Security’s 2026 State of AI Traffic & Cyberthreat Benchmark Report found that monthly AI\-driven traffic grew 187% from January to December 2025, nearly tripling over the year\. The fastest\-growing category was agentic AI\. Traffic from AI agents and agentic browsers grew 7,851% year over year\. The report is available[here](https://www.humansecurity.com/learn/resources/2026-state-of-ai-traffic-cyberthreat-benchmarks/)\. That is the shift worth watching\. Crawlers are no longer the whole story\. Software is starting to behave less like an indexer and more like a user with a goal\. A human shopping for a flight may visit five or ten pages\. An agent doing the same job can inspect hundreds of options, compare refund rules, monitor price changes, and show only the final recommendation\. That changes the economics of traffic\. It changes attribution\. It changes what “discovery” means\. It also breaks a lot of product assumptions that still treat the human browser session as the center of the internet\. The interesting part is not that the web is getting more automated\. That was already obvious\. The interesting part is what the web is starting to do in response\. ## The human web was never a good interface for software A modern website does not only contain information\. It contains intent, but much of that intent is hidden inside visual structure\. A button might mean “buy now,” “save draft,” “request quote,” “cancel subscription,” or “delete account\.” A date picker may depend on time zones, inventory, blackout periods, local validation logic, and user history\. A checkout flow can span several pages, client state, server state, payment authorization, a confirmation modal, and an email receipt\. Humans handle this because the web trained us for it\. We know a greyed\-out button usually means something is missing\. We know a small downward arrow probably opens a dropdown\. We know when a checkout page is asking for a shipping address and when it is about to charge a card\. We know when to slow down\. Agents do not really know these things\. They infer them\. They inspect the DOM\. They read labels\. They guess what a button does\. They simulate clicks and keystrokes\. They retry when something breaks\. This works surprisingly often, but it is still a bad abstraction\. It treats the agent like a human user trapped inside a browser, poking at a visual interface that was never meant to be a machine contract\. It is fragile\. A designer renames a button, restructures a form, moves a field behind a modal, changes copy, or adds a new validation step, and the agent’s plan may break\. Worse, the agent may not realize it has broken\. It may continue acting with partial understanding\. There is also the problem of intent\. Did the agent click “continue” because it wanted to preview the next step, or because it understood that the user had approved a purchase? Did it know a cancellation was irreversible? Did it understand that a field was technically optional but operationally important? This is where the old web starts to look awkward\. An agent should not have to guess whether a button triggers checkout\. The page should be able to declare a checkout capability\. An agent should not infer from layout that a form expects passport number, departure city, meal preference, and seat preference\. The site should expose a schema\. An agent should not click through five screens to discover whether a booking is refundable\. The policy should be available before the action\. Once you look at it this way, the web starts to resemble something else: a vast set of tool surfaces waiting to be described properly\. ## WebMCP is the clearest browser\-side signal so far At Google I/O 2026, Chrome introduced WebMCP as part of its broader “agentic web” push\. Chrome describes WebMCP as a proposed open web standard that lets websites expose structured tools, such as JavaScript functions and annotated HTML forms, to browser\-based agents\. Chrome’s I/O update is[here](https://developer.chrome.com/blog/chrome-at-io26), and the WebMCP documentation is[here](https://developer.chrome.com/docs/ai/webmcp)\. The idea is simple enough: instead of forcing agents to scrape HTML, interpret visual layout, and guess what interface elements do, websites can expose machine\-readable actions\. A travel site could expose a flight\-search tool\. A support portal could expose a ticket\-submission tool\. A SaaS dashboard could expose a diagnostics tool\. An e\-commerce site could expose availability, return rules, shipping windows, and checkout preparation as structured capabilities rather than leaving agents to reverse\-engineer them from page layout\. The visible website does not disappear\. The user still sees the page\. The brand, layout, and experience remain intact\. But behind the interface, the site exposes an action layer that an agent can understand with far less guesswork\. This is not just accessibility for AI\. It changes the contract between websites and software\. A flight site is no longer only a set of pages to browse\. It becomes a set of capabilities that can be discovered and invoked\. A form is no longer only a visual object\. It becomes a structured transaction boundary\. A product page is no longer only persuasive copy and imagery\. It becomes a machine\-readable surface for price, stock, shipping, policy, and purchase intent\. One WebMCP design choice is especially important: tool calls are tied to a browser tab or webview context\. The agent is not quietly calling an invisible backend endpoint somewhere far away from the user’s view\. The action still happens in a visible browsing context\. That visibility matters\. Pure agent\-to\-API interaction can be efficient, but it can also feel like a black box\. A visible browser context gives users a better chance to understand where the agent is acting, what it is doing, and when approval is needed\. It also creates new engineering work\. Once a website can expose callable tools to agents, product teams have to answer questions they could previously avoid\. Which actions should be exposed? Which ones require confirmation? What state should the agent see? How should permissions be scoped? How should errors be represented? How should retries work? What needs to be logged? That is where this stops being a browser feature and starts becoming infrastructure\. ## MCP arrived first because the integration problem was already painful WebMCP belongs to a larger protocol shift that has been building for more than a year\. The Model Context Protocol, or MCP, was introduced by Anthropic in 2024 as an open standard for connecting AI assistants to external systems\. Anthropic described it as a way to build secure, two\-way connections between data sources and AI\-powered tools\. The launch post is[here](https://www.anthropic.com/news/model-context-protocol)\. The official MCP documentation describes MCP as an open\-source standard for connecting AI applications to external systems such as tools, data sources, and workflows\. The documentation is[here](https://modelcontextprotocol.io/docs/getting-started/intro)\. The appeal is not theoretical\. Without a standard protocol, every AI application needs custom integrations\. One connector for GitHub\. Another for Slack\. Another for Postgres\. Another for Google Drive\. Another for a customer support system\. Another for an internal knowledge base\. Another for a billing platform\. That does not scale cleanly\. MCP tries to solve the integration problem by giving AI clients and external systems a shared way to expose tools, resources, and capabilities\. Build the server once, and compatible clients can discover and use it\. In the older API world, a developer wrote code against an endpoint\. In the agentic world, an AI application needs to discover what tools exist, understand what each tool does, decide when to call one, supply structured arguments, interpret the result, and continue the task\. That is more than API access\. It is operational context\. This is why MCP matters\. It is not just another connector format\. It is one of the pieces that moves AI systems from text generation into tool\-using behavior\. But the same thing that makes MCP useful also makes it dangerous\. Once an agent can call tools, the model’s output is no longer only language\. It can become an action\. A wrong answer is one kind of failure\. A wrong tool call is another\. The difference is not cosmetic\. It is operational, legal, financial, and sometimes irreversible\. ## A2A appears when one agent is no longer enough MCP mostly answers one question: how does an agent connect to tools, APIs, data, and workflows? Agent2Agent, or A2A, asks a different question: how does one agent work with another agent? The official A2A documentation describes it as an open standard for communication and collaboration between AI agents\. It also says A2A was originally developed by Google and donated to the Linux Foundation\. The documentation is[here](https://a2a-protocol.org/latest/), and Google’s original announcement is[here](https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/)\. The distinction is useful\. MCP is agent\-to\-tool\. A2A is agent\-to\-agent\. A hiring workflow may need a sourcing agent, a scheduling agent, a background\-check agent, and an HR policy agent\. A customer support workflow may need a billing agent, a refund agent, a logistics agent, and a fraud agent\. A deployment workflow may need a code agent, a test agent, a security\-review agent, and a release agent\. In a demo, all of this can be compressed into one big prompt with a few tools\. In production, that becomes messy very quickly\. Different agents may have different owners, runtimes, vendors, permissions, memory policies, models, and audit requirements\. Some agents may expose capabilities without exposing their internal toolchain\. Some may need to negotiate a task, ask for clarification, refuse a request, or return partial results\. That is why A2A is interesting\. It treats agents less like isolated chatbots and more like networked services\. If MCP is the tool layer, A2A is the collaboration layer\. Together, they point toward a web where software actors do not simply call APIs\. They discover, delegate, negotiate, and coordinate\. This does not mean every product needs a swarm of agents\. It means the old boundary between “application,” “API,” “assistant,” and “workflow” is getting less obvious\. ## Search is becoming delegation For most of its history, search was a retrieval interface\. You typed keywords\. Search returned links\. You clicked, read, compared, and acted somewhere else\. AI Overviews changed part of that loop by summarizing information inside the results page\. But the 2026 shift goes further\. At I/O 2026, Google described a new AI\-powered Search experience with agents inside Search\. Google said users will be able to create and manage information agents that monitor the web, synthesize updates, and support tasks such as apartment hunting, shopping, and local bookings\. Google’s Search update is[here](https://blog.google/products-and-platforms/products/search/search-io-2026/)\. This changes what a search query means\. “Best laptop under $1,500” is a query\. “Track laptops under $1,500 with good Linux support and notify me when one drops below $1,200” is a delegated task\. “Restaurants near me” is a query\. “Find a private karaoke room for six on Friday night that serves food late and has availability after 9 PM” is a delegated task\. “Flights to Tokyo” is a query\. “Find a flight to Tokyo in October with one layover max, compare refund policies, and hold the best option until I approve” is a delegated task\. The traffic implications are obvious\. In a delegation model, the user may not visit ten sites\. The agent visits them, monitors them, compares them, and returns only the useful result\. Sometimes the user sees the provider at the final confirmation step\. Sometimes they may never meaningfully see the original page at all\. For publishers, travel sites, marketplaces, local businesses, e\-commerce platforms, SaaS products, and service providers, this is not a small change\. The old game was to make pages discoverable to search engines and persuasive to humans\. The new game is to make actions legible to agents and trustworthy to users\. Most teams are not ready for that\. Not because they are careless, but because the discipline barely exists yet\. ## The security model is behind the product ambition The hardest problem in agentic AI is not tool calling\. It is authority\. A chatbot that gives bad advice creates a quality problem\. An agent that resets a password, sends money, changes production data, books a non\-refundable ticket, or deletes records creates a security problem\. That line is exactly where attackers are now paying attention\. In late May and early June 2026, reports described attackers manipulating Meta’s AI\-powered Instagram support chatbot into account\-access actions\. High\-profile accounts were reportedly affected, and Reuters described the incident as a warning about automating sensitive user functions without adequate safeguards\. Reuters’ report is[here](https://www.reuters.com/legal/government/high-profile-meta-ai-chatbot-breach-spotlights-security-risks-automation-2026-06-03/)\. TechCrunch also reported on the account takeovers[here](https://techcrunch.com/2026/06/01/hackers-hijacked-instagram-accounts-by-tricking-meta-ai-support-chatbot-into-granting-access/)and on follow\-up alerts to targeted users[here](https://techcrunch.com/2026/06/03/instagram-is-alerting-users-who-were-targeted-by-hackers-during-ai-chatbot-attacks/)\. The specific bug is important, but the larger lesson is more important\. Once an AI system is connected to privileged account functions, it is no longer just answering support questions\. It is participating in an access\-control workflow\. That is a completely different risk category\. Once agents can act, prompt injection stops being a novelty\. Malicious content on a webpage can influence tool selection\. Tool metadata can be poisoned\. A compromised connector can describe a dangerous operation as a harmless one\. Retrieved documents can smuggle instructions\. A multi\-agent workflow can carry trust across systems that do not share the same assumptions\. A helpful assistant can become a confused deputy\. Security research is already circling these problems\. The Agent Identity Protocol paper argues that agents increasingly call tools through MCP and delegate to other agents through A2A, while identity and verifiable delegation remain underdeveloped\. The paper is[here](https://arxiv.org/abs/2603.24775)\. A 2025 survey of interoperability protocols compared MCP, ACP, A2A, and ANP as emerging standards for tool integration, contextual sharing, and agent coordination\. That survey is[here](https://arxiv.org/abs/2505.02279)\. Other MCP security work has focused on tool poisoning, adversarial tool descriptions, prompt injection, privilege escalation, and governance\. One example is[Securing the Model Context Protocol](https://arxiv.org/abs/2511.20920), and another is[Securing the Model Context Protocol: Defending LLMs Against Tool Poisoning and Adversarial Attacks](https://arxiv.org/abs/2512.06556)\. The uncomfortable truth is simple: many systems that are technically API\-ready are not agent\-ready\. They expose endpoints, but not intent\. They validate payloads, but not delegated authority\. They log requests, but not reasoning context\. They authenticate users, but not agents\. They handle errors, but not agent recovery\. They document fields, but not operational meaning\. That gap is where many production failures will happen\. ## The agentic web stack is not one thing If the web is becoming an API for agents, the engineering question is not “how do we expose more tools?” The real question is: how do we make those tools safe, reliable, observable, and economically sane? A practical agentic web stack needs at least six concerns: intent, runtime, protocol, permission, action, and audit\. These should not be treated as abstract layers in a diagram\. They are the places where real systems will either behave responsibly or fail in ways that are difficult to debug\. Intent is where the user’s goal gets captured with enough precision to separate exploration from commitment\. Looking at refund options is not the same as issuing a refund\. Drafting an email is not the same as sending it\. Preparing a database migration is not the same as running it\. Good agent systems treat intent as a contract, not as a loose prompt\. Runtime is where planning, state, tool calls, retries, handoffs, approvals, and recovery happen\. A production agent runtime needs to know what happened, what is happening now, what can be retried, what requires approval, and what must never be attempted without a person in the loop\. OpenAI’s Agents SDK documentation describes agents as applications equipped with instructions and tools, with support for handoffs, guardrails, sessions, human\-in\-the\-loop mechanisms, MCP integration, and tracing\. The documentation is[here](https://openai.github.io/openai-agents-python/)\. Protocol is where MCP, A2A, WebMCP, OpenAPI, and related standards matter\. This layer tells agents what capabilities exist and how to call them\. Poor tool descriptions create poor behavior\. Ambiguous schemas create bad calls\. Over\-broad tools create security risk\. Missing error semantics create brittle retries\. Agent\-readiness is becoming an engineering property, not an afterthought\. Permission is where demos usually get vague\. A serious agent system must separate read, write, commit, and irreversible actions\. Reading an order status is not the same as canceling the order\. Checking a refund policy is not the same as issuing the refund\. Generating a SQL migration is not the same as applying it to production\. The permission layer has to answer questions that are not optional\. What identity is the agent using? Is it acting for a human, an organization, or another agent? What scope was granted? How long does that grant last? Can the agent delegate? Can the action be reversed? Does this step require explicit human confirmation? What happens if the model is manipulated? There are no safe defaults here\. Someone has to design them\. Action is where the work actually happens: fill form, book service, update record, create ticket, run diagnostic, deploy patch, send email, issue refund\. This layer should follow one boring but critical principle: agents should call narrow, explicit, reversible tools wherever possible\. A tool named`do\_everything\_for\_user`is a liability\. A tool named`prepare\_refund\_summary`is safer\. A tool named`issue\_refund`should require stricter permission, confirmation, and an audit trail\. Good agent\-facing tools should be small enough to reason about, typed enough to validate, and constrained enough to fail safely\. Audit is what makes the whole system accountable\. Standard logs are not enough\. Knowing that an HTTP request returned 200 does not tell you why the agent made the request, what it believed it was doing, or whether the user authorized the step\. Agent observability is different from normal observability\. It is not only about latency, errors, and uptime\. It is about delegated behavior\. You need to know what the user asked, what the agent understood, what tools were available, which tool was selected, what arguments were passed, what data came back, what policy allowed the action, whether a human approved it, what external state changed, and whether the action can be replayed, reversed, or explained\. OpenAI’s Agents SDK tracing documentation describes traces and spans for agent workflows, including model calls, tool calls, handoffs, and other workflow events\. The tracing documentation is[here](https://openai.github.io/openai-agents-python/tracing/)\. That is where serious agent engineering is moving: not just better answers, but better records of why actions happened\. ## What builders should start asking now The agentic web is early enough that most teams do not need to rebuild everything tomorrow\. It is mature enough that treating agents as toys outside the product is already the wrong posture\. The questions are practical\. Which user tasks in your product are actually safe to delegate? Which ones should stay human\-only? Which workflows fail because the interface is visually clear to humans but semantically opaque to machines? Which APIs are too broad for agent use? Which tool descriptions are ambiguous? Which actions should require confirmation before they touch irreversible state? What logs would you need if an agent made the wrong call in production? A few principles transfer across domains\. Expose intent, not just interface\. Prefer structured tools over click simulation\. Separate read from write\. Keep tools narrow\. Treat tool descriptions as security\-sensitive artifacts\. Do not let retrieved content silently become instruction\. Log the reasoning path, not only the final request\. Evaluate tool selection, permission boundaries, and recovery, not just the final answer\. Also assume agents will interact with your product whether you optimize for them or not\. Some will use clean protocols\. Some will click through your UI like an impatient intern\. Some will be legitimate\. Some will be hostile\. Some will be impossible to classify at first contact\. That is why the infrastructure layer matters\. The web cannot run on user\-agent strings and CAPTCHA forever\. It needs identity, scopes, provenance, permission boundaries, and economic rules for non\-human actors\. None of that exists at web scale yet\. ## The next web will be negotiated by agents It is tempting to describe this as the death of websites\. That is too dramatic\. Humans will still browse\. Interfaces will still matter\. Brand, trust, taste, and visual experience will matter more in some domains, not less\. In high\-stakes decisions, especially medical, financial, and legal ones, human judgment in the loop will remain essential\. But the web now has a second audience, and that audience is growing quickly\. The old question was: can a user find this page? The platform era asked: can a search engine index it? The agentic era asks: can a trusted agent understand, verify, and safely act on this system? That third question is harder\. It requires protocols, schemas, permissions, identity, observability, and product judgment about what should and should not be automated\. It forces frontend engineering, backend APIs, security, policy, and UX to sit in the same room\. The traffic inversion is already visible\. The security incidents are already arriving\. The protocols are being standardized\. Search platforms are being rebuilt around delegation\. The future of the web will not be defined only by bigger models or longer context windows\. It will be defined by whether we can build systems where agents can act without turning the internet into an unbounded permission accident\. The web is becoming an API for AI agents\. The hard part is not exposing that API\. The hard part is deciding who should be allowed to use it, when, and with what consequences\.