Output / Research Journal
After the web - the mesh: WAP, MCP and agentic architecture
Note 3 from the research journal by Nicklas Lundblad: thoughts and questions on agents, agency and institutions
Note 3
The Wireless Application Protocol, or WAP, was created in the late 1990s to bring something like the Internet to mobile phones. At that time, phones had tiny monochrome screens, no touch input, and connected through slow, unreliable networks. The web itself was designed for desktop computers with browsers that could interpret HTML, images, and multimedia—far beyond what a phone could handle. To solve this, a group of major telecom companies—Nokia, Ericsson, Motorola, and others—founded the WAP Forum in 1997 (the site wapforum.org now forwards the user to a new standard site). Their idea was to design a lightweight version of the web, using its own markup language (WML, Wireless Markup Language) and its own transport system (WSP instead of HTTP), so that mobile devices could request and display information efficiently. The dream was that anyone, anywhere, could access the Internet from a phone.
In practice, WAP quickly ran into trouble. Connections were slow, pages were stripped of graphics and color, and each request cost time and money. The experience felt nothing like the real Internet—it was more like a text-based directory of simplified pages. Developers disliked having to create separate WML sites, and users found the service clumsy and expensive. By the mid-2000s, mobile devices had become powerful enough to handle regular HTML, and mobile data networks had improved dramatically. When the iPhone launched in 2007 with a full web browser, WAP instantly became obsolete. Within a few years, it disappeared from most phones, remembered mainly as a bold but short-lived attempt to adapt the web to a world that wasn't yet ready for it.
The Model Context Protocol (MCP) was introduced by Anthropic in 2024 as a way to let artificial intelligence agents interact with the digital world built for humans. Most existing software—APIs, databases, web apps—was designed for developers or end-users, not for autonomous models that reason, plan, and act. MCP provided a bridge: a standardized way for agents to “plug into” these systems, discover what tools they offered, and call them safely through a single, predictable interface. It used a simple JSON-based structure and could run over familiar transports like HTTP or standard input/output, allowing developers to wrap legacy systems such as calendars, spreadsheets, or Slack channels as MCP “tools.” The ambition was similar to WAP's: to let a new kind of entity—then mobile devices, now AI agents—access resources that had been architected for an older technological world.
Just as WAP makes the web “work” on early phones, MCP makes the web of software “work” for early agents. And like WAP, it reveals the awkwardness of translation. Agents must mimic developers by issuing API-style calls and interpreting structured responses, rather than engaging with digital environments natively. For now, MCP is essential scaffolding—it allows the emerging agent ecosystem to function across today's fragmented landscape. But if the pattern holds, it will likely fade once systems become agent-native, meaning that data, applications, and environments are built to speak directly to intelligent models rather than through a compatibility layer.
In that sense, MCP stands to agents as WAP once did to mobile phones: a necessary bridge to an unfamiliar world that will disappear when the new medium learns to walk on its own.
The real change, then, will come when we start to build the web for agents. Exploring what this means is not an easy task, however, and it may also be quite transformative. Our kids might laugh at us when we explain that we had “browsers” and “surfed the web” - since in one scenario it is quite likely that there will not be browsers or a web at all – just a set of resources that can be compiled on the fly by agents into useful combinatory interfaces and services. Agents have no reason to think in “sites” or “pages” - and many of the other metaphors we have imposed on the technology.
Why is this interesting for our research project here at the TUM Think Tank? Because I think the way this future network of resources is built will depend on how we understand agency and agents overall – it may mean we have to also ask the question of what different kinds of agents there are, and which we should focus on as we build new network layers for agents. The term agent is used for everything these days. As Brinnae Bent has shown in her recent paper “The Term 'Agent' Has Been Diluted Beyond Utility and Requires Redefinition” (2025) we have used the term to mean almost anything: She proposes to redefine it as something that needs to fulfill three basic requirements. For something to be qualified as an agent it must...
- …have a measurable impact on its environment.
- …have goal directed behavior.
- …have some kind of state awareness
If qualified as an agent, we can then categorize different kinds of agents across different dimensions. From her paper:
This work is reminiscent of the taxonomic attempts by Atoosa Kasirzadeh and Iason Gabriel to categorize agents for alignment purposes and there are many other taxonomies as well – but what would a taxonomy look like if we focused on how networked resources of different kinds should be organized? How would we characterize agents if we were using that taxonomy to redesign the web for agents?
Well, first we should recognize that it may not be a “web” at all – but rather something we could call a “capability mesh” or just the mesh for short. Agents would dip into the mesh to solve tasks of various kind and duration and at the same time offer capabilities in that mesh in return. If we turn specifically to the kind of taxonomy that would be helpful for thinking about the architecture of the mesh, then we could end up with something like this.
Or, in a table:
