AI Agents and the Future of the Internet
AI agents are changing how people use the web. Explore the business incentives, user risks, and practical rules that could shape the internet. Read more.
The Web Was Built for People. AI Agents Are Changing That.
For years, websites have had two obvious buckets of visitors: people and bots. People browse, compare, and buy. Bots automate tasks like indexing and crawling, and sites usually try to identify and control them.
Personal AI agents blur that split. They act for individual users, often doing things like finding flights, comparing insurance, or placing orders - sometimes at speeds that would be hard for a human to match.
That leads to a practical conflict. A site may see an agent as automated traffic that threatens its systems or business model. The user may see the same agent as a legit shortcut - and a way to negotiate a better deal. As agents become more common, the web's rules, interfaces, and economics will have to adjust. The result could be more leverage for consumers - or it could mean websites that are harder to use, prices that are less transparent, and customer service that becomes harder to reach.
This article digs into why the fight is showing up now, what businesses could gain or lose, and what decisions help protect both users and the systems they rely on.
AI agents are a new kind of web visitor
The old "humans vs. bots" split wasn't perfect, but it was workable. Websites could cater to people while setting rules for automated systems that crawled, indexed, or processed pages. Security tools, rate limits, and verification checks were built around that basic separation.
Personal agents don't fit neatly into either category. They're software, and they can send requests faster and more often than a person. But they may also be acting on a specific person's instructions to complete a real, legitimate task.
So the more useful distinction isn't just "is it automated?" It's what the agent is doing, who it's doing it for, and what authority it has.
Automation changes the scale of ordinary requests
Imagine a customer asking an agent to compare hotel prices, book a table, or request a refund. One request is manageable. Thousands of agents making similar requests at machine speed can turn into a very different kind of load.
Support teams built for human-paced conversations can struggle when automated callers hit all at once. Reservation systems may need to tell the difference between genuine booking attempts and repeated attempts that tie up inventory without finishing the purchase.
This is a scaling problem. A service might work fine while early adopters try agent workflows, then run into trouble once that same behavior becomes common. None of that makes the underlying use case "wrong." It just means services need rules that account for speed, volume, and the fact that an agent can misunderstand what its user meant.
Intent is hard to infer from a request
Websites can't assume that every agent is acting in the user's interest. An agent could be authorized to research options but not to make a purchase. It might submit a refund request without enough context, or repeat a transaction because it never got a clear confirmation. A malicious actor can also disguise bulk automation as "individual" user activity.
From the site's point of view, allowing an agent isn't just a matter of recognizing a product or user-agent string. The site needs confidence about identity, permission, and the actual action being attempted. From the user's point of view, the equivalent need is control: the agent shouldn't spend money, expose sensitive info, or accept terms without the right approvals.
Taken together, the category looks a lot like delegated software: it acts automatically, but with some form of user intent backing it. That distinction matters for product design, security, and policy - and it's why treating every agent like a harmless assistant (or like a hostile bot) is likely to fail.
Why websites are blocking agents
When a platform can't reliably tell useful automation from harmful automation, blocking can be the quickest move. That's especially true for sites that handle payments, bookings, personal data, or high-volume customer requests. A blanket ban can frustrate users, but it may reduce immediate operational and security risk while the site figures out something better.
The reporting behind this discussion describes agents hitting blocks on services including Pizza Hut and Yelp, and Amazon blocking an agent from Meta's Muse. It also describes a legal dispute involving Amazon and the AI startup Perplexity. The examples point to a broader tension: when an agent acts for a consumer, it can disrupt the platform's control over its interface and commercial relationships.
For the underlying reporting, see MIT Technology Review's coverage of AI agents and the web.
Availability is a real operational concern
Restricting agents isn't automatically anti-consumer. Automated traffic can burn computing resources, distort analytics, trigger fraud controls, or overwhelm human support. If an agent keeps submitting the same request, the business pays the cost - then other customers feel it too, in delays and failures.
The catch is that a broad block often lumps very different behaviors together. Reading public product details isn't the same as sending a high-volume stream of checkout attempts. If a system can't separate those cases, it may protect the platform by excluding useful, user-authorized activity along with abuse.
Commercial control is part of the dispute
There's also a power-and-ownership angle. If a user delegates product discovery and purchasing to an agent, the platform may lose influence over what gets shown, how options are compared, and where the order gets completed. Advertising and sponsored placement become harder to interpret if the user never lands on the page - or never sees the promotions.
That doesn't mean every platform restriction is driven by ads. Security, fraud prevention, reliability, and legal obligations can all be legitimate. Still, the commercial incentives shouldn't be ignored. A site may prefer a human-paced journey because that's where it presents recommendations, promotions, and checkout choices. An agent may prefer a direct route that cuts steps and compares offers across businesses.
A quick way to evaluate a restriction is to ask three questions:
- What risk does it reduce? Fraud, load, privacy exposure, or misuse of the service.
- What user task does it prevent? A blanket automation rule may also block a reasonable request made with the customer's permission.
- Is there a narrower control? Rate limits, verified permissions, or confirmation steps may address the risk without shutting out every agent.
A ban can be a reasonable short-term safety measure. It's harder to justify as a permanent policy when the risk could be handled more precisely.
The business incentives point in both directions
Agents can create costs, but they can also create demand. The source reports that agentic web traffic rose sharply in a short period, with much of that traffic landing on ecommerce sites. It also describes Shopify offering agent-specific checkout lanes.
The real question isn't only "should agents be allowed?" It's whether a company can support them safely and profitably - and whether that support actually improves the customer experience.
Agents can reduce friction and expand access
When an agent is well scoped, it can take care of tedious comparison work, search across a large catalog, or help a user complete a task that's painful to do manually. It might find a cheaper insurance option, compare terms that look similar on the surface, or help someone dispute an incorrect bill.
These uses are valuable because they cut effort, not because they add "another AI feature" for its own sake.
For businesses, agents can also become another route to discovery and sales. If a retailer makes product information understandable to authorized agents, it's more likely to show up in comparisons. A booking provider can offer a structured way to check availability and complete a reservation. In those cases, designing for agents can improve transaction reliability - not just speed up browsing.
That said, the upside isn't guaranteed. If agents generate expensive traffic that rarely converts, or if they increase disputes and mistaken orders, the economics won't hold. Businesses need to track outcomes like completed transactions, support costs, returns, fraud, and customer satisfaction - not just the number of agent visits.
A web optimized for agents could be worse for people
There's also a less attractive path: companies invest in machine-friendly flows and neglect the interfaces people actually use. If you want to browse, compare details, or talk to a real person, you may find the experience worse when the business optimizes for automation first.
Transparency is another concern. If an agent recommends something, the user should know whether the suggestion reflects actual fit and price - or whether it's shaped by advertising, commissions, or platform agreements. If different users' agents receive different offers, it can become harder to tell whether price differences come from legitimate eligibility or opaque personalization.
And then there's verification. Stronger checks may help a site confirm that an agent has permission, but repeated challenges can wear people down. Poorly designed systems can make users "prove they're human" over and over, or demand sensitive identity checks for ordinary tasks. Strong security controls can help - but they're not a complete solution if they make everyday access painful.
The right measure is user outcomes, not automation volume
Companies that add agent-facing systems should focus on whether customers actually benefit. A practical scorecard might include:
- Task completion: Can the agent finish the intended task without repeated retries?
- User control: Does the person approve purchases, commitments, and sensitive disclosures at the right points?
- Fair access: Can users who don't use agents still browse and get support effectively?
- Commercial clarity: Are sponsored results, commissions, and pricing rules understandable?
- Operational health: Do agent interactions increase fraud, support demand, or system load beyond what the business can handle?
This is what makes the evaluation honest. Supporting agents isn't automatically "progress," and blocking them isn't automatically "responsible." The decision should depend on whether the arrangement works for the people paying with money, time, and data.
Rules that can make the agentic web work
The rules for agent access are still forming. Some are straightforward: agents should handle payment info carefully, follow user permissions, and avoid actions a person didn't authorize.
Other questions are trickier. Can a business exclude agents from a service? Should an agent be able to negotiate a better price? What disclosures are needed if commercial incentives affect recommendations?
These aren't only technical questions. They shape competition, consumer protection, privacy, and the economics of online services. A workable system should give businesses real protections without letting every platform use control of its interface to block legitimate consumer delegation.
Build permission around the action
A good design starts with what the agent is allowed to do - not just which agent it is.
Permission to search shouldn't automatically mean permission to book. Permission to compare prices shouldn't mean sharing payment details. A user may want an agent to draft a refund request, then review it before anything is submitted.
Businesses and agent providers can make these boundaries explicit with action-level permissions, spending limits, confirmation steps, and records of what the agent actually did. For higher-risk actions - purchases, account changes, or requests that involve sensitive data - requiring user approval is often a reasonable trade-off. Yes, it adds friction, but the cost of an unintended action can be far worse.
Make access proportional to risk
A blanket ban is easy to implement, but it's blunt. A more durable approach can separate reading public information from submitting transactions and from repeated requests to sensitive services.
Rate limits and authentication can reduce abuse. Structured interfaces can help agents send requests consistently. Human escalation can handle edge cases.
This approach isn't free. It requires engineering, monitoring, and ongoing maintenance. It might make sense for a large retailer with heavy agent traffic, but it may not for a small business that can't support another integration right now. In that case, a clear temporary restriction can be more responsible than an unreliable "agent-friendly" interface.
The key is to say why and revisit the decision as capabilities and demand change.
Keep the economics and recommendations legible
Users need to understand when an agent is acting within a commercial relationship - paid placement, commissions, and anything else that could affect what it recommends. Businesses need clarity on what they're paying for when agents send traffic or complete transactions.
Platforms also need to avoid presenting an agent's choice as neutral when the ranking is materially shaped by commercial incentives.
Transparency won't solve every policy problem, but it enables accountability. If a recommendation is bad, the user should be able to understand how it was produced and who had incentives to shape it. And if a company blocks a class of agents, it should be possible to tell whether that's a genuine security or operational constraint - or a choice to protect a particular sales channel.
Treat agent support as a product decision
If a business is considering agent access, a practical sequence looks like this:
- Choose a specific user task. Start with a real problem - checking stock or booking a slot - not a vague "support AI" mandate.
- Map the authority required. Decide what the agent can read, change, submit, or buy - and where the user must confirm.
- Set operational limits. Define request rates, authentication requirements, payment protections, and escalation paths.
- Measure both sides of the exchange. Track customer outcomes alongside fraud risk, support burden, reliability, and cost.
- Keep a human route usable. People shouldn't have to use an agent to access an essential service or fix an unusual problem.
It's less exciting than announcing an agent strategy, but it's also more likely to hold up once real users and real production systems show up.
Conclusion: design for a web shared by people and agents
AI agents expose a weakness in the web's old categories. They're automated, but they can also represent individual users with legitimate goals. Treating every agent like an ordinary bot will block useful work. Treating every agent like a trusted customer will create security, reliability, and accountability headaches.
The durable answer is to make access proportional to risk, tie permissions to specific actions, and make commercial incentives visible. Businesses should support agents when the user benefit and operating model justify it - and restrict them when they can't yet protect customers or keep the service reliable. Neither choice should shut off a usable path for people.
If you're building a product or running a platform, pick one concrete task and test the full flow: authorization, execution, confirmation, support, and measurement. That's more likely to tell you what you need than a broad promise to make your site "agent-ready" - and it helps ensure the next version of the web works for both humans and the software acting for them.