The term “agentic web” can still sound abstract, but this week I saw three very concrete layers emerging: how agents transact, how they take governed actions, and how they identify themselves.

The agentic economy

In Monday’s market signals briefing, a weekly feature of my new blog Agentic Web News (AWN), I looked at the trends that emerged from last week’s IAB Tech Lab Summit — which was focused on advertising in the agentic web era. While IAB Tech Lab CEO Anthony Katsur was careful to frame this time as the “wild west” era of agentic advertising — invoking the beginnings of previous web eras, particularly dot-com — it became clear that the foundational infrastructure is starting to be laid down.

The IAB Tech Lab has itself created an umbrella framework called AAMP (Agentic Advertising Management Protocols), which is full of acronyms and ‘agentic’ this-and-thats. Even if some of these pieces fall away over time, it’s encouraging to see the advertising and commerce sectors adapting to agentic AI — getting the monetization machinery ready.

There’s also a ton of experiments and early launches happening among the big players — Amazon, Google, Shopify, Stripe, OpenAI and others. In the AWN briefing, I highlighted Amazon’s new Agentic Shopping Assistant as just one example.

Agentic governance

In an interview published this week on AWN, Arcade’s Alex Salazar told me about his company’s “actions runtime” for agents. The idea is to provide a solid and secure middleware layer, based around MCP, for enterprise companies to manage interactions with agents and AI-ified tools.

Incidentally, Salazar came from Okta — a successful identity and authentication company from the cloud native era of the web. This is another thing I am increasingly seeing: technologists and entrepreneurs running their established playbooks with brand new agentic-focused companies. I’m thinking also of my interview last August with ex-Mashery founder Oren Michels, who now runs an “agentic governance platform” called Barndoor.

Taming the wild west for enterprise use is, of course, a tried and true formula for a new startup in any new web era — hat-tip here to my old Web 2.0 blog buddy, Dion Hinchcliffe, who has always been master of this trend. I know we’ll see a lot more ‘agent governance’ plays emerge as the agentic era ramps up.

Agents and identity

Earlier today I published another interview post, this time with Allie Kline from Innovation Labs (a division of the domain name services company, Identity Digital). This post looked at a crucial question for this era: who owns that agent that just visited your site/app, and who is accountable for it?

Whereas Arcade is focused on how agents execute actions safely, DNSid is focused on a more foundational question: before an agent acts, can we verify who stands behind it?

Again, this is still very early and it’s possible that DNSid won’t become the standard protocol we need. But as I noted in my post, agent identity and accountability will undoubtedly become foundational parts of the open web infrastructure moving forward. It has to be defined in an open standards way, too, because we don’t want the big platform companies to define it for us.

Agentic infrastructure

I always find the beginnings of a new web era to be exciting, because it’s where the infrastructural railroad tracks get laid down. I think we’re seeing real evidence of this now in commerce, enterprise IT, and identity.

I will add there are still areas that are lagging in the agentic web — I keep pointing out the compensation layer for content creators as one of these areas of concern, because it directly impacts me. Also, just like the railways of old, there is a risk of monopolies forming, or becoming even more entrenched, because of AI and agents.

But overall, this is a fascinating time in the evolution of the internet. And that’s exactly why I started Agentic Web News: to track these infrastructure shifts as they happen.

The post The agentic web’s infrastructure layer is starting to form appeared first on Richard MacManus.

Where is the business value in agentic technologies? A lot of people are rightly asking this question, as we continue our journey into the agentic web.

This was a big reason why I chose to profile a mainstream web company’s adoption of AI in my first interview post on Agentic Web News, my new tech blog covering this era.

RunSignup is a web platform for race organizers and it is deploying AI chatbots and building agentic infrastructure across its product. But let me be very clear: it’s NOT an AI company. It has tens of thousands of customers and most of them aren’t tech-focused — these people just want a way to organize races online and get runners registered to their events.

What most impressed me about RunSignup’s rollout of AI is that although it’s cutting edge technology, it’s been very carefully — and safely — integrated into the company’s core product.

2 key lessons for integrating agentic AI

If I had to sum up the two key learnings from my interview with founder and CEO Bob Bickel, it’s these:

1. Embed AI where users already work.

Don’t just bolt on novelty chatbots! They need to be integrated into existing workflows. This is especially true if you’re a SaaS platform, like RunSignup. But really, I think this applies to all organizations looking to add AI.

As Bob explained to me, one of the new agents they’re introducing will be integrated into a race director’s dashboard:

“So if you’re a race director, you have a dashboard control and set all your different options, and it has like a hundred menu items in it. What you’ll start to see is that some of these dashboard pages will now have this AI agent — either a little text box that you can chat in, or a circular chat widget that you can click on to perform the task.”

In RunSignup, these agents will augment the workflow that a user (a race director, in this case) is already doing.

2. Move fast, but safely.

In other words, adopt the latest agentic technologies where they make sense to your core product, but do it with safeguards — and don’t rush it out the door. The RunSignup team has a special catchphrase for this: “aggressive patience.”

Bob noted that his team has implemented some 40 MCP tools for internal use, but they haven’t yet rolled these out to the public platform — they’re worried about the safety concerns with vibe coders, for instance. Eventually they will release these tools, because they’re proving to be of great value to Bob’s team. But with AI technology, you really do have to be careful.

I love this approach, because if there’s one thing we all learned from Web 2.0, it’s that “move fast and break things” (the Facebook philosophy) backfired for many companies in that era — including Facebook on several occasions.

“Everywhere in our product, in every screen, there will be an AI agent there.”
– Bob Bickel, RunSignup CEO

Safety is definitely key for AI adoption, but you don’t want to get left behind either. If AI can meaningfully improve your product for your customers, by all means be ambitious! Bob told me about the new AI infrastructure platform his team is building in order to add agentic functionality to RunSignup. “Everywhere in our product, in every screen, there will be an AI agent there,” he said.

So they’re putting resources into building agentic functionality, and will roll it out only when they’re satisfied it is safe to do so. That’s the right approach for basically any company adopting AI.

The trust problem around agentic AI

As part of my field notes this week, I’ve seen some backlash about the agentic functionality Google announced at its I/O conference — apparently some Google search users are jumping ship to DuckDuckGo.

I’ve also noticed the unfortunate tendancy for tech companies to lay off chunks of their workforce and blame it on the need to be “AI-native” going forward. One company even invoked the “agentic web” term in a headline announcing layoffs, which did no favours to my own humble branding efforts.

To put this in the context of this post, I have to admit that bringing AI into companies does have negative consequences as well as positive ones. I’m especially uncomfortable with all the layoffs happening in our industry, which have profound personal and societal impacts (I myself was laid off a few months ago, and do not currently have a regular income). How AI is impacting the job prospects of the younger generation coming into the workforce — my own daughter is in this age group — is something I worry about.

I think this is another reason to heed the lessons of RunSignup: move fast, but safely…and with empathy. Not all your users will have positive views about AI at this time (and some may never have), because of the disruption it is causing to employment, the environment, and society in general.

Let’s be careful out there, as Sergeant Phil Esterhaus used to say in Hill Street Blues. I will try to heed this advice in my coverage of AI at Agentic Web News — do subscribe if you’d like to join me for the ride.

The post Let’s be careful out there: 2 lessons for businesses adopting agentic AI appeared first on Richard MacManus.

Starting today, I’m going to post regular analyst “field notes” about how the agentic web is shaking out. These will be more informal, more observational, and more human.

This week I launched a new tech blog devoted entirely to tracking the evolution of the agentic web: it’s called Agentic Web News (AWN) and is published via the Ghost CMS. I hope you all check it out and subscribe — you’ll get a weekly market signals briefing plus exclusive interviews.

But enough self-promotion. The point I actually wanted to make is that “agentic web”, as a new term to describe this current era of the internet, has really gained traction this week. Which was great timing for my blog launch.

In particular, Google used the term a few times during its developer keynote at Google I/O this week, and in its social media promotions after. I’ve also noticed some other large companies using it — e.g. Parallel Web Systems (led by former Twitter CEO Parag Agrawal) and Adobe.

I think Google getting behind the term is especially notable, though. In its summary of 15 updates from Google I/O, the Chrome for Developers team used this headline: “Powering the agentic web with new capabilities, tools, and features in Chrome” (emphasis mine). In the first paragraph, the team wrote:

“As we enter the era of the agentic web, we see a shift that bridges the gap between complex developer workflows, underlying platform capabilities, and everyday user experiences.”

Obviously, this is very developer-focused. But if you’re as old as I am, you’ll remember that “Web 2.0” as a term first gained traction amongst the developer and entrepreneur community of Silicon Valley. Only after it got a foothold amongst those people, did it slowly fan out into an industry term used more widely.

Also just like in Web 2.0, there are some well-funded new companies that are using “agentic web” as their rallying cry. I mentioned Parallel Web Systems in my debut AWN market signals post this week; and that was just before it launched something called Index: “a platform for content owners to understand how AI agents use their work, and earn revenue when they do.” I’ll dig into Index more on AWN next week, but today I saw this video introduction Agrawal did with The Atlantic’s Nicholas Thompson:

CMSs and major publishing platforms are also starting to adopt the term. Automattic is positioning WordPress as “the Operating System of the Agentic Web,” Webflow says it is “the agentic web marketing platform,” and just this week Drupal founder Dries Buytaert argued that “Drupal is uniquely positioned for what comes next with the agentic web.”

Adobe has gone all-in, using the term in a blog post about the Adobe Experience Manager product, along with a broader positioning statement about Digital Experience Platforms (DXPs). It was also a topic of discussion at a recent Adobe developer conference.

Finally, I’ll note that my own personal web hero, Sir Tim Berners-Lee, is on a panel next week at the IAB Tech Lab Summit 2026. The theme of the summit? “Welcome to the Agentic Web.” I’m very keen to hear what Sir Tim says about this trend. Alas, it’s not an online conference and I can’t afford to fly to NYC right now! But hopefully that panel gets posted onto YouTube later (please IAB Tech Lab).

Regardless of what people call it, there are a lot of questions yet to answer about the agentic web — for example, how is Google planning to make money off it? So even though I’m already hearing about a bunch of new startups being built for the agentic web era, just as I did in early Web 2.0, I’m aware that I also need to pay close attention to the impacts on the wider ecosystem. Like us poor (literally) indie publishers, for one!

That’s my Friday field note for today, let me know if you like this format. And don’t forget to subscribe to Agentic Web News

Lead image: Google I/O developer keynote, which discussed the agentic web.

The post Field notes from the agentic web: Google, Parallel and the market taking shape appeared first on Richard MacManus.

The agentic web is a technical shift that changes what a website is. But more than that, it is a business shift.

As AI agents begin to discover, interpret, and act on websites on behalf of users, businesses will need to rethink how their digital presence works. A website will no longer be judged only by how well it serves human visitors. It will also be judged by how clearly it exposes information, actions, permissions, and trust signals to AI systems.

That matters for business leaders, product teams, publishers, and developers alike. In this post, I’ll outline how each of these four groups will need to adapt.

1. Business leaders

For business leaders, the agentic web raises a strategic question: will your business be accessible, understandable, and usable in an AI-mediated digital environment?

Your first priority should be to shift your mindset from a website strategy to an agent strategy. How you adapt to the agentic AI era will affect discovery, distribution, customer acquisition, trust, partnerships, and operational workflows.

Will agents understand your business?

Agents are becoming an important way that users compare products or services, retrieve information, complete tasks, and make purchases. So your business needs to understand how it appears to those agents. Are your products or services easy to find? Is your content structured clearly? Are your capabilities exposed safely? Can an agent tell what your business does, what it offers, and what actions are available?

Your website becomes a control layer for how AI systems understand and act on your business.

The risk is that your business may still have a website, but it becomes harder for AI systems to interpret, recommend, or act upon. The businesses that adapt early will treat their websites not only as marketing channels, but as part of their AI-era business infrastructure.

2. Product teams

The agentic web changes how your product is accessed. Now, it won’t just be used by people through your interface. Increasingly, it will be accessed through agents acting on behalf of users.

That has some important consequences.

Products become agent-accessible

Your product needs to expose clear, structured capabilities so that agents can discover, understand, and interact with it reliably. It’s no longer enough to have a well-designed interface; you need to make actions legible to machines, whether via APIs, MCP tools, or other emerging standards.

Alongside this, you need to think about agent experience (AX) as part of the broader user experience. How easily can an AI system discover what your product does, understand how to use it, and execute tasks reliably? In many cases, the “interface” your users rely on will not be your UI, but an agent translating intent into actions.

Control becomes part of the product

In the agentic web, control becomes a core product concern. You will need to define what agents are allowed to do, under what conditions, and on whose authority. That includes authentication, permissions, rate limits, and safeguards — all of which will become part of the product surface.

In short: products become platforms for both humans and agents, and success will depend on how well you serve both. Put another way, products will compete not only on usability for humans, but on usability for agents.

3. Publishers

For publishers, the agentic web represents both a threat and an opportunity.

The threat is clear: fewer users will visit your site directly. Instead, AI systems will increasingly intermediate access to your content — summarizing it, extracting insights, and presenting it elsewhere.

From destination to source of truth

But the opportunity is just as significant. Your website becomes the source of truth that feeds those systems.

That means your focus shifts from page views to:

• being discoverable by AI systems;
• being trusted as a source; and
• being structured in ways machines can understand.

Practically, this means:

• ensuring content is accessible (not locked behind barriers);
• using structured data and clear information architecture; and
• thinking about how your content will be retrieved, chunked and cited.

Revenue remains unresolved

Now, having said all that, there are currently major concerns about how publishers will be compensated in this new agentic era. How can we earn a living in a world in which fewer people visit our websites — a problem exacerbated by Google referral traffic drying up.

There is some hope: publisher-friendly companies like Cloudflare are trying to encourage creator compensation from AI vendors, plus there are emerging protocols like Really Simple Licensing (RSL) that aim to help publishers license their content.

But it’s still early days and many publishers are rapidly downsizing (I myself have been impacted). So this is very much an existential crisis for the online media industry — and indeed the open web itself.

From media property to data layer

Even so, the agentic web does open up new product possibilities for publishers, from site-specific assistants (like my own “Ask Ricmac” feature) to premium, agent-accessible knowledge services.

Directionally, a publisher’s role in the agentic web is starting to move upstream: from destination to data layer. Strategically, the goal is to become a trusted, structured, machine-readable source for AI systems — while also defending the commercial value of that content.

4. Developers

For developers, the agentic web expands the scope of what it means to build for the web. You are no longer just building interfaces and APIs — you are building capabilities that agents can discover, reason about, and use autonomously.

That requires a shift in mindset.

Build for machine readability

You need to design systems that are machine-readable by default — not just human-friendly.

Clear schemas, predictable outputs, and well-defined actions become critical.

Think in workflows, not endpoints

You also need to think in terms of orchestration, not just endpoints. Agents will combine multiple tools and services dynamically, so your systems need to behave reliably as part of a broader workflow.

This means developers will increasingly work across a hybrid stack, including:

• browser-based AI (local models, Web APIs);
• cloud-based inference;
• tool protocols like MCP; and
• traditional web infrastructure.

Debugging the agent layer

Debugging changes too. As a16z VC Andrew Chen suggested, the UI may become “a debug layer” and developers will need new tools to understand what agents are doing, why they made decisions, and how to guide them.

In a nutshell, building for the agentic web means building for humans, agents, and the interactions between them.

The business implication is that developer experience and agent experience will increasingly overlap. The easier your systems are for agents to understand and use, the more valuable they become in AI-mediated workflows.

What businesses should do next

The practical starting point is not to rebuild everything for agents. It is to assess how ready your existing website, content, product surfaces, and technical infrastructure are for AI usage.

That means asking:

• Can AI systems discover your important content and capabilities?
• Can they understand what your business does?
• Can they retrieve accurate, structured information?
• Can they distinguish canonical content from noise?
• Are there clear boundaries around what agents can and cannot do?
• Are your APIs, feeds, schemas, metadata, and permissions aligned with how agents will interact with your site?

In other words, the agentic web turns your website into more than a destination. It becomes part of the operating layer through which AI systems understand and act on your business.

Start with an agent experience assessment

If you’re thinking about how to adapt to this shift, my Agent Experience Assessment shows how well your website and related product surfaces work from an agent’s point of view — and what to improve first. You can also request my Agentic Web Playbook to dive deeper into this subject.

Feature image created with ChatGPT.

The post Why the agentic web matters for businesses appeared first on Richard MacManus.

The agentic web is an emerging phase of the internet where AI agents increasingly discover, interpret, and act on websites and digital products on behalf of users.

The key shift is this: websites are no longer only destinations for people. They are also becoming sources of data, context, and capabilities for AI systems.

I’ve been chronicling the evolution of the web for more than two decades, from the dot-com era through Web 2.0, social platforms, mobile apps, and now AI. I see the agentic web not as a sudden break from web history, but as the next major shift in how the internet is used.

Any attempt to divide the web into eras is imperfect, but I’d argue there have been four major phases so far:

1. Read web / dot-com era: from the birth of the web in 1990 through to around 2003, when websites were primarily places to publish and consume information.
2. Read/write web / Web 2.0: from 2004 till about 2012, when blogs, social software, APIs, and user-generated content expanded participation.
3. Platform web: from around 2013 to 2021, when large platforms increasingly mediated discovery, distribution, and monetization.
4. Agentic web / AI era: from the debut of ChatGPT in late 2022 to the present, as AI systems increasingly mediate how people discover and use the web.

If I had to simplify even further, I’d explain the big shifts in the web like this:

READ -> READ/WRITE -> READ/WRITE/AGENTIC

The read era was when a website was regarded as a collection of pages for people to visit.

The read/write era, or Web 2.0, was when ordinary users could publish, share, remix, and participate at web scale — first through blogs, wikis, social software, and APIs, then through smartphones and social media.

The platform colonization era was really an extension of the read/write era, but unfortunately the web got worse (“enshittification” is the word often used to describe this period).

And now we’re entering the agentic web, when it’s not just people using the web — it’s also AI agents acting on our behalf.

A quick history of the agentic web

The word “agentic” comes from “agency”: the ability to take action or choose what action to take. In AI, the term now refers to systems that can pursue goals, use tools, interact with software, and complete tasks with some degree of autonomy.

The power of AI agents has come on incredibly quickly. In 2023, I attended the first AI Engineer conference in San Francisco and wrote at the time that the hype around agents seemed overblown. Even Shawn “swyx” Wang, the conference organizer, told me that agents hadn’t yet proven they could consistently perform basic tasks.

But how quickly things changed. In late 2024, Anthropic introduced the Model Context Protocol, which gave AI systems a standard way to connect with external tools and data sources. In 2025, Microsoft began talking about an “open agentic web,” and the W3C established an AI Agent Protocol Community Group to explore technical foundations for this emerging web.

