The VisitorBot is a software agent that schedules meetings with a visiting researcher (who is presumably also giving a talk). The VisitorBot distributes the talk's abstract and accepts requests for meetings with the speaker. It then distributes schedule-outlines which are filled out by those interested in reserving a time slot. Finally, after receiving submitted time constraints from users, the agent generates (and distributes) a schedule of meetings with the visitor.
The history behind the development of this agent is revealing. The
version described in [Kautz et al., 1994] was begun at AT&TBell Labs while I
was a summer student there. However, due to numerous technical
difficulties, this agent was not yet completed by the time I returned
to MIT at the end of the summer.
Therefore, I
ported the agent to the MIT AI Lab in order to finish working on it.
Interfacing the agent to the AI Lab's mailer involved nontrivial
effort, and after completing it here, installing and debugging the
agent at Bell Labs remotely from MIT required a ridiculous amount of
time. (This was primarily due to Bell Lab's network ``firewall.'')
While writing the VisitorBot (among other agents), it
became clear that getting an agent to run at a particular location
required a large amount of site-specific information. Additionally,
an agent which centrally controlled all aspects of user-interaction
was prone to failure in a networked environment. (For example, it is
not possible to open X-Windows across a firewall.) Essentially, there
were no clean abstraction barriers for writing agent software.
The development of personal agents in [Kautz et al., 1994] was a first step towards establishing some minimum level of distinction between local and non-local agent activity. For example, the VisitorBot could tell a user's personal agent to open a window on the user's display rather than doing so itself. However, both the VisitorBot and its involved personal agents are very much ad hoc, non-generalizable creations. The personal agent in [Kautz et al., 1994] is hard-coded and custom tailored to the VisitorBot, i.e. a hypothetical PaperReviewBot would require that users obtain a different personal agent to interact with it. According to this approach, every time a new agent is written, each user must install the appropriate personal agent to permit interaction with it.
SodaBot was my reaction to the effort required for writing and installing the VisitorBot. Although we found that it was generally very easy to state succinctly the desired agent behavior in English, it was quite another thing to formulate this in Perl and C. This distinction differentiates between SodaBot and efforts in the field of automated programming. Loosely speaking, the shortest specification of a program is generally the program itself; however, given the highly specialized domain in which software agents function (at least in SodaBot), it is usually quite easy to give a short high-level specification of an agent's desired behavior. SodaBot takes advantage of this by allowing an agent creator to provide merely this high-level specification. The system essentially handles all the effort involved in actually realizing the specified agent.
We did not address in [Kautz et al., 1994] how a new agent is released to the world. The VisitorBot was a collection of random C and Perl files which had to be installed and configured by a skilled human being. The difficulties inherent in encouraging use of new agents are thus enormous. Not only would a new user need to be convinced that the files are safe to install and to use, but she would additionally have to be willing to trust the system could, for example, handle her e-mail properly. Finally, installing and running the VisitorBot also sometimes required root access, which generally would prevent the average user from installing it herself.
How to distribute new agents was the subject of much discussion over the summer. The approach in SodaBot was motivated by a discussion of distributed agent planning at a Bell Lab's Bot meeting, where Ron Brachman suggested that planning agents could e-mail STRIPS operators to each other. I was quite taken with this idea and it eventually found its way into SodaBot (where agents instead send SodaBot programs).