Visions of Agents on the Web

The vision of intelligent agents on the Web is almost as old as the Web itself: in a keynote at WWW'94, Sir Tim Berners-Lee was noting that documents on the Web describe real objects and relationships among them, and if the semantics of these objects are represented explicitly then machines can browse through and manipulate reality. This vision was articulated more fully in the 2001 Semantic Web paper [[SEMWEB01]] and is now closer to realization through the standardization of the Web of Things at the W3C and the IETF.

In the AI community, the vision of a world-wide open network of intelligent agents also emerged in the '90s. In 2002, the AgentCities initiative was reporting a network of 41 agent platforms deployed in 21 countries [[WILLMOTT02]], which grew to 60 registered platforms in 2003 [[DALE03]] and 160 by 2005 [[JADE05]]. This network was based on standards developed by the Foundation for Intelligent Physical Agents (FIPA) but declined after the mid-2000s as industry attention shifted toward Web services. In parallel with AgentCities, the DARPA Control of Agent-Based Systems (CoABS) research program investigated the control, coordination, and management of large systems of autonomous software agents in military applications. Its central middleware, the CoABS Grid [[COABS1]], integrated heterogeneous agent-based systems, object-based applications, and legacy systems.

The DARPA CoABS program demonstrated the practical utility of agent technologies in large-scale deployments, while also highlighting significant challenges — for example, enabling agents to dynamically identify and interpret information sources [[COABS2]]. To address such issues, DARPA launched the Agent Markup Language (DAML) research program, which extended existing Web standards and laid the groundwork for the Web Ontology Language (OWL), Semantic Markup for Web Services (OWL-S), and other cornerstones of the Semantic Web. The DAML program advanced the original vision of the Web as an information space for both people and intelligent agents, and encouraged a shift from custom-built MAS middleware (e.g., CoABS Grid or FIPA platforms) to leveraging the Web's existing infrastructure. Such Web-based MAS received significant attention over the years, especially in the early 2000s with the advent of service-oriented computing [[SINGH06]].

Recent years have brought renewed interest in Web-based MAS — as evidenced by the Dagstuhl Seminar 21072 (Feb. 2021) and Dagstuhl Seminar 23081 (Feb. 2023) on "Agents on the Web", which led to the creation of the W3C Autonomous Agents on the Web (WebAgents) Community Group. A key enabler for this renewed interest is the Web of Things, which provides new practical use cases for Web agents and realizes several visionary ideas anticipated in the original Semantic Web paper [[SEMWEB01]]. Another key enabler is the recent progress in LLM-based agents that can follow instructions and use tools: just like previous generations of agents, LLM-based agents are designed for specific tasks, underscoring the need for open networks in which agents complement one another's abilities to solve more complex problems. New protocols and frameworks are emerging to support LLM-based agents to discover and use tools, or to discover and interact with other agents — many of them explicitly building on Web standards to foster interoperability (e.g., see the Model Context Protocol, Agent2Agent Protocol, Agent Network Protocol, Eclipse LMOS).

Conceptual Dimensions

A multi-agent system (MAS) has several distinguishing features. One key feature is decentralized control, where each agent makes its own decisions and controls its own behavior — yet the MAS as a whole exhibits coordinated behavior to achieve system-level design objectives. Another key feature is that capabilities, knowledge, and resources are distributed among agents, which creates inter-dependencies: agents participate in a MAS because they need to interact with one another to solve problems that would otherwise exceed their individual capacities. Without such inter-dependencies, the MAS would be a collection of isolated agents — and would not constitute a system at all.

A non-trivial MAS therefore consists of more than just agents: for example, it may also include the tools that agents use to achieve their goals, the protocols through which they interact, and the policies or norms that govern their behavior. In research on Engineering MAS, these concerns have been organized along four conceptual dimensions [[DEMAZEAU95]]:

• Agent dimension: abstractions for designing and programming agents;
• Environment dimension: abstractions for designing and programming the shared environment;
• Interaction dimension: abstractions for specifying interactions among agents and potentially other entities;
• Organization dimension: abstractions for structuring and governing agent behavior.