By the end of 2025, the agentic web had moved from a speculative phrase to a serious topic for platforms, standards bodies, researchers, and product teams.

What does the agentic web mean for websites?

Importantly, this new era doesn’t mean that websites will disappear — although it is true that their business models are under threat from AI products like Google’s “AI Mode” and ChatGPT. But websites, as an artifact of the World Wide Web, will remain the primary way people and organizations share information on the internet. 

The agentic web means a shift from pages to capabilities.

What is changing, however, is the way people reach and use websites. Fundamentally, the agentic web means a shift from the page model to a model based on capabilities.

That’s a huge change, because for most of its history the web has been built around documents. Users browse pages, click links, and navigate interfaces designed for humans. Even as the web became more interactive in Web 2.0 — through blogs, social media, and web apps — the underlying model remained the same: people directly interacting with websites.

In the agentic web, that model is no longer sufficient.

AI systems are increasingly acting on behalf of users — retrieving information, summarizing content, and completing tasks. Instead of navigating a site step by step, a user can delegate intent: summarize this article, find the key points, book this, compare those.

The conceptual changes to websites

There are three key changes happening to websites, summarized in this table:

By “capabilities,” I mean the things a site makes possible for a user or agent: search, retrieve, compare, summarize, subscribe, book, buy, query, configure, or act. In the traditional web, those capabilities were wrapped inside human-facing interfaces. In the agentic web, they increasingly need to be exposed in ways that AI systems can understand and use.

Perhaps the most jarring change is the shift from website as destination to website as a data and context layer. 

You might remember that the dominant metaphor for websites in the dot-com era was that they were places for people to visit. The canonical example is Amazon.com, which initially billed itself as a virtual bookstore. It’s also why personal websites were called “home pages” back then. 

This conception of a website as a destination hasn’t entirely gone away — and I hope it never does, because I always want the web to be centered on people sharing what they know. But in the agentic era, how people access web knowledge is changing. AI systems will increasingly focus on the underlying content, structure, metadata, and capabilities a site exposes.

Why websites still matter

I know it’s a scary time for web professionals, with massive job losses in our industry and a lot of hype around agentic AI. But websites still matter — and in fact, their role is expanding.

Websites will continue to be where people publish ideas, explain products, build trust, establish identity, and create canonical sources of truth. To be effective in this new era, though, they will also need to work with AI systems that act on behalf of users.

Websites are surfaces that AI systems can discover, interpret, and act upon.

In the read web, websites were pages to consume. In the read/write web, more people could participate. In the platform web, sites were increasingly mediated by large distribution systems. Now, in the agentic web, they are becoming surfaces that AI systems can discover, interpret, and act upon.

That means AI agents are becoming a new class of user for websites and digital products. They do not browse like humans. They extract, compare, summarize, cite, and increasingly act.

Adapting to the agentic web

If you’re thinking about how to adapt to this shift, I offer an Agent Experience Assessment that shows how well your website and related product surfaces work from an agent’s point of view — and what to improve first.

In future posts, I’ll look more practically at what this means for site structure, metadata, content design, APIs, agent protocols, and AI-facing product experiences. Subscribe by email or RSS, or follow me on LinkedIn, to get notified.

Feature image created with ChatGPT, via prompting.

The post What is the agentic web? The evolution from read/write to agentic appeared first on Richard MacManus.

The term “agent experience” (AX) was popularized in January 2025 by Matt Biilmann, CEO of the developer platform Netlify. For its first year or so, AX was mostly discussed as a successor to “developer experience” (DX): if AI agents were going to help build and deploy software, then those platforms needed to become easier for agents to use. 

Over a year later, we’re seeing agents increasingly become users of websites and apps. So AX is now evolving into a new branch of user experience (UX).

Biilmann himself acknowledged this in a one-year anniversary post for the term, noting that “we’ll go from a world where AX is primarily understood as a new type of developer experience, to a world where AX will be as generally applicable as UX itself.”

I’ve been calling this new era of human/agent interactivity the agentic web. In a funny way, it’s an inversion of the “read/write web” trend that I chronicled in a previous era. In Web 2.0, the key shift was (human) users going from simply consuming the web to producing it too. But in the age of generative AI, agents began by “writing” to the web (developing websites and apps) and have now moved to the “reading” part (using those sites and apps, on behalf of human users). Hence the shift from DX to UX.

AX was the new DX. Now AX is becoming the new UX. 

As noted, the main reason for this shift is that AI agents are now active users of the web. In fact, Google just updated its guidelines for website operators, asking us to “build agent-friendly websites” now.

Another way to put this is to design your website with “agent usability” in mind. Build for how agents use your website or app, in addition to how your fellow humans use it.

If you want to go even further, and add more acronyms, I quite like this framing from Liad Yosef, a co-creator of MCP Apps:

The future of UX comes down to two things:
1. How an agent experiences your product
2. How a human experiences that agent
UX = AX + UAX

But let’s stick with AX to keep things simple Speaking of acronyms…

ASO as the new SEO

Since we’re increasingly focused on non-human visitors to our websites and apps, naturally the massive SEO industry has become laser focused on how to optimize for this new type of user. A big wake-up call to this industry was the recent news that Adobe has completed its acquisition of the SEO firm Semrush.

Adobe positioned the acquisition as “enhancing its ability to offer businesses more capabilities to drive discoverability and conversion as AI interfaces and agents become a primary way for customers to discover, evaluate and engage brands.” (emphasis mine)

According to Adobe, SEO has now become ASO (agentic search optimization). Actually, there are several other acronyms vying for primacy among Adobe’s customer base, such as Generative Engine Optimization (GEO), Answer Search Optimization (ASO) and AEO (Answer Engine Optimization). 

Whatever the winning acronym turns out to be, the underlying trend is clear: marketers are no longer optimizing only for human searchers. They are optimizing for AI-mediated discovery and decision-making. Longer term, we’ll be optimizing for more and more autonomous agents, which may even have minimal human oversight.

In response to the Adobe-Semrush news, Amanda Pressner Kreuser — managing partner of a content marketing agency called Masthead — wrote on LinkedIn that “your content and marketing teams need to skill up in areas they’ve never touched before, like structured data, schema markup, product feed architecture.”

As Kreuser noted, most SEO professionals are already skilled in structuring content. But, she added, “most SEO people are execution-focused, not strategy-focused, and ASO is a strategy problem.”

I would go further. This isn’t just a question of “how do we optimize content for AI agents?” The critical question now, from a marketing and design point of view, is “how do we design systems that AI agents can actually use?”

This brings us back to AX, agent experience. In the agentic web era, your website is no longer just a destination — it’s an interface that ideally exposes capabilities that agents can use. Which is why agent workflows are so important to design for and test now.

This is precisely what I now offer through my Agent Experience Assessment: a hands-on review of how AI agents discover, understand, and interact with your website, content, documentation, APIs, and product surfaces.

The End of a Web Development Era

The shift in focus from DX to UX — except now a UX for humans and agents — also signals the end of an era in web development. The Javascript framework era, as I think we can now call the 2010s and early 2020s, was dominated by DX: making the developer’s life easier by abstracting away as much complexity as possible. The problem, of course, was that much of the benefits of DX came at the expense of users: often including a massive JS payload that had to be downloaded by the client before someone could even use your app.

JS framework bloat is still an issue for human users, but now the focus is moving back to the underlying semantic structure of a website — because that’s how machines will interact with it. 

Let’s put it this way: agents don’t need fancy JavaScript features; they need structure, state, permissions, and reliable ways to retrieve or act.

When I interviewed Matt Biilmann about AX in early 2025, he told me that the genesis of the term was Netlify’s integration with ChatGPT — which in turn led his company to the realization that “we needed to give it [ChatGPT] some specific flows around authentication and handovers and so on.”

At that point, AI systems were being used to help create websites via back-and-forth prompting. That trend has only accelerated over the past year and a quarter. It’s now common for developers (and increasingly, normal web users) to deploy a team of agents to build a website for them — often with little to no input from the “developer,” other than the starting prompt. So flows like authentication and handovers are now almost completely handled by agents. 

This has turned into an awesome business for Netlify and similar web development platforms, like Vercel and Cloudflare. Now that anyone can be a developer, there’s been a surge in new users for all these companies. 

To be frank, it doesn’t really matter now what the developer’s experience is, since everything has been abstracted away by AI. You could even argue that DX is merely a question of how easy it is to talk to an AI system! 

I’m exaggerating a little, but the point is this: the focus has rightly shifted back to the user experience. Increasingly, that will primarily be about how agents use your site or app (on behalf of humans).

It’s time to go beyond traditional UX

Here’s my current definition of AX:

Agent Experience (AX) is how well AI agents can discover, understand, and interact with your website, product, content, and digital services.

That includes visibility, but it’s much more than that. The more important part of AX is whether agents can actually use your website, app or digital product.

To explore this further, you can request my 36-page Agentic Web Playbook, or read more about my Agent Experience Assessment.

Image credit: Unsplash

The post Agent Experience: why AX is becoming the new UX appeared first on Richard MacManus.

In every major phase of the web, patterns matter. They help people move from abstract trends to practical things they can actually build. That was true in the early Web 2.0 era, and I think it’s true again now with the agentic web.

