See how Frete cut frontend build time by 70%

What are best AI tools? Take the State of AI survey

Builder.io
Builder.io
Contact sales

See how Frete cut frontend build time by 70%

What are best AI tools? Take the State of AI survey

Builder.io
Builder.io
< Back to blog

AI Agents

The Internet Is Not Ready for the Agentic Wave

September 21, 2026

Written By Pratham

The internet basically assumed everyone on it was human. If you weren’t, something was probably wrong. Almost everything we interact with today, from UI and authentication to checkout, was built with one assumption in mind: a human is using it. Someone who reads, clicks, thinks, and moves one step at a time.

LLMs bring a very different kind of user.

So what happens when the internet’s biggest assumption, that its users are human, is no longer true?

The rise of agentic traffic

We took some time getting online. Around 16 million people were on the Internet worldwide in 1995. By 2005, that number was roughly a billion. After that, another billion or so every few years.

Most of us might have seen the internet grow. Dial-up became broadband. Broadband became mobile. Mobile became 5G. All the internet folks (browsers, ISPs, security teams, etc.) had years to adapt to each new wave.

The teams adapting the web for agents may not get that luxury.

Line graph titled Internet user adoption over time (worldwide) showing growth from 1 billion users in 2005 to 6 billion users in 2025, representing approximately 74% of the world population and a 6x growth over that period.

Non-human traffic has already been a huge part of the web for years. Bot-traffic reports from companies like Imperva regularly put automated traffic at around half of all web requests, sometimes even higher. And that was before we started talking about agents. Agents like OpenClaw barely registered in server logs a few years ago. Now they are becoming a category of traffic that infrastructure teams actually have to think about.

In traffic observed across its customer base, HUMAN Security reported:

  • AI-driven traffic growth in 2025: 187%
  • AI agents + agentic browsers year-over-year growth: 7,851%

Now, the problem isn't the crawlers, but the agents that can actually do things. They can compare ten tabs of pricing, fill out a form, complete a checkout, or make a reservation—all on someone's behalf, and at crazy speeds!

Browser-use and computer-use agents quickly went from lab demos to shipped products like Perplexity's Comet Browser.

The web has had decades to adapt to humans. It may have only a few years to adapt to software acting on their behalf.

The web assumes you’re human

We don't usually think much about little things we do on the internet. We land on a page, look at the nice website design, do the CAPTCHA, hover over things, click around, wait for the response, and decide what to do next.

That whole experience assumes a person is doing all of this.

Authentication flows expect someone to log in. Fraud systems look for patterns that tell them a human is probably behind the request. Rate limits cap how many requests a client can make in a given period. And the advertising business depends on that person actually paying attention. Even things like permissions, consent screens, and terms of service ultimately assume there's a human making the decision.

But agents don't need to behave that way.

They can move through a UI without reading it the way we do. They can call APIs, retry failed requests, run thousands of actions, and make decisions between steps without getting bored or tired. They don't necessarily follow the path the interface designer imagined.

To be fair, every prior wave—mobile, streaming, IoT—got the same "internet isn't ready" treatment on arrival. And every time, the commercially important parts of the web eventually adapted because there was money to be made.

I don't think the agentic wave will be any different. The difference is how quickly it might happen, and which layers of the internet have to change first.

Designed for eyes, not for reasoning

We don't need to read the HTML to know a red button in the corner probably deletes something. Color, placement, icons, a decade of UI convention—the brain fills the gap without much effort. An agent looking at the same page has a much harder job. It has to work out what things mean from the way they were implemented.

An illustration showing a human looking at a shopping cart UI and focusing on a delete icon, contrasted with an AI agent analyzing the underlying HTML code of the same interface, represented by a block of code with a question mark bubble above the agent's head.

Screen readers have been dealing with this problem for years. Agents run into a similar problem when they act on a user's behalf. A poorly structured page doesn't just make one element confusing. It can make the agent misunderstand the task it's trying to complete.

And some agent systems are taking an expensive way around that problem. Instead of relying on the page structure, they look at the page, take a screenshot, send the image to a vision model, and reconstruct what’s on the screen from the pixels.

It works. But it’s a little backwards. The page already knows that something is a <button>. The agent is spending tokens figuring that out from a picture.

We’ve spent decades making the web look right in Chrome. We haven’t spent nearly as much time making it mean something to a machine.

Anti-bot infrastructure was built to say no

CAPTCHAs, invalid traffic detection, and rate limits are all used to detect or control automated activity. Broadly, one rule: human → trust it; automated → potentially hostile. Decades of dealing with spam bots, scraping, and other abuse have produced systems that are very good at spotting automation.

Agentic AI, as a form of automation, runs straight into that wall.

A cartoon illustration of a robot holding a flight booking document being blocked at a stone castle gate labeled Anti-Bot Infrastructure. The gate displays an Access Denied message and a stop symbol. To the right of the gate, a security guard labels the robot as Hostile. Further right, a list of security measures—Captchas, Invalid Traffic Detection, Rate Limits, and TLS Fingerprinting—are shown causing a flight booking to be throttled, a shopping session to be killed, and a task to fail.

The industry is starting to adapt. For example, Cloudflare now has AI Crawl Control, which lets site owners decide which AI crawlers to allow or block.

But there’s a flip side. Agents don’t always behave like traditional bots. They can navigate websites, vary their behavior and interact with pages much more like a human would. That makes them harder for existing automation-detection systems to distinguish from legitimate users and potentially creates a new security problem of its own.

