Recently, Vercel came to London and teamed up with Anthropic’s local chapter to host a skills event. (I am pretty sure the event was held, in Vercel fashion, at the same venue where I saw my last Ladytron concert before the Pandemic kicked off.) I also attended an AI Tinkerers event where my former director at Meta, who is now Chief Product Officer at Vercel, Tom Occhino, gave a fireside chat.

Vercel is repositioning itself as the “AI Cloud/Agent Platform” provider. It’s an interesting pivot from a company that sells hosted infrastructure for websites, essentially admitting the web-as-destination era is winding down. Their response is to build the infrastructure that allows you to deploy “agents” the same way you’d deploy a Next.js app, with easy routing between inference providers, a global API gateway, an open-source framework, and serverless compute retooled for agentic workloads. (Given that the frontier models live in Microsoft, Google, and Anthropic’s clouds, and the model hosting space is already well-established by incumbents like Hugging Face, “AI Cloud” might be a branding overstatement.)

While bespoke agents are taking off internally at companies, the question is, will consumers use the agents that agent builders deploy to the same extent they visit sites or download apps? The outlook for cloud-hosted agents reaching everyday consumers is complicated by a few structural realities. When people want a personal agent today, they reach for a frontier product like ChatGPT, Gemini, or Claude rather than a bespoke agent. And even that may be a transitional moment: Google and Apple are quietly building the on-device inference story that would let agents run locally, on the consumer’s local, personal data, without routing through anyone’s cloud. Vercel’s bet requires the cloud-hosted model to win consumer adoption before on-device inference makes it redundant. That’s a race against two of the best-capitalised companies in history, who also happen to own the devices!

The AI browser that never grew up

The last time I posted here, OpenAI had just launched Atlas, their AI browser. And I never did install it. I switched back to the decidedly non-agentic UK Chrome because I worried that OpenAI’s splashy release had put a prompt-injection target on the back of every AI browser user. (I still fire up Perplexity’s Comet when I’m researching things because it’s incredibly handy.)

Perhaps the AI Browser War went out with a whimper because consumers were concerned about prompt injection, but such risks haven’t thwarted OpenClaw enthusiasts, despite that agent’s notorious security risks (as of this writing, it already has more GitHub stars than React). It’s clear that security isn’t the adoption blocker; it's utility.

It’s 100% true that AI is changing browsing habits, but it’s not happening through agentic browser features. Rather, the change is coming from AI deployed on sites, such as Google’s AI summaries, which are replacing visits to sites. And from people using personal Agents like Claude and Gemini to get things done rather than opening hundreds of tabs.

Where data and inference live together

Providers who see the web in decline would naturally seek to repurpose their infrastructure to host agents orchestrated through their pipes that you access via apps (your apps, web apps, someone else’s apps—I wrote up an intro to all these different agents with the people at web.dev).

But for legal, privacy, and performance reasons, inference and data are both best collocated. You can see signs that Big Tech is moving in this direction:

• Apple has integrated MCP into XCode and is adopting Gemini.

• Most flagship Android phones ship with an SLM.

• Both Apple and Google have designed chips specifically for running models on the device.

Intelligence needs to live where the data lives, and for consumers, that’s usually on their device or buried in a platform (try building an agent that can talk between X and LinkedIn. I have. And no, scraping isn’t allowed.).

If you don’t have a device story, you have an app story that uses frontier inference controlled by Big Tech that can afford the data centers, or you have an app story that uses inference already on the device. Web infra and hosting providers are hoping for the former so they can at least sell the wiring. The latter would reduce the web to a collection of hosted markdown files and APIs (although I think that would come as a relief to some providers).

Apps don’t want your agent to access your data

In November 2025, Amazon sued Perplexity for users placing orders online via Comet. Amazon claimed that Perplexity was “damaging the user experience,” but having used Amazon for many years, I find it hard to imagine Comet making that experience worse. (Disclaimer: I’ve also worked at Amazon, albeit at AWS and not on the shopping card team.) What I think is actually happening is that Amazon wants to set a precedent that will give it a defense when Google or Apple release features that do the same. Amazon doesn’t want to be reduced to an API layer. That would cut into their secondary ads market!

All these companies, from LinkedIn to Facebook, do not want to give users access to their surfaces. Those people have to visit the site or download the app, log their usage data into the company data warehouse, see the ads, the upsells, etc. It’s hugely profitable to control the environment a user inhabits, even if for just minutes, because everything from the sale to the very data that the user logged by visiting turns a profit. So expect vertical platforms to fight furiously against the Agentic Web.

WebMCP: the future of the (Intra)net?

I recently interviewed Alex Nahas, the Amazon employee who invented WebMCP to solve an intranet authorization problem. Amazon had built an internal MCP server aggregating thousands of tools. OAuth 2.1, the auth story MCP had settled on, wasn’t implemented anywhere internally. But the browser already had everything needed: session cookies, SSO, and scoped identity. Rather than reinvent the wheel, Alex ran MCP inside the browser, used the existing session, and wrote a custom transport over postMessage. The browser as a pseudo-identity provider solved what MCP working groups were still figuring out.

WebMCP isn’t actually MCP. It’s “MCP inspired” (just the tools). It surfaces the same JS functions your UI calls (think search(term) and addToCart(item, options)) to agents as they visit the site. This is an accessibility boon that will, sadly, likely never take off with vertical web platforms like Amazon, Facebook, and Salesforce for the reasons previously stated.

But it will likely have an audience among people building internal tooling (like Alex) and incumbents embracing the agentic web. I would not be surprised to see Shopify and Etsy, who partnered with OpenAI on the Agentic Commerce Protocol, implementing this to do just that.

The web isn’t going anywhere. It’s becoming infrastructure, the COBOL of human networking. Vertical platforms will fight the agentic web because their business models depend on controlling the surfaces users inhabit. Cloud providers will pitch themselves as the neutral pipes. But the real leaps are coming from engineers solving real problems around the edges with existing tools, from competitors wrapping their existing code in agent-readable interfaces to gain an edge, and from devices getting smarter with each generation. The agentic web won’t be announced. It’ll arrive one step at a time.

Robin’s story exposed three broken systems:

• Permissive opensource licensing that lets companies extract infinite value while giving nothing back

• AI-driven hiring that screens out the very people you're trying to hire

• The general state of tech hiring in 2025 (spoilers: it’s not fun unless you’re an experienced ML engineer Meta has been clamboring to hire for Reasons)

But I wanted to dig deeper into the technical story behind the outrage. Input simulation is the linchpin for connecting AI to external systems, but what is it, and how did a German master's student end up maintaining critical infrastructure for the AI industry? Robin generously hopped on a call to explain.

Input Simulation is hard, actually

When JavaScript programmers think about simulating mouse clicks and keystrokes, we imagine it's as easy as sending a click event. Robin quickly corrected this assumption.

"It's surprisingly difficult to even do that simple thing," he told me. "The complexity arises mostly because of the different platforms that are supported. Everyone has their own ideas how to do that."

Enigo supports Windows, macOS, BSD, and Linux across multiple protocols (Wayland, X11, and libei). That's not just "write once, run everywhere"—each platform has different APIs, different security models, different ways of handling input events. Linux alone requires supporting multiple display server protocols as the ecosystem transitions from X11 to Wayland.

"Some compositors don't support all the protocols," Robin explained. "The goal of enigo is to just use the library, and the developer doesn't have to care what the compositor understands, which versions, and all that."

Even keyboard support requires manual labor. "For Linux, at least, I have to add [keys] manually. Recently, [F13 to F24 keys] were added, which existed on Windows, but on Linux, they didn't exist." (Correction: turns out enigo probably supported these already.)

My mind boggled trying to imagine that setup. Keyboards with 24 function keys? Robin laughed. "Most of them are simulated, but apparently, there were some old keyboards with two rows of function keys at the top." And apparently, there are some modern ones as well!

This kind of unglamorous infrastructure work makes "magical" AI features possible. Claude's computer control isn't breakthrough AI research. It's careful engineering on top of enigo’s cross-platform input abstraction.

The accidental infrastructure maintainer

Robin’s path to maintaining critical AI infrastructure started with a simple, unrelated goal to build a better smartphone keyboard for Linux.

"It all started with my master's thesis," he said. "I wanted to use the PinePhone, which is a Linux smartphone, and I got so used to swipe typing and next word prediction that I thought I would really miss it because it wasn't available for Linux at the time. That was 2020."

He planned to write a virtual keyboard with advanced features for Wayland. But first, he needed the basics: input simulation. That's when he discovered enigo, created by Dustin Bensing but abandoned with pending merge requests.

"I just asked him if he needed help maintaining it, and he was happy about it, gave me permissions on GitHub. He just completely trusted me, and that's how I started."

What Robin thought would be a quick detour became his primary focus. His keyboard project is still on the back burner because enigo keeps demanding more attention. "I naively thought it wouldn't change much, but I just have to continue to invest time into it."