One of the sections people have responded to most in my newly released Agentic Web Playbook is the set of “core patterns for AI on websites” that I outline there. As I noted in the playbook, these four core patterns show what to initially build on the agentic web (I also wrote about the why and the how, in separate sections). Because the agentic web is still early, with key standards and platforms still being developed, this is very much a transition stage. So half the battle is knowing what you can build to get started.

There’s an old web maxim that I always point to no matter what phase of the internet we’re in: learn by doing. The best way to learn a set of web technologies is to actually use them, even if they’re not mature yet. That’s why I included these patterns; they provide a practical entry point into the agentic web.

This idea takes me back to the early Web 2.0 era, when I was also trying to understand a new phase of the web through patterns.

My Web 2.0 patterns story

In 2005, I was contracted by O’Reilly Media to write a book about the then-nascent “Web 2.0” trend. My co-writer on the project was Joshua Porter, a web designer, and our goal was not only to explain Web 2.0, but to outline the emerging “design patterns for Web 2.0.” Unfortunately, the book was cancelled in early 2006, so our project never got to see the light of day.

Later, in November 2006, O’Reilly released a 100-page report by John Musser, Web 2.0: Principles and Best Practices. It was more business-focused than the design-patterns outline Josh and I had been working on, but it addressed a similar need: helping people understand the practical patterns behind a new web era.

One of the primary sections of John’s report was the “Eight Core Patterns” of Web 2.0, which were based on Tim O’Reilly’s main talking points for Web 2.0. I won’t go through all eight patterns here, but the first one captured the spirit of the era: “harnessing collective intelligence.” It was described by John as follows:

“Create an architecture of participation that uses network effects and algorithms to produce software that gets better the more people use it.”

As exemplars of that pattern, John’s report listed Google, Wikipedia, Flickr, Amazon and del.icio.us. Flickr’s “architecture of participation” was probably the easiest of those five for other businesses to copy and implement on their own websites: create a site that encourages users to upload something valuable, such as photos, and then make it easy for others to comment on, share, tag, and organize those contributions.

You get the idea. This and the other seven Web 2.0 patterns were a guide to getting started in a new era of the internet. Let a thousand Flickrs bloom, to twist another common Web 2.0 refrain.

Agentic web patterns: starter for 10

Now, I don’t claim that my agentic web patterns are as polished as John’s Web 2.0 patterns. By the time his report came out, it had been over two years since the first Web 2.0 Conference was held. So the patterns for that era had matured, at least a little. My sense is that the agentic web is currently where Web 2.0 was in 2004: early, messy, exciting, but not yet fully legible. Some of the key technologies — including WebMCP and on-device AI — are still emerging, and are not yet widely available to everyday web users.

That said, here are my four core patterns for the agentic web circa early-2026:

1. On-site assistants
   — Add embedded AI assistants to your website to help users ask questions, explore content, and find relevant next steps.
2. Hybrid AI systems: local + cloud
   — Combine on-device and API-based models to balance performance, cost, privacy, and control.
3. Agent interaction: MCP-style capabilities
   — Expose structured actions and data so AI agents can interact with your site programmatically.
4. AI as the interface layer
   — Let AI become a conversational layer on top of your site, so users can search, navigate, and act through intent rather than fixed menus and links.

Underneath all four patterns is a shared requirement: machine-readable structure. Your content needs to be accessible, well-structured, and understandable to AI systems; without that foundation, these patterns have little reliable material to work with.

These agentic web patterns will expand and solidify over time, just as Web 2.0 patterns did. But even now, they offer a practical starting point for bringing AI into your website, product, or app.

If you’re interested in exploring these patterns in more depth, you can request my Agentic Web Playbook and I’ll send you a copy:

Photo credit: Phil Hearing on Unsplash

The post Agentic web patterns: what Web 2.0 taught me appeared first on Richard MacManus.

I’ve put together a guide — The Agentic Web Playbook — on how to add AI to your website.

Over the past year, I’ve been thinking a lot about how AI is changing the web, particularly how people actually use websites. Instead of navigating pages directly, users are increasingly relying on AI systems to answer questions, summarize content, retrieve information, and in some cases take actions on their behalf.

I call this shift the Agentic Web: a web where AI agents don’t just read content, but act on behalf of users. In this model, interaction moves away from direct navigation and toward delegation, with AI systems increasingly mediating how people access and use information online.

At first glance, this looks like a threat to websites. If AI sits between you and your users, what role does your site itself play? It’s a reasonable concern, and one that’s often framed in terms of declining traffic or loss of control.

But the more I’ve looked into it, the more I think the opposite is happening.

Websites are becoming more important — not less. They remain the one place where you fully control your content, your brand, and your user experience. In an agent-mediated world, your site is no longer just a destination for human visitors — though that is still fundamental to the web. It also becomes the source of truth that AI systems rely on, and the layer where you define how they work with your content.

Your website as the control layer

Over the past few months, I’ve been exploring the agentic web from both a conceptual and practical perspective. That’s included building an on-site AI “article assistant” and experimenting with local versus cloud-based models in the browser, implementing a protocal called WebMCP to better control how agents use my website, and adding an AI chatbot to my site. I’ve also been paying attention to how different kinds of sites show up (or don’t) in external AI systems like ChatGPT and Perplexity.

One thing that has become clear is that most websites are not designed for how AI systems actually interact with them. They tend to be hard to parse, inconsistent in structure, and not particularly well suited to retrieval or programmatic use. As a result, they either don’t show up effectively in AI outputs, or they are used in ways that the site owner has little control over.

This creates both a risk and an opportunity. The risk is that platforms — whether AI assistants, search interfaces, or aggregators — increasingly sit between you and your users. The opportunity is that your website becomes more important as a control layer: the place where you define how your content is accessed, interpreted, and ultimately used.

How to adapt to the agentic web

My sense is that the sites that do well in this next phase of the web won’t be the ones that rely on external AI platforms, but those that integrate AI into their own products over time.

With that in mind, I’ve created a PDF guide that I hope will be useful to website operators, product managers, and developers. It’s called The Agentic Web Playbook: how to add AI to your website (without losing control).

The aim of the playbook is to be practical rather than theoretical. It looks at the patterns that are starting to emerge — things like on-site assistants, hybrid local/cloud AI systems, and early forms of agent interaction — and explains how they fit together. It also includes a real implementation example (the article assistant I built), along with a checklist you can apply to your own site.

If you’re thinking about how AI is changing the web — particularly from a product, engineering, or content perspective — it will give you a clear starting point.

You can request the playbook by filling in this form:

I’ll then send you the playbook directly by email.

I’m also starting to offer an Agent Experience Assessment, which is a structured assessment of how AI systems interact with a given site and what to prioritize next. I’ll write more about that separately.

If you do read the playbook, I’d be interested to hear what you think.

The post How to add AI to your website (without losing control) appeared first on Richard MacManus.

When Tim Berners-Lee created the World Wide Web, his goal was to foster collaboration between people. Even today, in the AI era, websites are still fundamentally a human construct. You create a website to share what you know, or to reach customers, or as a home base for you or your organization.

The difference today is that people will increasingly deploy AI agents to interact with our websites on their behalf. You might say we’re moving from a read/write web, where we can both browse and create websites, to an agentic web — where we can read and write the web with the help of agents.

As website publishers or operators, it’s up to us to adapt to this new agentic reality. While we will continue to publish our sites for our fellow humans, we have to recognize that how we reach those people will increasingly be through AI intermediaries. So, the way we build and deploy websites has to change accordingly.

Websites as capabilities

The shift we’re undergoing due to AI comes down to this: we’re moving from a world of websites as content, to a world of websites as capabilities.

Instead of just offering up information, websites will increasingly expose actions that AI systems can take. You might say, well isn’t that what APIs (Application Programming Interfaces) are for? In a sense, yes. APIs already expose a site’s capabilities, but they are designed for developers and typically require explicit integration. They define a fixed set of operations that another system can call in a structured way.

An agent can decide in real time how to use your website.

What’s changing is that AI systems can use those capabilities dynamically, rather than relying on predefined integrations. An agent can decide in real time which tools to use, how to combine them, and when to call them. This makes those capabilities far more accessible. Also, because AI systems use natural language, anyone can use them — so it’s not just developers who can take advantage of what your website offers.

You’re in control

To be clear, you as the website owner are still in control of how AI systems — especially agents — can use your site. In fact, that’s one of the benefits of the agentic web: there are emerging protocols and standards that give you that control.

In practice, this will increasingly be expressed through identity and permissions. Just as users today log into websites and grant apps access via OAuth, agents will need a way to act on a user’s behalf with clearly defined scopes. That means new patterns for authentication — where an agent can prove who it represents, what it’s allowed to do, and under what conditions.

You as the website owner are still in control of how AI systems — especially agents — can use your site.

Early work is already underway: from the World Wide Web Consortium’s AI Agent Protocol Community Group, which is exploring agent identity and inter-agent authentication, to emerging extensions of OAuth and OpenID Connect designed for delegated agent access. This is still early, but it will become a foundational layer of the agentic web.

Let’s now look at four of the key driving forces behind the agentic web.

1. Websites are exposing capabilities

The Model Context Protocol (MCP) has been the primary way websites have opened up their data, tools and services to AI systems. MCP was created by Anthropic and launched in November 2024; since then it’s become a leading method for AI agents and chatbots to trigger external actions.

While MCP is widely used to connect LLMs to web apps, there are more specific protocols and standards emerging that are more suited to websites in the browser.

WebMCP, which I have implemented on this very website, is a model where web pages expose MCP tools directly to the browser so that AI assistants running there can interact with them. WebMCP is still early — your users either need a browser extension (MCP-B) or an experimental version of Chrome to make use of it. But, eventually, WebMCP will become a native browser capability; and likely much easier to use than it is now.