There are already efforts to build a better interface for agents. WebMCP, for example, lets websites expose structured tools that agents can discover and invoke instead of navigating the UI like a human. This is an important step toward making the web agent-friendly. But it is still early, and most of the commercial web was not built this way.

That’s a good start, but it highlights a bigger problem: the internet’s existing security infrastructure was designed around a simple distinction between humans and bots. Agents increasingly blur that distinction.

The web is starting to get an API for actions

APIs solved machine-to-machine communication years ago. You get a contract: an endpoint, a schema, and a defined result when you call it.

Agents need something similar. A website should be able to tell an agent: here is how to add something to a cart, apply a coupon and check out. It should also define the inputs and permissions required to perform those actions.

WebMCP is an early attempt at building exactly this kind of interface for the web. It lets websites expose structured tools that agents can discover and invoke, rather than forcing them to navigate the UI like a human. WebMCP is being developed through the W3C Web Machine Learning Community Group, but it is still a draft rather than an established web standard.

This is a much better interface than making an agent figure out which button matters, what order the steps need to happen in, and whether clicking something actually did what it thinks it did.

But exposing an action is only part of the problem. Who is allowed to call it, what can they change, and when should a user approve it? WebMCP already has permission mechanisms, but permissions and authorization remain an important part of making agent actions safe.

There is also a much bigger adoption problem. Most of the commercial web was built for humans first and still exposes pages rather than structured actions. WebMCP points toward a better model, but the broader web has a long way to go before agents can reliably interact with websites through these kinds of interfaces.

What happens when agents become users?

This is where the Agent-Native framework comes in. Agent-Native is an open-source framework that allows you to build apps that treat both humans and agents as first-class users.

Instead of building an application for humans and then adding an agent on top, Agent-Native treats the agent as a first-class user from the start. The framework lets applications expose the same actions, state, data, permissions and context to both humans and agents. The UI is still there for people, but the agent doesn't have to pretend to be a person clicking through it. It can work with the application directly through the same underlying capabilities.

Those agent-native actions can also be exposed through WebMCP automatically. This means an application built with Agent-Native can make its capabilities available not just to agents operating inside the application, but also to agents interacting with it through the web. The same underlying action can become an agent-native API, an MCP tool, or a WebMCP tool without requiring developers to build each interface separately.

That also means an Agent-Native application doesn't have to choose between a great human experience and a great agent experience. The same product can be designed for both. Humans get the visual interface, while agents get the structured actions and context they need to reason and act.

Clips: An example of agent-native design

A good example of an app built with the Agent-Native framework is Clips, an open-source screen recording tool that, at first glance, looks a lot like Loom. You record your screen, share a link and someone watches it.

But Clips captures more than the video. With the Chrome extension, it also captures browser diagnostics like console errors and failed network requests. When you share a Clips URL with an agent, it can find the auto-generated transcript and request specific frames from the recording when needed. The agent can inspect what actually happened in the browser instead of trying to infer everything from the video.

Imagine sending a Loom recording to an agent saying, “The checkout button doesn't work.” The agent may be able to watch the video, but it doesn't get the same structured context about what was happening underneath. With Clips, it can inspect the recording alongside the browser activity, identify the failed request, understand the error and potentially start working on the fix.

The broader lesson is that making an application agent-native is about capturing the context and exposing the underlying state and actions so both humans and agents can work with the same product effectively.

Share

Twitter
LinkedIn
Facebook
Code the hard parts.
Offload the follow ups.
Push your branch to Builder so Design, PM, and QA can polish pixels, edit copy, and test in the real app - saving you time and feedback cycles.

Continue Reading
AI Tools15 MIN
What is Jev and how to use it
WRITTEN BY Vishwas Gopinath
September 21, 2026
Agent-Native8 MIN
The Real Reason Coding Agents Get More Done
WRITTEN BY Pratham
September 17, 2026
AI Tools11 MIN
How to De-Slop an AI-Generated Codebase
WRITTEN BY Alice Moore
September 16, 2026

Product

Visual CMS

Theme Studio for Shopify

Sign up

Login

Featured Integrations

React

Angular

Next.js

Gatsby

Resources

User Guides

Developer Docs

Forum

Blog

Github

Get In Touch

Chat With Us

Twitter

Linkedin

Careers

© 2020 Builder.io, Inc.

Security

Privacy Policy

Terms of Service

  • Fusion

  • Publish

  • Product Updates

  • Design to Code

  • Headless CMS

    Multi-Brand CMS

  • Landing Pages

  • Web Apps

  • Prototypes

  • Marketing Sites

  • Headless Commerce

Developer Resources

  • Documentation

  • Fusion Docs

  • Publish Docs

  • Figma AI to Production Code

  • AI Prototyping for Product Managers

  • Figma to Storybook

  • Figma to App Converter

  • All Resources

  • Blog

  • Webinars

  • Guides

  • Customer Stories

  • Community Forum

  • Partners

  • Affiliate Program

  • CMS Integrations

  • CMS Blueprints

  • Explainers

  • Glossary

  • Agent-Native

  • Figma to Code Guide

  • Headless CMS Guide

  • Headless Commerce Guide

  • Composable DXP Guide

  • About

  • Careers

  • Contact Sales

Security

Privacy Policy

SaaS Terms

Trust Center

Cookie Preferences

YouTube icon
Github icon
Twitter "X" icon
LinkedIn icon
Feed Icon