In the opensource era, it is common for critical infrastructure to depend completely on one person's side project. One person’s hobby can become everyone's dependency. Robin now maintains a library with more than 300,000 downloads that powers everything from AI agents to accessibility tools to remote desktop software.

What Input Simulation enables

Most people's mental model of input simulation stops at gaming bots and auto-clickers. But Robin has seen many more interesting applications:

AI computer control: "Recently [enigo] was very popular with people writing AI agents such as Anthropic. You basically send screenshots to the server, the server analyzes it, and then tells the client where to move the mouse and click and type stuff."

Remote desktop software: RustDesk, a TeamViewer alternative, uses enigo to relay mouse and keyboard input between computers.

Input methods for underserved languages: The Afrim project uses enigo to handle African languages that can't fit on standard keyboards—users type phonetically and the input method converts to the correct characters.

Accessibility tools: Voice-controlled computers for people who can't use traditional input methods.

All these applications need to bridge the gap between different modalities—voice to keyboard, network to local input, and one language system to another.

Input simulation and bot detection

I was curious whether systems can distinguish between simulated input and human input.

"It depends," Robin said. "On X11, with the protocol I'm using, the compositor can tell, but most compositors don't mind. On macOS, I think if you wanted to as the OS, you can always tell that it's a simulated input."

For many websites, bot detection prevents scraping, DDOS attacks, and other unwanted automated activities (think of scalpers who buy up all the concert tickets as soon as they’re released so they can resell them at a markup, or shady organizations using bots to leave flood political articles with comments designed to sway public opinion). Bot detection is an arms race between site owners and bot operators. "You could analyze the [mouse] path, or you can tell if you simulate text that no human can physically type that quickly."

Developers can counter by adding delays, fuzzing mouse trajectories, or using more human-like timing patterns and inputs. However, the ultimate countermeasure, short of paying actual humans to perform actions, is input simulation, where key presses are simulated at the system level.

Of course, in the case of personal AI agents operating on our computers to perform tasks on our behalf, this is perfectly acceptable to the user and difficult for the property operator to detect. This makes distinguishing between bots, agents, and humans incredibly difficult, and it is one of the biggest open-ended questions facing the Agentic Web (which I’ll get into in a future post).

The academic hacker's perspective

While maintaining infrastructure for billion-dollar companies, Robin is pursuing a second master's degree in IT security at TU Darmstadt. "We have very cool classes where you don't just theoretically learn about it, but you do projects. I did a reverse engineering lab last semester and reverse-engineered the authentication method of the app to log into your tax revenue service in Germany."

He also hacked his bike: "It's just a replay attack on the electronic shifters. They send wireless signals to the rear derailleurs. But I had to downgrade the firmware and man-in-the-middle some requests of the app."

Robin's academic approach provides him with a unique perspective on the industry's chaos surrounding AI hiring and opensource extraction. "I love studying. I would like to do that for the rest of my life. But then every now and then, I also want to build things more long-term."

Robin didn't set out to solve input simulation for the entire Rust ecosystem or to “fill in his green squares” on GitHub to attract a FAANG employer. He just needed functionality for one project, found an abandoned library, and started fixing bugs.

The happy ending (sort of)

It’s been a few weeks since the Hacker News uproar, and Robin's viral blog post has since created some unexpected opportunities. Multiple CTOs from AI companies reached out, and Robin also got offers for Rust consulting work.

"I didn't expect it to be that popular, but it was an interesting experience," he reflected.

Robin did get in touch with real humans at Anthropic, but nothing came of it. And the deeper issues remain. Anthropic is using Robin's code in production, deployed to thousands of devices, generating revenue for a company valued at $60+ billion. His compensation? Stars on GitHub and download counts on crates.io—what he calls "the nerd equivalent of street creds."

enigo’s MIT license maximizes compatibility but also leaves room for exploitation. Had Dustin Bensing used AGPL, Anthropic might have been forced to contribute back or pay for a commercial license. Perhaps licensing is something we should consider more when taking over maintainership of a repository.

What this means for AI

Robin's story illustrates a fundamental tension in how AI capabilities get built. The most impressive demos often rely on surprisingly mundane infrastructure—cross-platform input simulation, screen capture APIs, text parsing libraries. This infrastructure is typically maintained by individuals or small teams, often as hobby projects.

As AI agents become more capable, they'll need more of this "boring" infrastructure. Libraries for controlling browsers, parsing documents, interfacing with APIs, handling authentication. The companies building billion-dollar AI systems will increasingly depend on the Robin Grells of the world.