From content to actions

The most common way websites are exposing new capabilities in 2026 is via a custom chatbot. I built a chatbot called Ask Ricmac for my website. Here’s how it works: instead of searching my site manually, a visitor can ask a question and receive an AI-generated answer based on the articles I’ve written over the years. As with the general purpose chatbots we’ve become familiar with over the past few years, like ChatGPT and Claude, Ask Ricmac is connected to a cloud-based AI system to deliver its answers (in my case, Cloudflare Workers AI). The difference is that the AI is using my website content as a knowledge base, which it accesses via a vector database.

Think about how your services will be consumed programmatically by agents.

As these capabilities mature, they won’t just return information — they will increasingly execute transactions. Booking a trip, purchasing a product, subscribing to a service: these are all actions agents can perform on a user’s behalf. That introduces an economic layer to the agentic web, where websites are not just sources of content or tools, but endpoints for value exchange. Designing for this means thinking about payments, pricing, and how your services are consumed programmatically by agents.

2. User interfaces for websites are changing

We’re starting to see early agentic systems emerge — from tools like Claude, which can take actions on a user’s behalf, to more experimental projects like OpenClaw that explore multi-agent control of computers.

As website operators, we want agents like this to visit our websites and gather information or take actions. Although, of course, we’ll want to control that access.

The first generation of AI systems interacting with websites involved a lot of ‘dumb’ browsing, from so-called “headless browsers” like Playwright autonomously running tasks in the background. I say ‘dumb’ because often the AI systems used brute force tactics to surface the content they required (web scraping) or action a specific task (filling in a form, for example). Needless to say, website owners had little control over this process.

Agentic tools are becoming much smarter and more capable of interacting with websites.

But AI systems ‘browsing’ your website are becoming smarter, which in turn is impacting how we as website operators think of user interfaces. A few different trends are driving this.

Firstly, as explained above, the second generation of AI systems interacting with websites has a lot more guidance from website owners on where to find certain information or capabilities to run. Secondly, AI is getting baked into mainstream browsers like Chrome and Firefox — essentially making agentic functionality a native part of consumer web browsers. Thirdly, agentic tools are becoming much smarter and more capable of interacting with websites; tools like Anthropic’s Claude and OpenAI’s various apps.

From browsing to prompting

As one example, Ghost CMS founder John O’Nolan recently blogged about his experience using Claude’s CLI (command-line interface) as a way to interact with websites. He remarked:

“We’ve spent 10+ years focusing on having a clean, well designed interface for Ghost. It’s something we care a lot about, and spend a lot of time on.

But within about ~1hr of using Ghost via Claude/CLI, it was hard to imagine going back to caveman-clicking around a browser to get something done. Particularly for complex or compound tasks that might require visiting several different areas of the app.”

O’Nolan ended up building a custom CLI tool for Ghost, called ghst.

Browsing will become more tied to natural language prompts.

I mentioned OpenAI’s apps, too — recently, the Wall St Journal reported that OpenAI is building a desktop ‘superapp’ that will combine ChatGPT, the Codex app and the Atlas browser. This suggests that “browsing” will become even more tied to natural language prompts than it is now.

This shift also changes how users discover websites. Instead of navigating via links or search results, users increasingly rely on AI systems to retrieve and synthesize information for them. That puts more emphasis on how your content is structured, how easily it can be extracted, and whether it is considered a reliable source. In effect, traditional SEO evolves into something closer to “AI retrieval optimization” — where the goal is not just to rank, but to be selected and cited by AI systems.

3. The browser is evolving

Even if traditional web browsers survive, they will undoubtedly have more and more AI baked into them. This means that the browser will effectively become an AI runtime.

A key trend to track here is the rise of on-device AI, or “local AI” — where an AI model, sometimes called a Small Language Model (SLM), runs on your computer or smartphone instead of in the cloud. This allows AI systems to run completely on your device, allowing your browser to be a full runtime for AI applications.

The browser as an AI runtime

In my continuing agentic web experiments, I built an “article assistant” that can answer questions about a page using local AI in the browser — with a cloud fallback when needed. If you’re reading this post on my website, you can see this in action under the second paragraph.

From a user point of view, here’s how it works: I downloaded Google’s Gemini Nano model onto my laptop, which I can then use to run AI queries on websites that have enabled this functionality (like on ricmac.org). Now, as with WebMCP, this functionality is currently restricted to experimental versions of Chrome. So on-device AI is still very early in its evolution. But directionally, the trend is clear: increasingly you will run AI systems locally, especially for applications where privacy and speed are paramount.

Much of the evolution of the agentic web can be understood as a shift from browsing to tools.

Broadly speaking, there are two ways AI systems interact with websites today. The first is browsing mode — navigating pages, extracting content, and interacting with interfaces much like a human would. The second is tool mode — where the website exposes structured capabilities that an agent can call directly, without needing to parse the UI. Much of the evolution of the agentic web can be understood as a shift from browsing to tools.

4. Developer platforms are adapting

One of the most encouraging things about the AI era is that web technologies have become central to the technology stack. This makes it fundamentally different to other internet revolutions of our recent past, like smartphone apps (which run on non-web mobile environments, largely controlled by Apple and Google) and blockchain (which, despite all the talk of turning into an application platform, still barely uses the web). But the AI revolution is well and truly web-based.

All those vibe-coded apps people are building? They’re typically running as web apps on platforms like Cloudflare, Vercel and Netlify. Indeed, those companies have all experienced explosive growth due to AI applications. Vercel founding CEO Guillermo Rauch recently told Fortune that it has “seen a tremendous acceleration on deployments” and that “fundamentally, we want to become the infrastructure layer of this new generation of software.”

While agents aren’t necessarily web-based, they are typically using a web frontend.

As well as hosting apps, companies like Vercel are increasingly hosting AI agents. While agents aren’t necessarily web-based, they are typically using a web frontend — Vercel’s frontpage for agents highlights the use of Next.js (its open source React framework) to build the “user input” layer for agents. Vercel also notes that agents can connect to “external tools with MCP endpoints.”

The web as the AI application layer

All of the big AI companies are building developer platforms — which are either web-based or use web technologies as the foundation of the user interface layer.

One of the first such initiatives was MCP-UI, a 2025 MCP ecosystem project closely aligned with Anthropic and used by Shopify (amongst others). Basically, MCP-UI enabled developers to build Web UIs for their AI chatbots.

Soon after, OpenAI launched Apps SDK, along with AgentKit and other UI tooling. While these tools cover various development platforms — including the web, iOS and Android — OpenAI’s approach to UI has been similar to MCP-UI, in that it’s fundamentally based on browser technologies.

Some services that now exist as apps might become entirely agentic products.

Towards the end of last year, MCP Apps was announced. It’s a proposed open standard “for interactive user interfaces in the Model Context Protocol” and is supported by both Anthropic and OpenAI. Shortly after, Google launched A2UI, an open source project to help developers build “agentic user interfaces.”

It’s also possible that some services that now exist as apps might become entirely agentic products and not have any human UI at all. Or at least, as a16z VC Andrew Chen put it, “the ui is just a debug layer for humans to peek into what the agents are doing.” That might become the case for some transactional services, such as travel apps. But even then, most of those services will still have a website for branding purposes.

Trust becomes part of the interface

As agents take on a greater role in interacting with the web, trust becomes a critical factor. AI systems need to determine which sources are reliable, which actions are safe to execute, and which outputs can be verified. This is driving renewed interest in areas like content provenance, reputation signals, and verifiable data sources.

Credibility becomes a technical property.

For website operators, this means that credibility is no longer just a brand concern — it becomes a technical property that influences whether agents choose to engage with your site at all.

What’s next on the Web

The agentic web won’t replace the web, but it will change how it is used.

Websites will continue to exist as places where people publish ideas, build products, and express identity. But increasingly, they will also function as endpoints for agents — systems that retrieve information, execute actions, and mediate how users interact with the web.

The agentic web is an evolution of the original web.

In that sense, this is less a break from the original vision of the web than an evolution of it. Tim Berners-Lee imagined a system for sharing knowledge between people. What’s emerging now is a system where that knowledge can also be accessed, interpreted, and acted upon by machines on our behalf.

The key shift is not from humans to AI, but from interfaces to capabilities — from navigating websites to invoking what they can do.

For anyone building on the web today, the implication is clear: you’re no longer just designing pages or apps. You’re designing how your site will be understood and used by agents.

Feature image: Original WWW graphic by Robert Cailliau.

The post The agentic web: how AI systems will change websites appeared first on Richard MacManus.

I’ve been using the term “Agentic Web” a lot in recent articles to describe what I’m exploring: how AI systems integrate with the open web. Another term you might be familiar with is “Web AI,” which derives from Google and has a more specific meaning: running client-side AI in the browser.

Google’s concept of Web AI includes doing the inference — when AI models process queries — on your local device, rather than in the cloud. To achieve this, you need to install a small on-device model (often called a “small language model” or SLM). Not coincidentally, Google has just such a product for you: Gemini Nano, an on-device model of typically a few gigabytes, which is much smaller compared to large cloud models that require significant server-side resources.

Running inference locally is a relatively edge case at this point in time. It’s increasingly possible to run MCP-connected applications in the browser — such as my own Ask Ricmac chatbot — but the actual AI processing is typically done in the cloud (in my case, I use Cloudflare Workers AI). Even with WebMCP, an emerging protocol that enables websites to expose structured capabilities to AI agents, the idea isn’t that everything is done locally; rather, it’s that the browser becomes a mediator between your website and (mostly) cloud-based AI.

