Building Interfaces as Personal Agents: a Case Study Amedeo Cesta
Daniela D'Aloisi
IP-CNR Information Systems Group National Research Council of Italy Fondazione Ugo Bordoni Viale Marx 15 Via B. Castiglione 59 I-00137 Rome, Italy I-00142 Rome, Italy
[email protected] [email protected] March 27, 1996 Abstract
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 di erent tools and applications regularly utilized by a user: all these elements concur in building a exible and scalable environment that the user can access through intelligent agents that work as interfaces.
1 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 nd. After 1
years of dicult 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 [10]. The aim is to obtain active and cooperative interfaces [8] 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 [12], the so-called interface-as-agent option. The interface appears as an intelligent interface agent although consisting of di erent 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 o er 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 di erent tools and applications usually utilized by a user: moreover our idea was also to exploit the resources o ered by the di usion of the Internet with respect to both the quantity of information available and the di erent types of tools and free-software o ered. All these tools, applications, etc. should concur in building an environment
exible 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 di erent way. In pursuing those goals it was immediately obvious that a single system could not a ord the management of all the user's tasks: it would be a too complex assignment requiring huge amount of di erent kinds of knowledge, di erent 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 di erent 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 speci c 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 speci c problem. Following these concepts we have implemented an interface system for helping users in repetitive tasks that coordinates and supervises several activities. 2
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 satis ed requirements like scalability, exibility, 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. In Section 2 the basic ideas of building a Multi-Agent System as an interface are illustrated and a description of the generalized agent architecture is presented. Section 3 depicts the current use of the approach in setting up a distributed interface to alleviate the user from repetitive oce tasks. Section 4 contains some conclusive remarks.
2 Multi-Agent Systems for User Interfaces The general features we wanted to achieve with the adopted approach were the following: Distributedness: a complex task is shared by several agents that cooperate to accomplish it (in a user-transparent manner). Standard and transparent communication: the agents exchange messages by using the KQML protocol [7]. Activeness: the agents exhibit an active and cooperative behavior since they try to understand the user's needs starting from the past and present states of a airs also when there is no explicit user's request. Cooperation: the agents use the user's behavior to modify their actions and to decide what to do next. Scalability: new agents able to perform di erent types of functionality can be incrementally added to the system. We have also addressed two methodological issue quite relevant for the generality of the approach: the design of a basic architecture for single agents powerful enough to be used in di erent situations, and exible enough to be customized to di erent application purposes without rewriting relevant amount of code; the study of the possible ways to map a particular problem into a multiagent system in which agents are specialized according to their task. More speci cally the problem has been addressed of building cooperative, active interfaces as multi-agent systems.
3
2.1 The Single-Agent Architecture
In designing the di erent agents supporting the user we have de ned 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 speci c 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 [14, 9, 6, 5, 13]. A useful metaphor we took from [14] is the subdivision of the agent's structure in three broad modules useful to separate aspects that are conceptually di erent:
The Communicator , a specialized module in charge of handling the communication toward the external world. External world here means: the software environment in which the agent operates, the other software agents that are connected to its activities, the user it supports.
The Head , a \Control Unit" that supervises all the internal activities of the agent.
The Body , containing basic specialized skills that characterize the agent.
Knowledge Component
KQML Message Manager
Other Agents
Reasoner Situation Assessment Planning Scheduling Task Activation Interaction with user
User Interface Manager Software Environment
Sensor
Working Memory
Actuator
HEAD Task 1
User
COMMUNICATOR Task 2
Task 3
Task N
BODY
Figure 1: General Architecture for an Active Agent-Based Interface The agent's Communicator, which is accessible from both the Head and the Body boxes, is subdivided in specialized devices according to the di erent interactions the agent may have: 4
The User Interface Manager , that takes care of the dialogue with the user. The basic function consists of managing a window where "content messages" produced by other parts of the agent are displayed. According to the application, this basic functionality is enriched when the agent is devoted to dialogue with the user. In agents that do not have direct contact with the user the functionality is used at implementation time for debugging purposes.
The Agent Interface , that is responsible for sending messages to and receiving messages from other software agents. At present, we have chosen an existing protocol for message exchange, the KQML language proposal [7], and have developed a \KQML Message Manager" that supports it.
The Software Environment Interface , that is responsible for executing Unix commands and for receiving answers from the Unix environment. The two functionalities are distinguished in the \Actuator" and \Sensor" boxes in the gure. It can be specialized to the software development environment.
The Head is the module that coordinates the internal activities and guarantees the autonomy of the whole agent. The basic Head consists of:
a \Knowledge Component" that contains a representation of the user environment, the other agents, the external environment, and any information needed to the long-term task of an agent; a \Reasoner" that takes decisions according to its long-term knowledge and the current state of a airs. In particular it has some basic capabilities for: situation assessment useful to analyze the working memory content and select a current agenda with issues to be solved, planning to decide combinations of elementary tasks, scheduling to temporalize tasks execution, and task activation to call (parts of) the Body. A separate but important part concerns the management of the agent's interactions. While the User Interface Manager is responsible for the communicative part, the reasoner must be able to elaborate cooperation and negotiation strategies to adapt its behavior to the user's. Moreover, it also manages the user's pro le; a \Working Memory" in which information about the current situation is gathered. This part of the agent is also accessible by the other two modules and has the role of a shared memory for information exchange.
The Body is a collection of specialized routines for particular tasks. This part is customized according to di erent application needs, and may also incorporate external code or software tools. The di erent 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 di erent Tasks contained in the Body. Our prototypical environment allows for the adaptation of agents to current tasks. 5
2.2 Putting Several Agents Together
The agent architecture is general enough to be adaptable to di erent purposes. A re ection is worth about the possible ways to address single problems with a multiagent system of this kind. It may be observed that di erent 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 di erent sites by sending messages to their representative agents. A di erent 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 di erent role played by agents with respect to \conventional" objects lies on the possibility of obtaining
exible 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 di erent users. Although preliminary, these observations arise directly from our experience in building up the case-study described in the next Section.
3 Active Interfaces for Repetitive Tasks 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 depicted in Section 2. The basic idea is to o er 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 speci c agent. In the current implementation there exist the following agents: the Mail Agent [3], the Meeting Agent [2], the Info Agent [4], the Storage Agent besides obviously the above mentioned Interface Agent. They are at di erent stages of development: the rst 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 6
manage the newsgroups [1]. 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 e ort. In the following two agents are described each belonging to di erent 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 rst 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 con icts. The Meeting Agent exhibits several features from both the members of such classes. The Interface Agent manages shared data, e.g., the user's pro les, 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.
3.1 The Mail Agent
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 speci ed in one or more pro les. 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., ltering information: it learns by continuously looking over the shoulder [11] and working in background while the user performs his daily activity. It can automatically improve the ltering process by suggesting modi cations 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 nd useful. When some new pattern of behavior emerges, the agent proposes modi cations of the current status that the user can accept or reject: the nal 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 re ects the basic principles illustrated in 7
this paper. Its architecture is distributed and consists of four sub-agents, each devoted to deal with a particular aspect in the context of ltering e-mail messages: the Preference Speci cator, the Re nement Proposer, the ProcMail Agent and the Message Manager. Each of these agents is designed on the basis of the architecture described in Section 2: moreover each agent can present a di erent development of the components described in Figure 1 according to the di erent assignments it is supposed to carry out. Two public domain tools|Procmail and Wais|are employed that are powerful but of dicult 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 userde ned lters. Wais is able to search trough a collection of databases (speci ed by the users): the documents in these databases are indexed according to standard information retrieval techniques (e.g., inverted le 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 nd 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 Speci cator assists the user in setting the lter's constraints: it is possible to specify values for each eld characterizing an e-mail message. A lter consists of a single speci cation or a chain of speci cations. For each lter, the user can single out a sequence of pre-de ned actions to be performed on the selected messages, e.g., "Forward them to Tom" or "Put them in the folder Jane", or can de ne 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 lters. Along with the Preference Speci cator, 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 rst task is to translate the information coming from the Preference Speci cator and asks to the ProcMail program, that is part of its body, to synthesize the lter. Then the lter returned by ProcMail is applied on the incoming e-mail messages. Each message is marked as accepted or rejected according to the lter(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 speci ed actions.The ProcMail Agent attends at another processing phase, the revision of the lter 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 nding 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 Re nement Proposer. The messages coming from the rejected set and selected by the Message Manager 8
are stored by the Re nement Proposer in a database, called DB Relevant. For each message in this database, the Re nement Proposer creates a new lter deducing it from the features of the message most similar to it. The user can control the lter and have an explanation about its de nition: 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 di erent steps that led to the new lter. Eventually the user can choose to accept, modify or reject the suggested lters. If the user accepts some of the modi cation proposed, this monitoring module sends a request to the ProcMail Agent of revising the current set of lters. The developing concept of the whole Mail Agent is that, given a standard generation of lters by the user, the system gets a rst 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 modi ed 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 sucient to modify a part of the Message Manager's body.
3.2 The Meeting Agent
The organization and scheduling of a meeting with a certain number of attenders 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 attenders' 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 con ict 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 in uence 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 di erent agents 9
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 nishing 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 rst proposal in case of con ict: in absence of any con ict, 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 de nition 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 gure out the distance between di erent 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.
10
4 Conclusions 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 e orts 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 exibility and the scalability of the system, since it is possible: to incorporate in the agents available applications or tools regularly used by the user; to use parts of di erent systems or external resources; to have di erent instances of a part of an agent; to have parts of agents places on di erent machines. Due to the fast development and the spreading of the telecommunication networks, these types of approaches will have larger and larger di usion 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 e orts 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 de ned suitable metrics.
Acknowledgments 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)".
References [1] G. Amati, D. D'Aloisi, and V. Giannini. A Framework for Dealing with Email and News Messages. In Proceeding of AICA Conference, pages 353{360, 1995. 11
[2] R. Brancaleoni, A. Cesta, and D. D'Aloisi. MASMA: A Distributed Meeting System Based on Agent Technologies. Technical report, FUB, Rome, 1996. in preparation. [3] A. Cesta, D. D'Aloisi, and V. Giannini. Active Interfaces for Useful Software Tools. In Y.Anzai, K.Ogawa, and H.Mori, editors, Symbiosis of Human and Artifacts (Proceedings of the 6th Int. Conf. on Human-Computer Interaction), pages 225{230. Elsevier Science, New York, 1995. [4] D. D'Aloisi and V. Giannini. The Info Agent: An Interface for Supporting Users in Intelligent Retrieval. In Proceedings of the ERCIM Workshop "Towards Interfaces for all: Current Trend and Future E orts", pages 143{155, 1995. [5] O. Etzioni, H.M. Levy, R.B. Segal, and C.A. Thekkath. The Softbot Approach to OS Interfaces. IEEE Software, pages 42{51, July 1995. [6] O. Etzioni and D.S. Weld. A Softbot-Based Interface to the Internet. Communication of the ACM, 37(7):72{76, July 1994. [7] T. Finin, J. Weber, and al. Speci cation of the KQML Agent-Communication Language. DRAFT, February 1993. [8] G. Fisher, A. Lemke, and T. Schwab. Knowledge-Based Help Systems. In Human Factors in Computing Systems (CHI '85 Conference Proceedings), pages 161{167, San Francisco, CA, 1985. ACM. [9] N.R. Jennings. Controlling Cooperative Problem Solving In Industrial MultiAgents Systems Using Joint Intentions. Arti cial Intelligence, 75(2):195{240, 1995. [10] A. Kay. User Interface: A Personal View. In B. Laurel, editor, The Art of Human-Computer Interface Design, pages 191{208. Addison-Wesley, Readings, Massachusetts, 1990. [11] Y. Lashkari, M. Metral, and P. Maes. Collaborative Interface Agents. In Proceedings of the 12th AAAI, pages 444{449. AAAI Press, 1994. [12] B. Laurel. Interface Agents: Metaphors with Character. In B. Laurel, editor, The Art of Human-Computer Interface Design, pages 355{366. Addison-Wesley, Readings, Massachusetts, 1990. [13] J.P. Muller and M. Pischel. The Agent Architecture InteRRaP: Concept and Application. Technical Report RR-93-26, DFKI, Saarsbrucken, June 1993. [14] D.A. Steiner, D.E. Mahling, and H. Haugeneder. Human Computer Cooperative Work. In H.Huhns, editor, Proc. of the International Workshop on Distributed Arti cial Intelligence, 1990.
12
About the Authors Amedeo Cesta is a research scientist at the Institute of Psychology of the National Research Council of Italy. His research interests include arti cial 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 arti cial intelligence and sofware agents.
More information about the project may be found at the Web page: http://www.airone.fub.it/projects/agents.html.
13