The current norm is that companies extract infinite value from permissively licensed code while giving nothing back. This works fine when the stakes are low. But as this infrastructure becomes critical to AI capabilities, the sustainability questions become urgent.

What happens when the maintainer of a critical library burns out? When they get hit by a bus? When they decide their time is worth more than GitHub stars?

We’ll find out soon enough.

The Real Magic Trick

Claude's computer control isn't some breakthrough in artificial intelligence. It's carefully engineered, built on top of opensource libraries maintained by graduate students from wealthy nations.

This is actually good news. It means these capabilities are more accessible and reproducible than they appear. If you want to build AI computer control, you don't need to reverse-engineer Anthropic's research. You can use the same libraries they do.

The magic isn't in the AI model. The magic is in developers like Robin who solve the unglamorous but essential problems that make everything else possible. Every time Claude moves your mouse cursor, it's Robin and Dustin's hard work making it happen.

Anthropic might be getting the credit, but the arms and legs belong to opensource.

The original interview was much longer—we covered everything from German tax software security to electronic bike shifter vulnerabilities. You can catch it on YouTube.

Robin continues to maintain enigo at github.com/enigo-rs/enigo. If you're building something with input simulation, consider contributing back to make the project more sustainable. And if you're hiring for AI infrastructure roles, consider screening applications from maintainers of libraries you're using in production into a human-monitored process.

You can read Robin's original blog post at grell.dev.

I'll be speaking at the O'Reilly AI Codecon: Coding for the Agentic World on September 9 at 11:00 AM ET. Join us for an intensive exploration of the tools, workflows, and architectures defining this next era of programming. Sign up now to save your spot—for free!

District Judge Amit Mehta ruled that Google won’t have to sell Chrome (or Android!) but won’t be able to enter into or hold exclusive deals for Chrome, Gemini, Google Search, and has to share search data with rivals. There was an uptick in share prices as investors took the ruling as a positive sign, but I think the long-term impacts of having to pay for placement like everyone else mean the era of Google’s monopoly is coming to a close. If Elon Musk wanted Apple to use Grok to power Safari's search, little would stop him from outbidding Alphabet. It’s a ruling that appears favorable to Google but is actually quite damning.

Now that it’s clear Google won’t have to part with Chrome, we could see one or more things happen next:

1. Google could start pouring resources into reimagining Chrome as an AI browser, similar to Comet or Dia.

2. Google could release an “alternative experience” to the browser, perhaps a Gemini-powered personal agent that runs on top of the Internet.

3. Google could continue bumbling along with Chrome.

The latter could be possible if the company is distracted by Gemini and its other AI offerings and competition. Alphabet is a nimble startup no longer. It takes time to rally resources. Unless people have been working on an AI-fueled Chrome in silence like Microsoft did when it switched Edge from EdgeHTML to Chromium, it will take time to re-rally around the web. A clever company would have done 1 and 2 in absolute silence, waiting for this ruling. After all, no one wants to influence a judge at work—or put a lot of effort into a product they might have to hand over to a competitor.

I’m curious to see what happens next. Could there be something exciting around the corner, or have AI-friendly browsers like Opera gotten a head start?

On the road again!

I’m leaving London for a bit of travel in September to share some tea and give some talks about how AI is changing the web.

• Sep 8-13 | Bay Area If you or someone you know wants to nerd out over agents and the web, hit me up!

• Sep 9 | online O'Reilly AI Codecon: Coding for the Agentic World

• Sep 16 | online Unintelligence Conf

• Sep 18-19 | Seattle CascadiaJS Google’s Jason Mayes (who claims to have invented the term “Web AI”) and Jack Herrington (who does great videos about MCP) will be speaking as well. Use STACKED to get $50 off a ticket.

Coming up: On Monday I’ve got a special interview with the maintainer behind Claude’s computer use capabilities. Stay tuned!

Perplexity is making a big bet on browsers. Founder Aravind Srinivas said, “The browser is bigger than chat. It’s a more sticky product, and it’s the only way to build agents. It’s the only way to build end-to-end ‘workflows’.” The agent-in-browser approach, as Srinivas argues in this post by Nadeem Sawar, is more familiar and flexible than the chatbot UX favored by ChatGPT and Claude. To be honest, I agree. However, that’s not what the flagship batch of AI Browsers are offering.

AI Browser feature sets