Running AI models locally does have a lot of potential, though: primarily, it gives the user much better privacy controls, because your private data isn’t going back and forth from the cloud. Also, you’re not paying a cloud provider per request. Finally, using SLMs can reduce latency (although, as I will explain, right now that’s not feasible for many of us).

Over time, local AI — sometimes called “on-device AI” — will become increasingly viable, as our computers and smartphones increase RAM and storage capabilities, and also as AI models get ever smaller and smarter.

Given the clear potential, I wanted to test local AI here on ricmac.org. So in this post I’ll describe how I implemented an “article assistant” on my technology analysis articles, which defaults to local AI if available.

This feature — which you can see in action on this very post on my website, under the second paragraph — allows readers to ask questions about the article or generate a quick summary. On supported browsers it can run entirely locally; otherwise it uses cloud AI.

This post is a conceptual walkthrough of how my article assistant works, and what each piece of the stack is responsible for.

The starting point: AI that runs on your machine

The first piece of the puzzle was getting a model running locally in the browser. For this, I experimented with Gemini Nano — Google’s lightweight, on-device model designed to run in environments like Chrome.

It’s important to note that to use Gemini Nano in my app, I will be relying on Google’s built-in AI APIs for developers (which are currently only available in Chrome’s experimental builds, such as Canary). So practically speaking, I’m not invoking the model directly. My code will call a browser API, and Chrome handles the rest — routing the request to its on-device AI runtime, which runs Gemini Nano locally if it’s available.

Back to Gemini Nano. The first problem I ran into was that I needed about 22GB of spare storage on my computer to run it. My current laptop is a 2022 Macbook, so it doesn’t have state-of-the-art specs. In fact, when I first went to install Gemini Nano, the process failed as I only had about 11GB of storage to spare. So I had to delete a bunch of old applications; I also cleared about 15GB of cache, which finally gave me more than enough space.

You also need at least 8GB of RAM to run Nano; my laptop has exactly 8GB. Because my device is at the minimum required level of memory, I later discovered that the inference was slower than using a cloud AI model (hence my note above about latency not necessarily being better when running a model locally!).

All this means that local AI in the browser is far from being a universal runtime at this time. At best, it’s an emerging capability that only works in quite specific conditions.

So that shaped the architecture of my article assistant: local AI couldn’t be the only path. It had to be one option. I’ll get to how I dealt with that later in this post, but for now let’s stick with the local AI implementation.

Local AI in Chrome: a new kind of runtime

Once I had Gemini Nano available, the next step was wiring it into my webpage.

As noted above, the model is exposed through browser APIs, which means:

• The execution happens locally
• There’s no dependency on external infrastructure

Conceptually, this is a shift for all of us who’ve gotten used to the ChatGPT or Claude model of AI, where the AI inference is done in the cloud.

In this case, the browser is no longer just a client talking to an AI service — it’s becoming an AI runtime itself. As Microsoft’s Maxim Salnikov put it in a LinkedIn post earlier this week:

“The web platform has always been about reach and universality. Now it might also become one of the most important runtimes for AI.”

If the runtime concept sounds familiar, that’s because web applications these days commonly run using a variety of client-side tricks, using React and similar JavaScript frameworks. There are other similarities. Like some of the more notorious React apps, using local AI requires a hefty upfront “cost” in terms of the initial download. Although, unlike with React apps, it’s a one-time (or infrequent) cost for the user.

Anyway, once I got local AI up and running, I created a JavaScript file (with the help of ChatGPT) for the article assistant. It had the following architecture:

Extract sections of the article → chunk by headings → rank chunks against the question → send only the best chunks to Gemini Nano

I also added clickable citations in the answer, which when clicked will take the reader to the exact location in the article that was referenced.

So, at this point I have a working prototype for using local AI on my website. However, given that most readers who visit my site will not have Gemini Nano or a similar local model running on their devices, I needed a cloud AI fallback.

When local isn’t enough: introducing a fallback

To make the assistant usable for all site readers, I introduced a second path: a cloud-based model, to be invoked if local AI isn’t available. To enable this, I built a simple routing layer that tries local first, then falls back to cloud if needed.

The routing logic in this system is deliberately simple. Rather than trying to evaluate the quality of responses or score different models, the decision is made upfront based on capability:

• If local AI is available in the browser, the query is handled locally
• If not, it falls back to the cloud

This reflects the current state of local AI on the web. As noted above, browser-based models like Gemini Nano are still experimental and only work under specific conditions, so availability necessarily becomes the primary routing signal.

Over time, this could evolve into something more dynamic — where the system tries local first and escalates to the cloud for a better answer, if needed. But for now, a capability-based router keeps things predictable and easy to reason about.

One subtle UX issue emerged from this: how to communicate which route will be used. After the user clicks the “Ask about this post” button, a popup displays with a prompt to ask a question. But until the user clicks the submit button, it’s unclear if the system will choose local or cloud AI. So as a default, I put “Mode: Ready.” Then when the user submits the question, the mode status will change to either “Local AI” or “Cloud AI,” depending on what is available.

The cloud path: adding context and scale

For the fallback, I’m using a cloud-based pipeline that uses a subset of the Cloudflare AI tools that my Ask Ricmac feature uses.

The main difference is that Ask Ricmac is a site-wide chatbot, whereas Article Assistant is limited to a single article. In the latter case, the browser sends selected chunks of the article to a Cloudflare Worker, which then calls a cloud model to generate the answer. So there’s no need for a vector database or sitewide retrieval layer, because the relevant context is already present in the page.

What I ended up with is a single interface — the “Ask about this post” box — backed by two very different execution environments:

• The browser (local, small model)
• The cloud (larger external model)

From the user’s perspective, this complexity is mostly hidden. They just ask a question and get an answer. Curious readers may notice the mode status, but it’s not essential to use the feature.

What this experiment suggests about the Agentic Web stack

Building this has clarified something for me about where the Agentic Web stack is heading.

We’re moving toward a model where:

• The browser will increasingly run lightweight and/or privacy-centric AI tasks locally;
• The cloud will remain the default path for heavier reasoning and broader context (simply because that’s where larger models will always live); and
• Websites will orchestrate between the two.

This is quite different from the current paradigm, where almost all AI interactions are centralized in a handful of platforms. What I love about the “local AI” paradigm is that intelligence will become more distributed and more under the control of the user — both key factors in web systems.

Giving your website visitors a way to use their own personal AI model to interact with your web content is a huge boon for the open web.

Think about how much power ‘big tech’ has on our online lives these days, with its opaque algorithms and invasive data snooping. If you’re able to offer your web readers a way to use their own personal AI model to interact with your website, that’s a huge boon for the open web.

One further note: even though I do expect the cloud to always be where the most sophisticated AI models will live, we can reasonably expect local models (like Gemini Nano) to rapidly increase in power. As Jason Mayes, who leads Google’s Web AI efforts, put it to me last November, “at some point, we’re going to have a model in the future that’s as good as today’s cloud models, [but] that fits on-device.”

When that happens, Mayes thinks that “maybe for 95% of use cases, you won’t need to delegate to the cloud.” In other words, local AI might soon become the default option for websites and web applications — rather than the exception that it is today.

What’s next

There are a lot of directions this could go next:

• Smarter routing (e.g. deciding upfront whether a query needs the cloud)
• Better use of local models (as they improve)
• Deeper integration with page capabilities (via WebMCP-style tools)
• More transparent UX around how answers are generated

But even in its current form, this experiment feels like a glimpse of something larger. It’s more than just “AI on the web.” This feels like AI adapting to the best aspects of the web: giving users more control, giving web publishers more options on how to use their content, removing some of the cloud-based leverage Big Tech has over us, and better privacy for all.

Feature image via Unsplash.

The post Building an article assistant: local AI in the browser with cloud fallback appeared first on Richard MacManus.

One of the most interesting ideas emerging in the Agentic Web ecosystem is that websites themselves can expose capabilities directly to AI agents. Instead of scraping pages or relying entirely on APIs, an agent can interact with a site through structured tools defined by the site owner. I love this, because it gives power (or, ahem, agency) back to website owners.

Structured tooling is a core idea behind Model Context Protocol (MCP): websites or applications publish capabilities — such as searching content or performing actions — and AI systems can call those capabilities as tools.

In the browser environment, that idea is evolving into WebMCP: a model where web pages expose MCP tools directly to the browser so that AI assistants running there can interact with them.

But WebMCP is still very early. It isn’t a formal web standard yet and is currently being discussed in a W3C community group exploring how AI agents could interact with web pages. So one of the most practical ways to experiment with this architecture today is through MCP-B (the “B” stands for “browser”), an extension that acts as a bridge between web pages and MCP-compatible AI agents.

However, things are moving fast. Last month, Google released an experimental implementation of WebMCP-style browser tooling as an early preview in its Chrome Canary development browser. So once a version of this is released more widely in Chrome and other browsers, you won’t need a browser extension to run WebMCP on your website.

For now, there are two different approaches to implementing WebMCP:

• MCP-B, which acts as a bridge for today’s browsers.
• WebMCP in Chrome Canary, an early preview of native browser support.

I tested both approaches on my personal site, ricmac.org, and I’ll describe my findings in this post. Together, they offer a glimpse of how websites may soon become AI-interactive surfaces rather than passive pages.

