In many work contexts it is often useful to employ specialized software
programs, called agents, to support the user both in cooperative and individual
work processes. These agents are allocated to specific users, i.e. the
default context of their operations is the user's actual workspace, as
shown in Figure 3. Their context can, however, be defined to be a resource
that belongs to the user, as the user's individual room for example (see
Chapter 2: agent's access rights).
It is not an intrinsic feature of these agents that they are sent over a network to be executed on a remote facility. We would rather see agents reside on different resources that are networked, where the communication between the agents is performed via communication channels that are available in the network.
From the point of view of the tasks they perform we distinguish two types of application agents within the Cooperation-Ware framework:
Instantiations of these two basic agent types can be used to compose higher level agents such as a representative agent that may act by proxy for a person within some work contexts. In the case of the room-based interaction metaphor for human cooperation, such an agent may reside in some person's workspace offering both some generic representative and some specific representative functionality with respect to an expected visitor/meeting.
The agents' ability to perform delegated tasks or monitoring activities may involve the necessity to interact with other agents to jointly perform some task. This is also reflected in Figure 1. Here a special type of agent, a user agent, mediates between the human and a specific application agent which is installed to carry out some task by providing appropriate interaction facilities for the user (see [11] for more information on the notion of user agent). The interaction within the agent society takes place on the level of the application agents which drive and encapsulate the actual application.
At this level, the accomplishment of certain tasks only may be achieved by the use of techniques of distributed problem solving. Fundamental to such distributed problem solving processes is the availability of high level protocols which allow the agents to transfer propositional information on the task under consideration and illocutionary information on their respective attitude concerning their intention to take part in a cooperative action. In order to allow such cooperation processes we provide so-called AISs (agent interaction scripts).
The foundation for these AISs have been laid in the MAI2L language (see [12]); MAI2L is a Multi-Agent Interaction and Implementation Language which is based on the integration of an agent interaction formalism with flexible planning facilities. The building blocks of the "cooperation language" provided within this framework consists of cooperation types (such as PROPOSE, REQUEST, REJECT, MODIFY, etc), cooperation objects (GOAL, PLAN, COMMITMENT; ORGANIZATIONAL_STRUCTURE, etc). These two entities can be used to build cooperation primitives (such as REQUESTing a COMMITMENT). Cooperation methods in turn are composed dynamically out of cooperation primitives. For a more detailed presentation with respect to the approach to agent based interaction see [13] and [14].
Our AISs are functionally comparable to such cooperation methods with the fundamental distinction that they are statically predefined. This has the advantage that we do not need sophisticated planning facilities for their execution. Thus, the user has a number of LAs (library agents) at his disposal. These predefined, functionally dedicated agents can be accessed (i.e. licensed and activated) via an agent library. Typically a LA consists of an agent of both the user and the application category.
At the current stage, the creation of functionally new agents is purely in the hands of the programmer(s) of the agent library. In order to allow naive users of the Cooperation-Ware system to set up their own agents with new functionality, we are developing suitable mechanisms. These will range from means to specialize existing agent templates to a simple formalism for "programming" new agents. The design philosophy behind these extensions is, however, rather restrictive. It assumes that any end user facility for agent modification and definition has to be narrowly constrained to give the user only a fully transparent model, preventing him from unanticipated effects.