Issue
Article
Vol.28 No.3, July 1996
Article
Issue
Issue |
Article |
Vol.28 No.3, July 1996 |
Article |
Issue |
This paper concerns the development of interfaces which perform tasks on behalf of the user. Recently the concept of task delegation has gained consideration due to the increasing number of assignments that are quite repetitive and tedious, like dealing with electronic messages, managing personal agendas, retrieving data and information in remote and distributed repositories. These tasks are generally connected to the development of computer networks. The design of such interfaces presents a high degree of complexity since the relationship with the user and his needs is very critical: in most cases the user wants to control the jobs to be mechanized but in the same time he wants to be free from wasting his time in performing repetitive patterns of actions. In this paper the main problems concerning the design of active and cooperative interfaces are investigated. Then a solution is proposed based on the approaches of software agents and distributed architectures. Starting point of the project is to integrate and make accessible different tools and applications regularly utilized by a user: all these elements concur in building a flexible and scalable environment that the user can access through intelligent agents that work as interfaces.
Introduction
One of the major problem in designing interfaces is the necessity of adapting them to the user and to the application: general design principles can be stated but then an adaptation process must be performed. In the past many interfaces were designed according to the behavior and the needs of the typical user, a mysterious individual who spent his time in testing each application and tool he was able to find. After years of difficult search, the designers have turned their attention to make the interfaces able to adapt themselves to the users and their needs.
The approach adopted in our project, born from the cooperation of two research institutions, is to design adaptive intelligent interfaces endowed with the capability of bidirectional interaction in with both the user and the interface can initiate communications and take initiative [kay90]. The aim is to obtain active and cooperative interfaces [fisher85] able to adapt themselves or their interaction methods to their interpretation and understanding of the user's needs. The metaphor pursued is that of a personal assistant which supports the user and collaborates with him in the same work environment [laurel], the so-called interface-as-agent option. The interface appears as an intelligent interface agent although consisting of different active entities. The whole interface may assume a tutorial role with respect to the user who can modulate its intervention level and autonomy degree: it should be able to make the user free from learning many technicalities, from being aware of the complexity of the domain, etc. Moreover, it should offer supplementary performances than those expected from the tool(s) it is making accessible to the user.
Another keynote issue of our approach is to incorporate in an agent pieces of tools and applications freely available on the Internet: instead of developing application from scratch, it is possible to recycle tools that someone else built in a sort of software ecology. Our starting point was to integrate and make accessible the different tools and applications usually utilized by a user: moreover our idea was also to exploit the resources offered by the diffusion of the Internet with respect to both the quantity of information available and the different types of tools and free-software offered. All these tools, applications, etc. should concur in building an environment flexible and scalable, in which it is possible to easily add (or subtract) functionalities or to substitute parts of code with others that perform the same task in a different way.
In pursuing those goals it was immediately obvious that a single system could not afford the management of all the user's tasks: it would be a too complex assignment requiring huge amount of different kinds of knowledge, different problem solving capabilities, etc. Our solution consists of building a society of specialized agents, a Multi-Agent System, coordinated by an agent, called Interface Agent particularly designed to interact with the user, a sort of personal assistant that works in cooperation with all the others. The whole system although appears as a single, uniform interface is indeed composed by different specialized entities each of them implemented on its own as a Multi-Agent System.
The number of the agents in the interface depends on the needs and the duties of the user: each system, subsystem, program, tool, etc. the user uses can be integrated in an agent that is in charge of mediating between him and the application and the environment. A single agent is characterized by general capabilities and specific abilities: for example it is able to communicate with the environment in a manner homogeneous with respect to the other agents, but it is the only agent able to tackle with a specific problem.
Following these concepts we have implemented an interface system for helping users in repetitive tasks that coordinates and supervises several activities.
In designing the whole system, there were two methodological aspects coming out that were more general and not strictly connected with the particular application environment: we had to design an architecture for single agents that satisfied requirements like scalability, flexibility, active and cooperative support; we had to study the problems connected to the integration of the software agents methodology and the distributed architectures to build such a kind of environment.
This paper accounts for both general ideas and particular applications that are involved in our study. We start by illustrating the basic ideas of building a Multi-Agent System as an interface and a description of the generalized agent architecture is presented. We then depict the current use of the approach in setting up a distributed interface to alleviate the user from repetitive office tasks. We end with some conclusive remarks.
The general features we wanted to achieve with the adopted approach were the following:
We have also addressed two methodological issue quite relevant for the generality of the approach:
In designing the different agents supporting the user we have defined a skeletal agent that contains all the functionalities (the infrastructure) that are common to all the agent instances and that allowed the application designer to specialize parts of the agent or add new capabilities when addressing a specific problem.
The present agent architecture, shown in Figure 1, comes from various earlier versions and incorporates aspects both from our experience and from the study of other proposals [steiner], [jennings], [etzioni94], [etzioni95], [muller].
Figure 1: General Architecture for an Active Agent-Based Interface
A useful metaphor we took from [steiner] is the subdivision of the agent's structure in three broad modules useful to separate aspects that are conceptually different:
The agent's Communicator, which is accessible from both the Head and the Body boxes, is subdivided in specialized devices according to the different interactions the agent may have:
The Head is the module that coordinates the internal activities and guarantees the autonomy of the whole agent. The basic Head consists of:
The Body is a collection of specialized routines for particular tasks. This part is customized according to different application needs, and may also incorporate external code or software tools. The different tasks contained in the Body may take control of the communication channels during their activities and leave results of their computation in the working memory. The Head is the only part responsible for the activation of different Tasks contained in the Body. Our prototypical environment allows for the adaptation of agents to current tasks.
The agent architecture is general enough to be adaptable to different purposes. A reflection is worth about the possible ways to address single problems with a multi-agent system of this kind.
It may be observed that different pre-existing software systems, also public domain utilities, may be attached to the agents' bodies. In this way it is possible to create agents that "represent" a particular software tool within an end-user application: moreover the architecture allows for avoiding software duplications using systems running on different sites by sending messages to their representative agents.
A different aspect concerns the natural way that agents allow for representing functional distinctions within a given application. For example it is possible to distinguish the part of the system that is in charge of continuously interacting with the user from the part that carries out the special task functions; it is also possible to consider the active and passive part of the interface as distinct autonomous parts. It should be noted that as far as system design is concerned the different role played by agents with respect to "conventional" objects lies on the possibility of obtaining flexible behaviors according to the context.
A further point concerns the development of multi-user applications. In such cases not only the interface part may be distinguished into user-interface and task-delegation part but also the possibility exists of cloning single specialized agents or sets of agents and adapting them to different users.
Although preliminary, these observations arise directly from our experience in building up the case-study described in the next section.
The concepts described in the previous sections have been applied to the development of environments for cooperative and active user's support in complex and/or time-consuming tasks -- above all those that come from or can be facilitated by the existence of the network -- by using the software agent framework according to the general architecture described. The basic idea is to offer an integrated environment in which the user can perform any task and solve any type of problems in a straightforward manner: although he is interacting with a complex and rich system, the Interface Agent works as a mediator by hiding the complexity of the environment. So the user always interacts with it even if the control of the interface moves from an agent to another.
At present a quite simple Interface Agent allows the user to contact several specialized environments, each developed according to a distributed approach. Each environment can be seen as a specific agent. In the current implementation there exist the following agents: the Mail Agent [cesta], the Meeting Agent [meeting-in-prep], the Info Agent [d'aloisa], the Storage Agent besides obviously the above mentioned Interface Agent. They are at different stages of development: the first two are fully implemented, the Info Agent is quite complete, the Storage Agent is in development phase. It is also expected a News Agent that will integrate in its body a software developed to automatically manage the newsgroups [amati]. Due to the scalability of the whole architecture, to the homogeneity of the agent's model, to the modularity of the agent's design, to the standard communication languages it is possible to add other types of agents or to modify the pre-existent ones with a modest effort.
In the following two agents are described each belonging to different classes of agents. The Mail Agent is a sort of information agent dealing with e-mail messages: other examples of information agents are the Info Agent, the Storage Agent and the News Agent. The other classes are those of the task delegation agents and the negotiation agents. The agents of the first class tackle with assignments that imply particular problem-solving capabilities. Agents in the second class bear a crucial part since they can substitute the user and perform operations in which the user himself would play an active role. So they must include a good representation of the user and of his behavior, be able to deal with private data, and be able to solve possible conflicts. The Meeting Agent exhibits several features from both the members of such classes.
The Interface Agent manages shared data, e.g., the user's profiles, and connects the user to the agent(s) that can solve his problem. Some agents can work in the background and call for attention when necessary.
Nowadays the electronic boxes are more and more similar to our mail boxes: a huge quantity of items the majority of which of scarce or null interest. Before selecting the letter one was just expecting, he is supposed to read any type of advertisement, etc. The same happens with the e-mail messages: announcements of conferences completely out of your interest domain, of books, of new products, etc. pack your mail box often causing the loss of interesting messages since you decide to give up reading. The Mail Agent helps the user to automatically select among the incoming e-mail messages (with e-mail messages we mean every types of electronic mail such as bulletin-boards, mailing-lists, interest groups, etc.) those satisfying constraints specified in one or more profiles.
Besides supplying a high-level interface to a complex language (there are several commercial tools that accomplish this task), the agent exhibits an active and cooperative behavior by adapting itself to the user's evolution. In fact, the Mail Agent goes beyond its main task, i.e., filtering information: it learns by continuously looking over the shoulder [maes94] and working in background while the user performs his daily activity. It can automatically improve the filtering process by suggesting modifications on the basis of a comparison between accepted and rejected messages, i.e., whether a rejected message can be caught again since it contains information that the user could find useful. When some new pattern of behavior emerges, the agent proposes modifications of the current status that the user can accept or reject: the final decision is always up to him.
This is part of the active behavior of the interface that tries to go beyond requests explicitly done. This kind of function characterizes all the agents can work in evolving situations.
The implementation of the Mail Agent reflects the basic principles illustrated in this paper. Its architecture is distributed and consists of four sub-agents, each devoted to deal with a particular aspect in the context of filtering e-mail messages: the Preference Specificator, the Refinement Proposer, the ProcMail Agent and the Message Manager. Each of these agents is designed on the basis of the architecture described earlier: moreover each agent can present a different development of the components described in Figure 1 according to the different assignments it is supposed to carry out.
Two public domain tools -- Procmail and Wais -- are employed that are powerful but of difficult usage for non-expert programmers. Their integration in the agent results in an increment of the performance of the whole system. Procmail's task would be simply to check each incoming e-mail message according to a number of user-defined filters. Wais is able to search trough a collection of databases (specified by the users): the documents in these databases are indexed according to standard information retrieval techniques (e.g., inverted file system and primitives for word weighting). One feature of Wais utilized in our system is the relevance feedback: once a relevant document has been retrieved, Wais is able to find all the documents that are similar to it. Procmail and Wais are respectively part of the body of the ProcMail Agent and of the Message Manager.
The Preference Specificator assists the user in setting the filter's constraints: it is possible to specify values for each field characterizing an e-mail message. A filter consists of a single specification or a chain of specifications. For each filter, the user can single out a sequence of pre-defined actions to be performed on the selected messages, e.g., "Forward them to Tom" or "Put them in the folder Jane", or can define new actions. The agent translates these preferences for the ProcMail Agent putting the result in the body of a KQML message.
The ProcMail Agent is in charge of actually generating Procmail filters. Along with the Preference Specificator, it avoids the user to learn the command language of ProcMail: in fact the user can specify his preferences in a plain mode without be aware of the complexity of the target language. Its first task is to translate the information coming from the Preference Specificator and asks to the ProcMail program, that is part of its body, to synthesize the filter. Then the filter returned by ProcMail is applied on the incoming e-mail messages. Each message is marked as accepted or rejected according to the filter(s), and then passed to the Message Manager. The accepted messages are also put in the mail box of the user or treated according to the specified actions.The ProcMail Agent attends at another processing phase, the revision of the filter setting as explained below.
The Message Manager stores the messages -- received from the ProcMail Agent -- marked as accepted in a database, named DB Mail. Each message in DB Mail is indexed by Wais -- that is part of body of the Message Manager -- and represented by term vectors. Each rejected message is transformed by Wais in a query against the indexed content of DB Mail. The search is done by finding the messages with the maximum weights for each word in the query. The query-message similarity value comes from the comparison of the corresponding vectors. If relevant messages are found in the rejected set then they are sent to the Refinement Proposer.
The messages coming from the rejected set and selected by the Message Manager are stored by the Refinement Proposer in a database, called DB Relevant. For each message in this database, the Refinement Proposer creates a new filter deducing it from the features of the message most similar to it. The user can control the filter and have an explanation about its definition: there is an interaction phase between the user and the agent, in which the user can ask and verify what happened and the agent shows the different steps that led to the new filter. Eventually the user can choose to accept, modify or reject the suggested filters. If the user accepts some of the modification proposed, this monitoring module sends a request to the ProcMail Agent of revising the current set of filters.
The developing concept of the whole Mail Agent is that, given a standard generation of filters by the user, the system gets a first idea of the user's interests and starts a work of observation and revision. Some of the rejected messages may be "similar" to one or more of the accepted ones. Chances are that the messages were deleted because of a "rigid" use of ProcMail by the user. A negotiation phase with the user is started to understand if he acknowledges the acceptance of the retrieved similar messages.
The performance of the agent can be modified by adding new "tasks" in the body or by substituting the old ones: for example if one develops a more powerful tool than Wais, it is sufficient to modify a part of the Message Manager's body.
The organization and scheduling of a meeting with a certain number of attendees are complex and time-consuming tasks for both the organizers and the guests. The involved people, or their secretaries, are supposed to reach an agreement about the place, the time, the duration of the event given the constraints of their personal agendas and of logistic and external problems. Another important issue to account for is the respect of the attendees' privacy who would prefer to keep their agendas secluded. The solution of the problem requires phases of communication, e.g., by phone, fax, e-mail and so on, negotiation, cooperation and application of conflict resolution strategies.
The Meeting Agent is an example of task-delegation agent playing a critical role since it does not simply substitute the user in handling with boring tasks, but it can take decisions instead of the user: its decisions influence the user's schedule and his relationship with other members of his community. Obviously the agent can take over from the user only when he trusts it and decides to let it work autonomously. As negotiation agent it has to pursue decision strategies always trying to guard the user's interests, although following some general social rules that also the user is supposed to respect.
In the current version, the Meeting Agent is able to automatically organize meetings, seminars and small conferences. It has a distributed architecture and consists of the following sub-agents: the Scheduling Agent, the Resource Agent, the Server Agent and the Travel Agent. In particular there is an instance of Scheduling Agent for each user while the other agents are shared by a community of users since they hold common information and data. Every group of users may refer to different agents depending on the nature of the shared knowledge. This is a case in which the utility of a distributed architecture is particularly evident.
The Meeting Agent is a sort of multiple interface since it avoids the user phoning, faxing, choosing for the right place, etc. The adaptation phase is very crucial since the user needs to trust the agent before delegating it decisions usually of his competence.
The Scheduling Agent maintains a knowledge base about the user containing his preferences, his interests, his availability, his agenda. The preferences express the user's attitudes with respect to his working time: for example, whether he likes to work on holidays, the vacation period, the hours of the day he prefers starting or finishing the job, etc. These preferences are expressed by a rule languages, but the rules are automatically extracted by the agent both on direct user's indication (there are a set of windows in which he can specify his choices) or from the observation of the user's behavior. A preference value corresponds to each type of preference and interest.
According to the situation, the Scheduling Agent can play the role of organizer or guest. When a meeting is announced, all the agents have to reach an agreement to make the event possible: obviously all the constraints have to be respected. From the preference values, the agents extract priority values that are utilized to make a first proposal in case of conflict: in absence of any conflict, the solution is simpler. If an agreement is not possible, a negotiation phase starts in which the organizer can ask the agents to relax some constraints. The hosts do not have the same importance level: for example, the agent of a speaker will be the last to which the organizer requires to change its schedule. Also the working position is taken into account: that is part of some general rules that can be set to characterize the general behavior of the agent, for example an agent respecting the hierarchy.
During and after the definition of the event, the host's Scheduling Agent contacts the other agents. The Server Agent maintains data regarding the address of the users and about their interests. So the Scheduling Agent sends the announcement of a meeting with its features to it: the Server Agent broadcasts it to all the interested or involved Scheduling Agents, then it returns the list of the supposed participants.
The Resource Agent knows the cities in which the users live, the places usually hosting meetings and the available resources. Moreover it is able to figure out the distance between different places. So it can single out the most convenient town and the place in which to organize the meeting or simply look for a place in a given town.
The Travel Agent has data about the timetable of trains, planes, etc. and information concerning hotels or similar. When requested, it can organize the travel in the place of the meeting by booking the plane and/or the hotel. It is to be noted that, due to the architecture of the system, the agents can access and use as part of their knowledge external databases: for example, the Travel Agent could search the time of a plane in the databases of an airline company.
In this paper we have illustrated some guidelines in the design of intelligent and cooperative interfaces based on the agent technology. Although the approach based on task delegation seems to be promising, many issues need to be better considered just concerning the relationship user-system and the control the user can exert on the system. At present, many of our efforts are focused on this topic: in designing the agents described in this paper, we have tried to respect the privacy of the users and to allow him to trust his agents little by little. For example, the Meeting Agent is very careful in making private information public. Besides the user can always control what is going on and stop the agent if he does not agree with it: then is the user who decides when leaving the control to the agent.
The current experimentation has shown the validity of the distributed approach that increases the flexibility and the scalability of the system, since it is possible:
Due to the fast development and the spreading of the telecommunication networks, these types of approaches will have larger and larger diffusion just to deal with the information overload and the increasing complexity of systems and resources. Often the user has to manage situations that are not directly implied by his daily work or are not in the focus of his interests: as a consequence, he does not want to waste time and efforts in learning how to face with these situations.
It is to be noted that most of the agent-based research is system-oriented, i.e., based on the development of solutions. In the future, it will be necessary to develop theories underlying these systems, as well as to include experimentation phases after having defined suitable metrics.
The authors wish to thank Vittorio Giannini and Rodolfo Brancaleoni for their contribution in the project. Daniela D'Aloisi carried out her work in the framework of the agreement between the FUB and the Italian PT Administration. Amedeo Cesta's work is realized in the framework of the ESPRIT III Working Group No.8319 "A Common Formal Model of Cooperating Intelligent Agents (ModelAge)".
Amedeo Cesta is a research scientist at the Institute of Psychology of the National Research Council of Italy. His research interests include artificial intelligence planning systems, multi-agent interaction and man-machine interfaces.
Daniela D'Aloisi is a research scientist at Fondazione Ugo Bordoni in Rome. Her research interests include human-computer interaction, distributed artificial intelligence and sofware agents.
More information about the project may be found at the Web page: http://airone.fub.it/projects/agents.html .
Amedeo Cesta
IP-CNR
National Research Council of Italy
Viale Marx 15
I-00137 Rome, Italy
amedeo@pscs2.irmkant.rm.cnr.it
Daniela D'Aloisi
Information Systems Group
Fondazione Ugo Bordoni
Via B. Castiglione 59
I-00142 Rome, Italy
Issue |
Article |
Vol.28 No.3, July 1996 |
Article |
Issue |