MCP-B: a bridge for today’s browsers

You can think of MCP-B as a kind of polyfill for WebMCP. It enables web pages to register MCP tools using JavaScript, while the extension — which works with Chrome, Edge and Firefox — handles the communication between those tools and an AI agent.

In other words:

• The web page defines the tools; and
• The extension exposes them to the agent.

For my experiment on ricmac.org, a WordPress site, I implemented two simple tools:

1. subscribe_newsletter: Subscribes an email address to updates via my site’s Jetpack email subscription system.
2. find_in_article: Searches the current page for a relevant paragraph and highlights it.

I chose those two use cases because they would show off the ability of WebMCP to take browser actions on my website. This is different to how my Ask Ricmac chatbot works, which is by calling an MCP server running in Cloudflare Workers — in other words, the AI functionality runs in the server and is sent back to my website. But with WebMCP, an agent can interact with the website itself, in the browser, in order to accomplish a task: in this case, subscribing to my site via email and/or searching an open article.

Sidenote: these two use cases are relatively simple examples that allowed me to understand WebMCP from a web publisher perspective. For a deeper developer dive, I recommend RL Nabors’ interview with MCP-B creator Alex Nahas, which gets into the technical weeds more than this post will do.

So, how does MCP-B work? The WebMCP tools are defined directly in the browser using the navigator.modelContext.registerTool() interface. The web page describes the tool’s name, purpose and input schema, and then provides an execution function.

Conceptually it looks like this:

navigator.modelContext.registerTool({
  name: "find_in_article",
  description: "Find the most relevant paragraph in the current article",
  inputSchema: {...},
  execute(args) { ... }
})

When the MCP-B extension is installed, it listens for these tool registrations and exposes them to a connected AI agent.

The interesting part is where the logic runs. Unlike traditional MCP servers — which run in a backend environment — these tools run inside the web page itself. That means they have direct access to the DOM, allowing the AI assistant to interact with the page’s content and interface. Because the tools run inside the page context, an AI assistant can only invoke capabilities that the page itself explicitly registers.

For example, the find_in_article tool I implemented scans paragraph elements in the page, identifies the best match for a query, and then visually highlights the result. From the user’s perspective, the AI assistant can point to a specific part of the article, rather than the user having to scroll down the page and find the relevant section manually.

This architecture effectively turns a normal website into an interactive surface that AI agents can operate on.

However, MCP-B is ultimately a workaround and depends on a browser extension. The long-term goal is to make this capability native to the browser. That’s where WebMCP comes in.

WebMCP in Chrome Canary

Google’s Chrome team has begun experimenting with native browser support for WebMCP, currently available as an early preview in Chrome Canary.

Where MCP-B relies on an extension bridge, WebMCP moves the functionality directly into the browser runtime.

The conceptual model remains the same:

• Web pages register tools; and
• The browser exposes those tools to an AI system.

But in the native implementation, the browser itself becomes the mediator rather than an extension.

From the website developer’s perspective, the code looks almost identical to the MCP-B version. The same navigator.modelContext.registerTool() interface is used to declare capabilities. The difference is what happens after registration.

In the WebMCP model:

1. The page registers its tools;
2. The browser makes those tools available to the assistant running in the browser environment; and
3. The assistant can invoke them directly.

This architecture treats web pages almost like mini MCP servers embedded in the browser environment.

For my ricmac.org prototype, I reused the same two tools — email subscription and article search — and tested them inside Chrome Canary with WebMCP enabled.

The result was effectively the same user experience as MCP-B:

• The AI assistant could ask the page to search for a passage.
• The page highlighted the relevant section.
• The assistant could initiate an email subscription flow.

But the underlying architecture was cleaner. There was no extension bridge and no separate bridge process required. The browser itself handled exposing the page’s tools to the assistant.

Why this matters for the web

These early experiments hint at a larger shift in how websites may evolve in an AI-native web.

Today’s web pages are primarily designed for human readers. AI systems interact with them indirectly — through scraping, APIs, or retrieval pipelines.

WebMCP introduces a different model: sites can explicitly expose capabilities designed for AI agents.

In practice this means a website might publish tools such as:

• search this article
• retrieve structured data from this page
• perform a transaction
• subscribe to updates
• navigate a site’s content

Instead of parsing HTML, the agent calls a well-defined capability. This avoids brittle scraping logic and gives site owners control over what capabilities are exposed.

From a developer perspective, this resembles how the web evolved with JavaScript APIs. Over time, browsers standardized interfaces for things like geolocation, notifications, and storage. WebMCP could become a similar layer for AI interaction.

If that happens, websites won’t just present information, but will also expose agent-accessible functionality.

A small step toward an AI-native web

My implementation on ricmac.org is a small experiment — just two simple tools running in the browser. But it illustrates a key idea: websites can participate directly in the AI ecosystem without requiring complex backend infrastructure.

Using MCP-B, that capability is already possible today through a browser extension bridge. With Chrome Canary’s WebMCP preview, we can also see how the same idea might work when it becomes a native browser feature.

Whether WebMCP becomes a widely adopted standard remains to be seen. But the direction is clear: the boundary between web pages and AI systems is starting to blur. Certainly, this kind of technology will reshape how websites are built in the years ahead.

If you have the MCP-B browser extension installed and/or you have Chrome Canary, do test this WebMCP functionality on my website. I’d love your feedback, so please leave a comment on this post or tag me on Mastodon, Bluesky or LinkedIn.

Photo of canary by Jelle Taman on Unsplash.

The post Implementing WebMCP: letting AI agents interact with my website appeared first on Richard MacManus.

Over the past few months I’ve been exploring what I think of as the agentic web stack — the emerging intersection of artificial intelligence with the open web. As part of that exploration, I built a small experiment for my personal website: an AI chatbot called Ask Ricmac. Its purpose is simple: instead of searching my site manually, a visitor can ask a question and receive an AI-generated answer based on the articles I’ve written over the years.

Under the hood, Ask Ricmac runs on a Cloudflare Workers backend that uses Vectorize, D1 and Workers AI. During development, I also used the WordPress MCP Adapter and Claude Desktop. In this post I’ll explain how these pieces fit together and the role each one plays.

This project is an example of a server-side MCP application, meaning that the AI logic runs on backend infrastructure and the results are delivered to the website. In my next post I’ll explore the other side of this idea: a client-side MCP application running directly in the browser using WebMCP.

The idea: an AI interface to website content

Let’s start with an explanation of my data store. In addition to all the blog posts I’ve published on ricmac.org over the years, I also have copies of all the journalism I’ve written over the past decade and more — basically, all my work since leaving ReadWriteWeb in October 2012. It includes hundreds of tech analysis articles for Newsroom (a New Zealand news operation), Stuff (kind of The New York Times of NZ, despite the terrible name), and The New Stack (which I recently finished up at).

Traditionally, readers would navigate that content using search or category pages. But large language models offer another interface: conversation.

Instead of searching, a reader can ask a question like:

• “What was ReadWriteWeb?”
• “What is the agentic web stack?”
• “What is MCP and where did it come from?”
• “What are the origins of blogging?”

(Feel free to open the Ask Ricmac page now — that link opens a new tab — and ask a question to get a feel for the app.)

The system I built retrieves relevant content from my site and uses an AI model to generate an answer. Technically, this pattern is known as retrieval-augmented generation (RAG). But unlike a typical AI chatbot, like ChatGPT or Claude, the model doesn’t rely only on its training data — it retrieves information from a knowledge base first. And in this case, the knowledge base is my own website content.

The architecture

To build Ask Ricmac, I experimented with several emerging technologies from the agentic web stack. Some of these tools were used during development, while others form the runtime architecture of the application.

I started with the following tools:

• WordPress MCP Adapter
• Claude Desktop

These helped me experiment with AI access to WordPress via MCP servers. But to turn this into a working feature of my website, I used the following runtime technologies:

• Cloudflare Workers
• Cloudflare Vectorize
• Cloudflare D1
• Cloudflare Workers AI

These components together power the deployed Ask Ricmac application.

At a high level, this is the runtime architecture:

I’ll explain each of these components in the rest of the article, but the TL;DR is that this stack enabled me to add an AI interface to my large archive of technology analysis articles.

Before going further, a note about how the system was built. This post isn’t a tutorial, because I used ChatGPT as my coding partner while developing the app. I wouldn’t call it “vibe coding,” because I always pay close attention to the code in order to understand how it works. But the reality is that AI produced much of the code while I orchestrated the process. So my goal here is to explain the architecture and thinking behind the system, rather than provide step-by-step instructions.

WordPress MCP Adapter: exposing the site to AI

During development, one of the first challenges was figuring out how an AI system could access the content of my site.

My personal website runs on WordPress, so during development I used the WordPress MCP Adapter to expose the content as tools that an AI agent can call.

MCP stands for Model Context Protocol, an emerging standard for connecting AI systems to external tools and data sources. Instead of hard-coding integrations, MCP lets developers define capabilities — such as “search posts” or “retrieve page content” — that an AI system can invoke when needed.

So the WordPress adapter turns WordPress into an AI-accessible data source.

For example, it can provide tools like:

• searching posts
• retrieving post content
• listing recent articles

Essentially, this creates a bridge between a traditional CMS and modern AI agents.

Claude Desktop: the development environment

To experiment with these MCP tools during development, I used Claude Desktop.