I’ve been investigating AI browsers for the past two months, having spent 3 weeks with Dia from The Browser Company (the same company that built Arc) and now taking Perplexity’s browser, Comet, out for a spin. Dia and Comet are essentially browsers with chatboxes strapped to their sides that let you query a page, search for more resources, or perform tasks on the page.

Comet’s assistant is like ChatGPT’s Agent and Google’s Project Mariner—just in the browser. It can navigate around a page for you, but it still gets stuck in places that a human might not, and it has to wade through UI when an API call might have been more efficient. I’m still using my MCP servers in Claude for I/O-heavy apps like Notion.

What makes Comet stand out is Perplexity’s algorithm. It is the leader when it comes to discernment (choosing which URLs are most relevant to a query) and formulating thoughtful responses using the latest information gleaned from the web (which is problematic in its own right, but I’m saving that for a future issue).

The shared “killer feature” between these two browsers is the ability to save prompts you want to reuse with different web pages as “skills” in Dia or “shortcuts” in Comet. I even did a tutorial on how to port them from one to the other.

Will AI Browser prompts replace extensions?

Nadeem argued that skills/shortcuts will replace extensions. Average users indeed have no way to identify when a browser extension might be harvesting their data or stealing revenue from affiliate programs (see also PayPal’s Honey scandal). I’ve also been able to recreate several utilities with a short prompt that I usually use an extension for, such as cleaning up copy. Heck, Dia has a skill for looking up coupon codes, no theft from creators required!

But the prompt library interfaces of both Comet and Dia are rough around the edges—I wasn’t able to find out how to edit saved prompts in Comet, and Dia’s UI isn’t as polished. In the end, the feature could be easily copied by a lead browser with an LLM to sell and hungry PMs looking to ship a feature in time for bonus season (looking at you, Edge).

Is Chrome going to get bought?

Rumor has it that Perplexity's bid is likely a publicity stunt (I mean, I'm writing about it, aren't I?) Although Perplexity’s funders say they’ll pay up for the deal if it goes through, it would be likely that Google would not go quietly into that dark night. Chrome is often the first app people install on a new device, an OS inside your OS, and the Omnibox (used for typing URLs and search terms) is crucial real estate for Google, which is already losing search traffic to the likes of Perplexity. Losing control of Chrome would be Very Bad for the company.

And perhaps that’s why we haven’t seen Chrome launching any prompt libraries or Assistants of its own. Why invest in something you might have to turn around and give to your competition?

Perhaps Google is holding its breath and waiting for this to pass. Meanwhile, AI Browsers keep evolving…

Psst! Are you into AI Browsers as much as I am? I made a YouTube channel just for my livestream recordings where I experiment with AI Browsers. Check it out, and feel free to drop me a line or comment with how you’re using them!

The signs are there. A few years back, Google cut funding to longstanding community contractors working on standards with the W3C. Community members I spoke with at CSS Day 2023 in Amsterdam found the move confusing, given that Google had supported this vital work for so many years. And maybe it was important—to the Web. But what Google was saying with its actions was, “This work is not important for Google right now.”

And with good reason. For the first time ever, Google searches are dropping. And despite rhetoric that “users won’t pay to use the Web” they are paying to use AI services competing with the Web like Perplexity. This happened once before when mobile apps hit the scene, and Google rose to defend the Web (and its advertising income) by launching Chrome, AMP, and a host of other initiatives to keep the web competitive with walled garden app stores.

But this time is different. AI just broke the Web that Google built.

Chrome’s IE6 era

While Google’s Chrome Platform team has been shipping new standards for web developers, Chrome, the browser itself, hasn’t made any significant improvements to its user experience in years. (By comparison, Firefox has shipped more UI updates in the same 5 years, including ones like sidebar navigation for tabs.) Perhaps Google sees no need to “fix” what is already working for ~70% of the Internet.

A similar situation occurred with Microsoft’s Internet Explorer 6 (IE6). After finally achieving a 90% browser market share, Microsoft lost interest and diverted its resources to sell more Windows and Office licenses.

The next largest browser is Safari, with around 15% of the browser market share, thanks to its iron grip on iOS. If you see Google/lobbyists pushing for Apple to allow other browser engines onto its devices in courts, it is likely more about gobbling up that high-value slice of market share than giving users the power of choice. Chrome is, and always has been, a vehicle for ad revenue and data collection for Google’s money-making duo: Search and Ads. In protecting these interests, Google has gone so far as to backpedal on deprecating third-party cookies, which underpin data collection and ad targeting.