These conceptual dimensions help organize the complexity of non-trivial MAS — and are particularly relevant when designing Web-based MAS [[HMAS19]]: they offer a broader conceptual view of MAS (broader than just agents) while also defining the scope of the design space. For example, [[[#mas-web-transport-layer]]] shows a MAS modeled as agents that exchange messages. In this view, the Web is reduced to a message transport layer, an early perspective in research on Web-based MAS (see Section [[[#agents-web-services]]]). However, the Web was not designed as a transport layer (see Section 6.5.3 in [[FIELDING00]]).

In contrast, a broader conceptual view of MAS enables deeper integration with the Web: instead of limiting the Web to a transport layer for agent messages, it can leverage the Web as an application layer for MAS [[HMAS19]]. For example, [[[#mas-web-application-layer]]] shows a MAS that incorporates concepts from all four dimensions mentioned above. In this view, the Web serves as the application layer for the agent environment — for example, providing agents with shared tools, resources, and governance mechanisms. This perspective expands the design space for Web-based MAS and aligns more closely with the Web's original purpose and capabilities.

Architectural Considerations

This section discusses how architectures for MAS can integrate with the Web architecture [[WEBARCH]]. Section 3.3.1 defines design goals for Web-based MAS to motivate why alignment with the Web architecture is desirable. Section 3.3.2 introduces architectural patterns that describe MAS in terms of components and connectors, facilitating their mapping to the Web architecture [[FIELDING00]]. Section 3.3.3 presents a set of architectural constraints that specify the roles and features of components and connectors in a MAS to ensure alignment with the Web architecture.

Architectural Patterns

An architectural pattern specifies a general solution to a recurring design problem. [[[#pattern-language]]] shows a set of architectural patterns for situated MAS adapted from [[WEYNS10]]. The patterns are described using components and connectors as the main architectural elements.

A component is "an abstract unit of software instructions and internal state that provides a transformation of data via its interface" [[FIELDING00]]. A connector is an abstract mechanism that mediates interaction among components [[TAYLOR10]]. We use component-and-connector models because they facilitate alignment with the design of the Web architecture, as captured by the Representational State Transfer (REST) architectural style [[FIELDING00]]: REST defines a set of architectural constraints that apply to the components and connectors of a distributed hypermedia system — and, in addition, treats data elements as first-class architectural elements subject to the same constraints. We return to REST in Section [[[#architectural-constraints]]].

The original pattern language introduced by Weyns includes five patterns [[WEYNS10]]: situated agent, virtual environment, selective perception, protocol-based communication, and roles & situated commitments. In this report, we focus on the first two — the basic patterns — and leave the others for future work within the Autonomous Agents on the Web (WebAgents) Community Group. The language may also be extended with new architectural patterns, such as the policies & norms pattern shown in [[[#pattern-language]]].

In the following, we present the two basic patterns using UML component diagrams. We give concise overviews of the each pattern and illustrate their application in both modern LLM-based MAS and classical MAS (for detailed descriptions, see [[WEYNS10]]). We then discuss network-based connectors, focusing on Web interactions.

The situated agent pattern shown in [[[#situated-agent]]] includes a single data repository (Memory) and three components: Perception, Decision Making, and Communication. The Memory repository, accessible to all three components, stores both the agent's internal state and state that may be shared with other agents. This state may be static (e.g., a predefined list of contacts) or dynamic (e.g., a perceived change in the environment). Perception is responsible for sensing and interpreting run-time information from the virtual environment — and supports selective perception, enabling the agent to focus on information relevant to its current tasks. Decision Making is responsible for realizing the agent's tasks by invoking actions in the virtual environment. Communication is responsible for handling interactions with other agents.

One alteration we introduce relative to Weyns' original pattern is an explicit connection between Communication and Decision Making, allowing the latter to trigger communication acts. This configuration is common in more recent agent architectures, such as those employing information protocols [[KIKO23]].

The situated agent pattern applies naturally to classical agent architectures, such as Belief-Desire-Intention (BDI) agents [[JACAMO20]], which typically make use of all components. In contrast, many current implementations of LLM agents focus primarily on the Decision Making and Memory components: Communication may be implicit to Decision Making and Perception, and in many cases Perception may also be implicit — for example, when the agent perceives its environment only through observations returned by its actions.

The virtual environment pattern shown in [[[#virtual-environment]]] describes an adaptation layer that bridges the agent's level of abstraction with its deployment context. This adaptation layer can be implemented, for example, by a Model Context Protocol (MCP) server, a Universal Tool Calling Protocol (UTCP) server, or a WoT Thing Description Directory. The virtual environment exposes to agents a set of provided interfaces through which they can sense, act, or exchange messages (top of [[[#virtual-environment]]]), and may also define a set of required interfaces for interacting with the underlying infrastructure (bottom of [[[#virtual-environment]]]). For instance, an MCP server may wrap the HTTP endpoint of an industrial robot (the Operate required interface in [[[#virtual-environment]]]) to expose a set of tools accessible to LLM agents.

Some virtual environments may include tools that maintain State and implement their own Dynamics, or host Digital Twins that mirror the state of physical assets through the Synchronization component.

So far, we have examined components and their interfaces for situated agents and virtual environments. Connectors specify how these components interact. In this report, we are particularly interested in cases where such interactions are realized through the network-based connectors that rely on Web standards and technologies. One of the objectives of this report is to identify existing standards for these connectors and to highlight potential gaps where further standardization may be needed.

State of Web-based Multi-Agent Systems

Relevant Standards and Initiatives

Discussion

Relevant Standards and Initiatives

Discussion

Relevant Standards

Discussion

Relevant Standards and Initiatives

Discussion

Relevant Standards and Initiatives

Discussion

Relevant Standards and Initiatives

Discussion

Relevant Standards and Initiatives

ODRL, DIDs?

Discussion

Relevant Standards

Discussion

Accountability

Make a case for accountability; what do we need to enable accountability, e.g. transparency? answerability (building a dialogue)?