Claude Desktop acts as a kind of AI development environment. It allowed me to create and manage a couple of MCP servers, so that I could interact with the tools the WordPress adapter exposed. I first created an MCP server for a local version of my WordPress setup (run via MAMP), so that I could test everything on a site that wasn’t online. Then once I was sure it was working as expected, I created an MCP server for the production version of ricmac.org.

Once connected, Claude can decide when to call the WordPress tools in order to answer a question.

For example, if I ask:

“What is Cybercultural?”

Claude can choose to call a tool that retrieves the relevant page(s) from my site before generating a response. This interaction between the model and external tools is one of the key ideas behind the emerging agentic web — AI systems that can reason about when to access external resources.

Claude Desktop was very useful for testing this behaviour while I was developing Ask Ricmac. In the next post in this series, I’ll explore how this same idea — AI systems interacting with web pages through tools — can move directly into the browser using WebMCP.

Cloudflare Workers: the serverless backend

Once I had experimented with AI access to my WordPress content, the next step was building the application itself. The deployed Ask Ricmac system runs on Cloudflare Workers.

Workers are Cloudflare’s serverless runtime that executes code at the network edge. Instead of running a traditional server, developers deploy small scripts that respond to requests.

In the Ask Ricmac project, the Worker acts as the backend orchestrator. It performs tasks such as:

• receiving a user question
• retrieving relevant documents from a vector database
• sending the context to an AI model
• returning the generated answer

Running this logic on Workers keeps the architecture simple and scalable.

Vectorize: storing semantic embeddings

To make retrieval work, the system needs a way to find relevant pieces of content based on meaning rather than keywords. This is where Cloudflare Vectorize comes in.

Vectorize is a vector database designed for AI applications. It stores embeddings, which are numerical representations of text generated by an AI model.

Each article from my website was converted into embeddings and stored in the database. This part of the development process actually took the longest for me. I used curl from the Mac Terminal to upload the data in chunks to the vector database; after a bit of trial and error, I discovered I could only get it to “ingest” 3 posts at a time. So it took a while to complete this process.

How does this work at a user level?

When a user asks a question, the system converts that question into an embedding. The database can then perform a similarity search to find the most relevant content. The idea is that this process allows the system to retrieve passages that are semantically related to the user’s question, even if the exact words don’t match.

Vector databases have become a foundational component of modern AI applications, especially those built around retrieval-augmented generation (RAG).

D1: storing structured data

Alongside the vector database, I used Cloudflare D1, which is a lightweight SQL database.

While Vectorize handles semantic search, D1 stores structured data about the content itself — such as metadata, IDs, and references to the original articles.

Together they provide both semantic search and traditional data storage. This combination is common in AI applications that integrate with existing content systems.

Workers AI: generating the answer

Once the system has retrieved relevant passages, it needs a model to generate the final response. For this, I used Cloudflare Workers AI, which provides access to a range of open-weight AI models directly inside the Workers runtime.

The Worker sends the retrieved content and the user’s question to the model, which then generates an answer grounded in that material.

Because the model is running through Workers AI, the entire process stays inside the Cloudflare environment. That simplifies deployment and keeps latency low.

A small step into the agentic web era

In summary then, Ask Ricmac works like this: a user question is sent to a Cloudflare Worker, relevant content is retrieved from a vector database, and an AI model generates a response grounded in my published articles.

For many years, the web has been about publishing content for human readers. But increasingly, it will also be about exposing content and capabilities to AI systems. Now, with that said, I still think the primary purpose of a website is to serve content to fellow humans. But the fact is, AI is rapidly becoming a default interface to the web; and I believe it’s up to website publishers to adapt to that reality.

This experiment is only the beginning. If you’d like to follow my journey to become an agentic web expert, subscribe to ricmac.org via RSS or email.

Feature image via Unsplash.

The post Building Ask Ricmac: my first experiment in the agentic web stack appeared first on Richard MacManus.

As AI agents begin interacting directly with websites and services, a new “agentic web stack” is emerging. In this article, I map the technologies shaping this next phase of the web.

Let’s first look at how we got here. I was the first writer at The New Stack to regularly report on what’s now called “AI engineering.” I reported from an AI conference in London in 2022, before ChatGPT was even launched. Then I attended the first AI Engineer Summit in San Francisco in 2023, in the first flush of the AI hype wave initiated by ChatGPT. But it wasn’t until 2025 — not coincidentally, the year that agents became a huge trend — that I began to see a really interesting web angle to the AI development trend.

I realized then that AI models could, and should, be symbiotic with websites and web applications. Yes, there are fundamental issues with AI — the fact that it takes content from people like me for free, without any compensation, and the environmental concerns about AI data centers. But it’s also undeniably a technology that can augment websites and web applications; and so I think web publishers and operators should lean into that.

This realization spurred me to research and do interviews with the people who were creating new products, protocols and standards at the intersection of AI and the Web; including from leading tech companies like Google, Microsoft, Vercel and Shopify.

One of the terms being bandied about for this activity was “agentic web.” I first became aware of the term from Microsoft, which used it to describe MCP and NLWeb (the latter was created by Microsoft) in May 2025. The W3C appears to have adopted agentic web too. It has a working group, called AI Agent Protocol Community Group, that aims to “establish the technical foundations for the emerging Agentic Web.”

I quickly became fascinated with all the latest agentic web technologies, such as WebMCP, MCP Apps, MCP-UI, OpenAI’s Apps SDK, Google’s A2UI, and more. You’ll notice that MCP — the Model Context Protocol — is part of the name for some of these new technologies. That’s because MCP is a key connective protocol between AI agents and the Web. It allows agents to access web content, tools and services in a structured way.

I’ve also become extremely interested in on-device AI, using web browser technologies like LiteRT.js (a JavaScript runtime for running AI models in the browser using WebGPU) and Chrome’s built-in AI APIs, which provide access to on-device models like Gemini Nano.

Over the coming months, I’ll be testing and developing with all these different agentic web technologies. That will allow me to ascertain the strengths and weaknesses of each component, and their use cases.

The agentic web stack

For now, I’ve taken a stab at a high-level overview of the agentic web stack. But this is a work-in-progress, so leave a comment on this post or tag me on Mastodon, Bluesky or LinkedIn if you have ideas to improve it. (Note: I did ask ChatGPT to help me refine this.)

APPLICATION LAYER

• User interfaces
  • Web browsers
  • Browser extensions
  • Chatbots
  • AI-powered web apps
• Application frameworks
  • OpenAI Apps SDK
  • Google A2UI
  • MCP-UI
  • MCP Apps

AGENT LAYER

• Agent frameworks
  • OpenAI AgentKit and Agents SDK
  • Anthropic Claude Agent SDK
  • Google Agent Development Kit (ADK)
  • LangChain
• Agent builders / platforms
  • Google Vertex AI Agent Builder
• Custom agents
  • Cloudflare Workers agents
  • Node.js / Python agents

TOOL & PROTOCOL LAYER

• Core protocols
  • Model Context Protocol (MCP)
  • WebMCP
  • NLWeb
  • Agent2Agent (A2A)
• Tool access mechanisms
  • MCP adapters (e.g. WordPress MCP adapter)

AI RUNTIME LAYER

• Cloud inference (e.g. Cloudflare Workers AI)
• On-device inference runtimes (e.g. LiteRT.js)
• Browser AI runtimes (e.g. Chrome built-in AI APIs)

KNOWLEDGE LAYER

• CMS (WordPress, Drupal)
• Vector DB (e.g. Vectorize)
• Databases (e.g. D1, PostgreSQL)

MODEL LAYER

• GPT
• Claude
• Gemini
• Gemini Nano
• Llama

Web relevance for each layer

The application layer is where a lot of the innovation has happened over the past year in the agentic web. It was MCP-UI that first caught my attention last year, because it brought web technology into chatbots — in the form of sandboxed iframes. MCP-UI eventually turned into MCP Apps, which is carrying that work forward. OpenAI, Google, Anthropic and others are all working hard to define this layer.

The agent layer is, of course, the most hyped layer currently. Since it’s not inherently tied to the Web, I won’t focus on it as much as some of the other layers. At least initially.

The tools and protocol layer is where a lot of the most interesting action is happening in agentic web right now. Underpinning a lot of it is the Model Context Protocol (MCP), which I noted above is a critical protocol. But for the Web specifically, I think WebMCP holds the most promise — it basically allows websites to expose their capabilities and content in a structured form that agents can discover and use. So it gives a lot of power back to web publishers and operators, which is a welcome development.

The AI runtime layer is where a lot of deep technical work is happening to make the web platform a first-class citizen of AI inference.

The knowledge layer is mature from a web perspective, but AI-native integrations into CMS platforms are still emerging. However, I have been closely tracking the progress of the two most prominent open source CMSs: WordPress and Drupal.

My final post for TNS ended up being about Drupal CMS 2.0, which I described as “a return to the simpler Drupal CMS product of yore and a response to the current trend of vibe coding.” It’s basically a less complex Drupal that includes AI functionality, such as Drupal Canvas to help build user interfaces.

WordPress has also jumped on the AI bandwagon with the release earlier this month of WordPress MCP Adapter, which “implements the Model Context Protocol in the scope of a WordPress site and lets AI tools (like Claude Desktop, Claude Code, Cursor, and VS Code) discover and call WordPress Abilities directly.” I’ll go into this in detail in my next post, as I used the MCP Adapter to integrate Ask Ricmac into this website (ricmac.org is a WordPress site).

In the meantime, let me know in the comments or on social media if you have any feedback on this post about the agentic web stack!

The post The agentic web stack: a map of emerging AI-web technologies appeared first on Richard MacManus.