Although Chrome receives the bulk of browser use, and thus Google has little motivation to innovate and compete, the writing on the wall is that Chrome’s days are numbered. User behavior suggests people are finding LLMs more convenient for finding answers than Googling, where they must leap over hurdles of ads, dive several pages into the search results, and then pogo in and out of websites to find answers to some of their most banal questions. And Google knows this. On May 7th, Eddy Cue, Apple’s senior VP of services, shared that searches on Safari dipped for the first time last month, which he attributed to people using AI like Perplexity. Google I/O touted a vision of an Agentic and AI-driven future brought to you by Gemini.

Google is shifting its attention

We can watch externally and see how Alphabet is reorganizing Google to accommodate this upcoming modality. We can see them testing AI-driven search results in Google. They reorganized their devices and Chrome teams a few weeks back, cutting industry-favorite Chrome team members. What do these actions say?

Google is saying, “I’m not interested in continuing to pour the same resources into Chrome anymore. I’m not interested in stewarding the Web as we know it.”

Consider also that the FTC is currently deciding if Google and Chrome should be split up (which could see Chrome bought by Perplexity or even Yahoo). Google executives would have to be blind not to see where the ball is going, that ChatGPT and its ilk threaten its core business model of serving ads to people searching for answers. This may explain why, at Google I/O this year, new AI features were shipping at the OS level, not the browser level. You could interpret all of this as Google pulling back resources from a product that is about to be outmoded, sold off, or, at the very least, doesn’t require further innovation to remain the top browser.

The Web’s post-ads era

If you build websites, you might be offended—“How dare Google stop investing in the free and open web?”

My friend, Google was always investing in keeping the Web competitive with apps so its ad revenue wouldn’t decline, to the point where it has been creating a “shadow Internet” in the form of AMP. It has never been altruistic, though it has wisely employed altruists.* And arguably, there’s nothing inherently “evil” about supporting an ecosystem of content with ads. The downside, however, is that the APIs, protocols, and standards Google fostered grew the Web only in one direction: ad-based revenue. The Agentic Web is poised to disrupt the ads-supported ecosystem because LLMs can deliver facts directly, and AI Agents can pierce through ads and data-collecting tech to harvest content on behalf of users, no human eyes required.

The question Google—and you—should be asking is, “How do we adapt to a world where people have a magical answer box embedded in their machine and don’t need to visit websites much anymore?”

This series of posts seeks to address the new challenges facing the Web, its users, and its creators with the introduction of “magical answer boxes,” generated content, and agentic systems. I shall endeavor to share neither optimistic nor pessimistic views but only to drive at the truth of what is happening and what we can do to bring about a thriving ecosystem of creators and consumers. I seek to address the following:

• Money Economic models, payments, and protocols for a post-ads economy

• Identity How we distinguish between ourselves, each other, and our “extended selves,” both personally and programatically.

• Reach Optimization for reaching audiences using agents and LLMs

• Security Methods to defend servers and information from unwanted agents and bots

• Evolution: The creation of new browsers and “browser alternatives”

The Web is always a work in progress, and now it is changing more rapidly than ever before. Let’s navigate this shift together.

—RL Nabors

Homework/further reading

• From Penny Press to Protocols: The Structural Shift AI Forces on the Internet picks up where Stratechery left off, drawing parallels with the telegraph’s disruption of the Penny Press and proposing new protocols for content consumption.

• Everything Is Chrome is a deep dive into Chrome’s history, positing that Google has been trying to control the Web through Chrome’s marketplace power.

Originally posted as a thread on BlueSky, enough people asked for a link to the article version that it seemed like the perfect launch post for this promised series. Thank you to everyone who pre-signed up for this first missive and for encouraging me to share my thoughts and findings on how AI is reshaping our relationship with the Web and each other.

Special thanks to the following folks for their proofreading and feedback: Jack Herrington, Paul Asjes, Vale, Bob Monsour.

About the author

I’ve had the privilege of contributing to projects at Microsoft Edge, Meta’s React team, and AWS Amplify, in addition to working with startups focused on AI, auth, and design systems. As an Invited Expert at the W3C, I helped shape the Web Animation Standard and collaborated with Mozilla on development tools and documentation initiatives. Through these experiences, I’ve learned that while I may have been doing this work for quite some time, the real magic happens in the community. I believe deeply that we—developers, creators, and users—are the true architects of the Web. While standards bodies and large companies influence its direction, the Web ultimately belongs to all of us. Every small contribution we make helps pave the way forward.

The opinions I share in these posts are my own and do not reflect those of my clients or employers, past or present. They reflect only publicly available information.

Subscribe now