page 2  (6 pages)
to previous section1
3to next section

the meeting scheduling module could be a task-specific agent, which will manage and update a particular user's appointment and meeting agenda. The general-purposed finger service module, which can extract useful information from the network finger utility given user's login name and network address, can be viewed as an information-specific software agent. Although the boundary between these two types of software agents is quite arbitrary and vague, we make the distinction that typically task-specific agents access other agents (either task-specific or information-specific ones) and communicate directly with users, whereas information agents (usually) access only information sources, other information assistants and task-specific agents. Task-specific agents have knowledge of the task domain, information assistants relevant to performing various parts of the task. In addition, task assistants have strategies for resolving conflicts and fusing information retrieved by information assistants. Information assistants have models of the associated information resources, and strategies for conflict resolution and information fusion.

This architecture is mainly motivated by the following considerations:

ffl sharability: Many users can share information-specific software agents or task-specific agents. Typically, user applications will access several agents in parallel and one software agent can serve different application programs. The behavior of a software agent, essentially, could be easily described in a server-client model.

ffl Complexity hiding: Often information retrieval in support of a task involves quite complex coordination of many different agents. Having the user interact only through a relevant task assistant hides the underlying complexity and frees the user from having to know of, access and interact with a plethora of information seeking agents in support of a task. For example, the hosting visitor task involves four information agents and four task agents. However, the user interacts directly only with the Visitor Hoster agent, the main task assistant for the visitor hosting task.

ffl modularity and reuseability: Although software agents will be operating on behalf of their patrons|human users, pieces of code can be copied from one user to another without modifications or with little adaptation to take into consideration particular users' preferences or idiosyncrasies. One of the basic ideas behind the distributed agentbased approach is that software agents will be kept simple for ease of maintenance, initialization and customization.

ffl flexibility: software agents can interact in new configurations on-demand", depending on the information requirements of a particular decision making task.

3. Scenario: Organize a Visit

We illustrate the system architecture and the interactions of the information gathering agents in the visitor hosting scenario. A different variation of the hosting visitor task has also been explored by Kautz and his colleagues at Bell Labs [KSC94].

A visitor hosting agent should have the following capabilities: