From: AAAI Technical Report SS-94-03. Compilation copyright © 1994, AAAI (www.aaai.org). All rights reserved.
An Experiment in the Design of Software Agents
HenryA. Kautz, Bart Selman, MichaelCoen, and StephenKetchpel
AI Principles ResearchDepartment
AT&T
Bell Laboratories
MurrayHill, NJ 07974
{kautz, selman}@research.att.com
mhcoen@ai.mit.edu
ketchpel@cs.stanford.edu
real worldis an unpredictableplace: messages
betweenagents
Abstract
Wedescribe a bottom-upapproachto the designof
softwareagents. Webuilt andtested an agent systemthat addressesthe real-worldproblemof handling the activities involvedin schedulinga visitor
to our laboratory. Thesystememploysboth taskspecific and user-centered agents, and communicates with users using both email and a graphical
interface. Thisexperimenthas helpedus to identify
crucial requirementsin the successful deployment
of softwareagents,includingissues of reliability,
security, and ease of use. Thearchitecture wedevelopedto meetthese requirementsis flexible and
extensible, and is guidingour current researchon
principlesof agentdesign.
1 Introduction
Thereis muchrecentinterest in the creationof softwareagents
(e.g., Etzioniet al [2], Maes
[4], Dentet al [1], Shoham
[7]).
rangeof different approachandprojectsuse the term"agents",
ranging from simple shell programming
programsystemsto
agentsincorporatingsophisticatedreal-timeplanningandplan
executioncapabilities.
In our ownapproach,agentsassist users in a rangeof daily,
mundane
activities, suchas setting up meetings,sendingout
papers, locating informationin multipledatabases,tracking
the whereaboutsof people, and so on. Ourobjective is to
designagents ("bots") that blend transparently into normal
workenvironments,
whilerelieving users of low-leveladministrative andclerical tasks. Wetake the practical aspect of
softwareagentsseriously: users shouldfeel that the bots are
reliable andpredictable, andthat the human
user remainsin
ultimatecontrol.
Oneof the mostchallengingaspects of agent designis to
definespecifictasks that are bothfeasible usingcurrenttechnology,andare truly useful to the everydayuser. Furthermore,
it became
clear duringthe testing of our initial prototypethat
users havelittle patiencewhenit it comesto interactingwith
softwareagents. Wetherefore paid special attention to the
user interface aspectsof our system.In particular, whenever
possible, weopted for graphically-orientedinterfaces over
puretext-basedinterfaces. In addition,reliability anderrorhandlingis crucialin all parts of a softwareagentsystem.The
43
maybe lost or delayed, people mayrespondinappropriately
to requests,andso forth.
Our approach has been bottom-up. Webegan by identifying possibleusefulandfeasible tasks for a softwareagent.
Thefirst suchtask wechooseinvolvedthe activities surrounding the schedulingof a visitor to our lab. Wedesignedand
implemented
a set of softwareagents to handlethis task. We
deliberately madeno commitment
in advanceto a particular
agent architecture. Wethen tested the systemwith an actual
visitor. Thefeedbackfromthis test led to manyimprovements
in the designof the agentsandthe human/agent
interfaces, as
well as the development
of a general and flexible framework
for agentinteraction. Thekeyfeature of the framework
is use
of personalizedagentscalled "userbots"that mediatecommunication betweenusers and task-specific agents. Weare now
in our third roundof implementation
andtesting, in whichwe
are further refiningandgeneralizingour userbotsso that they
can communicatewith software agents developedby other
researchgroups,suchas OrenEtzioni’s"’softbots"[3].
In this paperwedescribethe designof our softwareagents,
and the lessons wehavelearned duringthe constructionand
testing of the system. Ouragents currently run at andcommunicatebetweenBell Laboratoriesand MIT,and, soon, the
University of Washingtonand CMU.
Webelievethat the bottom-up
approachis crucial in identifying the necessarypropertiesof a successfulagentplatform.
Aswewill see in this paper, our initial experiments
havealreadyled us to formulatesomekeyproperties. Examplesincludethe separationof task-specificagentsfromuser-centered
agents,the needto handleissues of security andprivacy,and
as mentionedabove,the need for goodhumaninterfaces and
high reliability. Webelievethese kindsof issues shouldalso
be addressedby theoretical workin agent design. For example,ultimately one wouldlike to be able to provethat no
communication
deadlockscan occur in an agent system.
2 The Visitorbot
Asnoted in the introduction, selecting an appropriatetask
for softwareagentsto performis itself a challenge.Agents
mustprovide solutions to real problemsthat are important
to real users. Thewholeraison d’etre for softwareagentsis
lost if they are restricted to handlingtoy examples.Onthe
other hand, morecomplextasks frequently include a whole
range of long-range research issues, such as understanding
unrestricted natural language.
After considering a numberof possible agent tasks, we settied on the problemof scheduling a visitor to our lab. 1 This
job is quite routine, but consumesa substantial amountof the
host’s time. The normal sequence of tasks consists of announcing the upcomingvisit by email; collecting responses
from people whowouldlike to meet with the visitor, along
with their preferred meetingtimes; putting together a schedule that satisfies as manyconstraints as possible (taking into
account social issues, such as not bumpingthe lab director
from the schedule); sending out the schedule to the participants, together with appropriate information about roomand
telephone numbers;and, of course, often rescheduling people
at the last minutebecauseof unforeseenevents.
Wedecided to implement a specialized software agent
called the "visitorbot" to handle these tasks. After examining
various proposedagent architectures (e.g., Etzioni et al [3] and
Shoham[7]), we decided that it was necessary to first obtain
practical experience in building and a using a concrete basic
agent, before committingto any particular theoretical framework. Our initial implementation was a monolithic agent,
that communicateddirectly with users via email. The programwas given its ownlogin account ("visitorbot"), and was
activated upon receiving email at that account. (Mail was
piped into the visitorbot programusing the ".forward" facility
of the Unix mail system.)
Ourexperiencein using the visitorbot in schedulinga visit
led to the followingobservations:
1. Email communicationbetween the visitorbot and humans was cumbersomeand error-prone. The users had to
fill in a pre-defined form to specify their preferred meeting
times.2 Smallediting errors by users often madeit impossible
to process the forms automatically, requiring humanintervention. Moreover,users other than the host objected to using the
visitorbot at all; fromtheir point of view, the systemsimply
madetheir life harder.
Basedon this observation, we realized that an easy to use
interface was crucial. Wedecided that the next version of the
visitorbot wouldemploya graphical interface, so that users
could simplyclick on buttons to specify their preferred meeting times. This approach practically eliminated communication errors betweenpeople and the visitorbot, and was viewed
by users as an improvementover the pre-Bot environment.
2. There is a need for redundancyin error-handling. For
example, one early version of the visitorbot could become
confused by bounced email, or email responses by "vacation" programs. Althoughour platform has improvedover the
initial prototype, there is still muchroomfor improvement.
The agents must react moreor less predictably to both foreseen errors (e.g., mangledemail), and unforeseenerrors (e.g.,
1See also Dentet al [1] and Maesand Kozierok[5], that describe the designof softwareagentsthat learnhowto assist users in
schedulingmeetingsand managing
their personalcalendars.
2Weconsideredvarious formsof natural languageinput instead
of forms.However,
the current state of the art in NLPcannotparse
or evenskimunrestrictednaturallanguage
withsufficientreliability.
Onthe other hand,the use of restricted "pseudo"-naturallanguage
has little or no advantage
overthe use of forms.
44
a subprocess invoked by the bot terminates unexpectedly).
Techniquesfrom the area of software reliability and real-time
systems design could well be applicable to this problem.(For
example, moderntelephone switching systems have a downtime of a few minutes per year, because they continuously run
sophisticated error-detection and recovery mechanisms.)
3. The final task of creating a goodschedule from a set of
constraints did not require advancedplanning or scheduling
techniques. The visitorbot translated the scheduling problem
into an integer programmingproblem, and solved it using a
general integer programmingpackage (CPLEX).An interesting advantageof this approachis that was easy to incorporate
soft constraints (such as the difference between an "okay"
time slot and a "good"time slot for a user).
This experience led us to the design shownin Fig. 1. This
design includes an agent for each individual user in addition
to the visitorbot. For example,the agent for the user "kautz"
is named "kautzbot", for "selman" is named "selmanbot",
and so on. The userbots mediate communicationbetween the
visitorbot and their humanowners.
The normalinteraction betweenthe visitorbot and the users
proceeds as follows. The initial talk announcement
is mailed
by the vistorbot to each userbot. The userbot then determines
the preferred mode of communication with its owner. In
particular, if the user is loggedin on an X-terminal,the userbot
creates a pop-up windowon the user’s screen, containing the
announcementand a button to press to request to meet with
the visitor, as shownin the left-hand windowin Fig. 2. If
the user clicks on "yes", the userbot passes this information
backto the visitorbot, whichrespondswith a request to obtain
the user’s preferred meetingtimes. The userbot then creates
a graphical menuof meeting times, as shownin the righthand windowin Fig. 2. The user simply clicks on buttons to
indicate his or her preferences. The userbot then generates a
messagecontaining the preferences and mails it back to the
visitorbot. If the userbot is unable to determinethe display
where the user is working,or if the user fails to respond to
the pop-updisplays, the userbot forwardsthe request from the
visitorbot via email to the user as a plain text form.
Thereare several importantadvantagesof this design. First,
the visitorbot does not need to knowabout the user’s display, and does not need permission to create windowson that
display. This means, for example, that a visitorbot at our
institution can create a graphical windowat any site that is
reachable by email where there are userbots. This was successfully tested with a the "mhcoenbot"running at MIT. 3
The separation of the visitorbot from the userbot also simplifies the design of the former, since the userbots handle the
peculiarities of addressing the users’ displays. Even more
importantly, the particular information about the user’s location and workhabits does not have to be centrally available.
This informationcan be kept private to the user and his or her
userbot.
3Sometimes
it is possibleto create a remoteX-window
over the
intemet,but this is proneto failure. Among
other problems,the user
wouldfirst haveto grant permissionto ("xhost")the machinerunning
the visitorbot program;but note that the user maynot evenknowthe
identity of machineon whichthe visitorbot programis running.
user kautz
I
~¢
t
user selman
t’
user mike
Figure1: Current architecture of the agent system.Solid lines represent email communication;
dashedlines represent both
graphical and email communication.
Anotheradvantage
of this designis that different users, who
mayhaveaccess to different computingresources, can run
different userbots,of varyinglevels of sophistication.Thus,
everyoneis not restricted to a "least common
denominator"
typeinterface.
Perhapsthe mostimportantbenefit of the design is that
a task-specific agent(suchas the visitorbot) is not tied
anyspecific formof communication.
Thetask-specific agent
specifies whatinformationis to transmittedfor obtained,but
not howthe communication
should take place. Theuserbot
can then employa wide range of media, such as graphics,
voice, FAX,email, etc. for interacting with its owner.The
userbotcan take into accountits ownerspreferencesandsuch
factors as the ownerswhereaboutsand current computing
environmentin deciding on the modeof communication.
For
example,a userbot could incorporatea telephoneinterface
with a speechsynthesizer. This wouldenable a userbot to
place a call to its owner(if the ownerso desires), read the
talk announcement,
and collect the owner’spreferences by
touch-tone. Note that this extension does not require any
modificationto the visitorbot itself. In the next section we
will discussuserbotsin moredetail.
taggedwith a special headerfield, "XBot-message-type".
The
messagetype indicates the general wayin whichthe bodyof
the message(if any) shouldbe processedby the receiver. For
example,the messagetype"xchoices"meansthat the message
is a requestfor the receiver to makea series of choicesfrom
among
oneor moresets of alternativesdescribedin the bodyof
the message.Theinclusion of the field "XBot-return-note"
in
the message
indicatesthat the result of processingthe message
should be mailed back to the sender. The communication
protocolestablishes the syntaxfor the data presentedin the
bodyof each messagetype, and the format of the data that
results fromprocessingthe message.However,the protocol
deliberately does not specify the exact methodby whichthe
processingis cardedout. For example,a userbot mayprocess
an xchoicesmessageby creating a pop-upmenu,or calling
the user on the telephone,or simplyby consultinga database
of defaultsthat the user has established.
Whenapplications are developedthat demandnovel kinds
of interactions with userbots, the communication
protocols
can be extended by adding new messagetypes. This will
require the creation of mechanisms
for distributing "updates"
to the userbotsto handlethe extensions(an issue wereturn to
in Section4 below).So far, however,only a very smallnumber of messagetypes (namely,ones for requesting choices,
3 Active Userbots
requesting help, and simplyconveyinga piece of informaTestsof the visitorbot/userbotsystemdescribedin the previous tion) havebeenneeded.Onequestionthat moreexperiencein
sectionshowed
that users greatly preferredits easeof use and buildingbots will answeris whethernumberof basic message
flexibility over our initial monolithic,email-based
agent. Now types is indeedbounded
and small, or if newtypes are often
that wehad developeda goodbasic architecture, the logical
neededwith newapplications.
nextstep wasto incorporatenewtask-specificagents.In order
In essence, then, the messagesthat task-specific bots and
to do so, weundertooka completereimplementationof the
userbotsexchange
can be viewedas intensions- sucha request
system.In the newimplementation,all visitorbot-specific
to makea choice - rather than extensions - for example,
codewaseliminatedfromthe userbots. Wedesigneda simple if one were to mail a messagecontaining a programthat
set of protocolsfor communication
betweentask-specific and drawsa menuon the screen whenexecuted. In this regard
userbots. Again,our approachwaspragmatic,in that wetried
it is informativeto contrast our approachwith that used in
to establisheda minimal
set of conventions
for the applications Telescript, the electronic messaginglanguagecreatedGeneral
wewereconsidering,rather than immediately
trying to create
Magic.In Telescript, messages
are full-fledged programs,and
a full-blownagentinterlingua.
are executedon the receivingmachineby a fixed interpreter.
In brief, bots communicate
by exchangingemail whichis
Thus,Telescript messagesare purely extensional. Whilethe
45
[]
x~d
~
[]
ilessafefrou Yisitarbot
(ll:20ouTue~ Jan 18)
[]
[] xsched
Heuago iron Vlsitorbot
(11=15e. Tues Jan 18)
Check boxes to Indicatetlou
to neet ulth Oren Etzioui
on Thursday, January 20.
~* Talk Rnnouncenent ***
Sortbots a8 Testbedl; for fiT
Oren Etzioui
Univ. or Rashlngton
1 u111 descriha our project to develop
UNIX softbots (software robots)--coupleto
lntelllBent
agents that interact uith UHIX.
11=00 an Thurs Jan 20, Roun 28-402
Schedule
nectlng?
[]~
Figure 2: Graphical interfaces created by a userbot in response to messagesfrom the visitorbot. The left windowis created by
processing a talk announcement;
the right, by a request for the user’s preferred meetingtimes.
Telescript approachhas the advantagethat the reception of a
messagecan initiate arbitrarily novel and complexprocessing,
this mustbe weighedagainst the fact that any flexibility in the
way in which the interaction takes place with the user must
be built into each and every message. (Further comparisons
with Telescript appear in Section 4.)
Oneaspect of the preliminary userbot that someusers found
objectionable was the fact that various windows
(such as those
in Fig. 2) wouldpop-up wheneverthe userbot received mail,
which could be disruptive. Therefore, in the newimplementation messagesare normallynot displayed until the user makes
an explicit request to see any outstanding botmail. The interaction betweenthe user and his or her userbot is supported
by a continuously-running"active" userbot, as shownin Fig.
3. The main userbot windowindicates the number of outstanding messageswaiting to be processed, the userbot’s state
(working or idle), and three buttons. Clicking on the "process message"button allows the userbot to process messages
that require user interaction - for example, bringing up an
xchoices windowon behalf of the visitorbot.
The secondbutton, "user preferences", brings up a window
in which the user can set various options in the behavior of
his or her userbot. For example, checking the "antopilot"
box makes the userbot pop up windowswithout waiting to
be explicitly told to do so. The "voice" checkboxcauses the
userbot to announcethe receipt of newuserbot mail using the
speaker in a Sun workstation - a kind of audible "biff" for
botmail. The "forward to" options are used to indicate that
the userbot should choose try to communicatewith its owner
at a remote location - for example,by transmitting messages
46
via a FAX-modem
to the owner’s hometelephone. (Currently
the code to support the "forwardto" options has not yet been
completed. The exact appearance and functionality of these
options maydiffer in the final version.)
Finally, the third button in the mainuserbot windowbrings
up the windowlabeled "taskbots". This windowcontains a
button for each task-specific agent whoseemail address is
knownto the userbot. (This information is maintained in file
that the user can easily customize.) Clicking on a button in
this windowinitiates communicationwith the designed taskspecific agent, by sending a messageof type "help" to that
agent. The communicationprotocol specifies that the agent
should respond to a help message by sending back a menu
of commands
that the agent understands, together with some
basic help information, typically in the form of an xchoices
message.Whenthe userbot processes this response, it creates
a windowcontaining the appropriate controls for interacting
with that particular task-specific agent. For example,a user
whois hosting a visitor to our lab starts the entire process by
clicking on the visitorbot button. This leads to the creation of
a windowcontaining buttons for basic visitorbot commands,
such as schedulinga newvisitor, getting the status of a visit,
ordering a schedule to be generated, and so on. Clicking
on someof these buttons could lead to the creation of other
windows, for example, one in which to type the text of the
abstract of the visitor’s talk.
At the time that this paper is being written, only the visitorbot button in the taskbots menuis active. Overthe next
few weeks we intend to establish communicationwith Oren
Etzioni’s "finger" agent (used to obtain information about
adhoco290X
pud
/hoMe/kautz/research/agents
adhoco291~
ls
jcr_persona]bot
BRCKUP_xsched
Marl.requests.text
ketchDel-aQents.text
Figure3: Graphicaldisplayof a userbot.
people on the internet) [3], and TomMitchell’s "calendar"
agent (used to schedule meetingsamonggroups of people)
[1]. Thefingerbot and calendarbotwill not themselvesbe
portedto our laboratory’scomputers;instead, those programs
will run at their respective "homes"(Universityof Washington and CMU),and communication
with userbots at various
sites will take place usingordinaryinternet email. Wehope
that the idea of a userbotwill providea powerfulandflexible
framework
for integrating manydifferent kinds of software
agentsthat run in different computing
environments.
In general, this directory containsuser-specificinformation
for the userbot. It is importantto note that this directory
does not needto be publicly readable, and can thus contain
sensitive informationfor use by the userbot. Examplesof
such informationinclude the namesof peoplethe bot is not
supposedto respondto, unlisted hometelephonenumbers,the
user’s personalschedule,andso on.
Thus,userbotsprovidea generalmechanism
for the distribution and protection of information.For a concrete example, considerthe informationyouget by runningthe "finger"
command.
Right now,you have to decide whetheryour home
4 Privacy and Security
phonenumberwill be available to everyoneon the internet,
or no oneat all. Astraightforwardtask of youruserbotwould
Earlydiscussionswith potential users madeit clear that privacyandsecurityare central issues in the successfuldeploy- be to give out your phonenumbervia email on request from
at your departmentandpeoplelisted
mentof softwareagents. Someproposedagent systemswould (say) faculty members
filter throughall of the user’semail,pullingout anddeleting your address book, but not to every person whoknowsyour
loginid.
messagesthat the agent wouldlike to handle. Wefoundthat
users generally objected to giving a programpermissionto
Earlier wedescribedthe alternative Telescript modelin
delete automaticallyany of their incomingmall. Analterwhichmessagesare programsthat are executedon the receivnative approachwouldgive the bot authority to read but not ing machine.This modelraises concernsof computer
security,
modifythe user’s mail. Theproblem
withthis is that the user’s particularlyif suchprograms
are able to accessthe host’s file
mail quickly becomespolluted with the manymessagessent
system.(Securityfeaturesin Telescriptallowthe user to disbetweenthe variousbots.
able file access, but this wouldappearto limit the kindsof
Oursolution to this problemhas beento create a pseudo- tasks Telescript agents could perform.)Userbotsystemsare
accountfor each userbot, with its ownmail alias. Mailsent
by nature secure, insofar as the routines for processingeach
to this alias is pipedinto a userbotprogram,that is executed messagetypewithinthe userbotare secure.Although
this is a
underthe corresponding
user’s id. This gives the instantiated non-trivialcondition,it wouldappearto be easier to guarantee
userbotthe authority, for example,to create a window
on the
that the codeof the userbotitself (that is presumably
obtained
user’s display.Any"bot mail"sent to this alias is not seenby froma trusted source)is secure,rather thanto guaranteethat
the user, unlessthe userbotexplicitly decidesto forwardit.
every email program(that could comefromanyone)does not
Eachuser has a special ".bot" directory, whichcontains contain a virus. Extensionsandupdates to userbots to haninformationcustomizedto the particular user. Thesefiles
dle newmessagetypes wouldhaveto be distributed through
specifythe particular programthat instantiates the userbot, secure channels, perhapsby using cryptographictechniques
a log of the userbotmail, andthe user’s default displayid.
[6].
47
5 Bots vs. Programs
Anissue that is often raised is whatexactly distinguishes
softwareagents fromordinary programs.In our view, softwareagents are simplya special class of programs.Perhaps
the best wayto characterize these programsis by a list of
distinguishingproperties:
Communication:
Agentsengagein complexand frequent patterns of two-waycommunicationwith users and each
other.
Temporalcontinuity: Agentsare mostnaturally viewedas
continuouslyrunningprocesses,rather than as functions
that mapa single input to a single output.
Responsibility:Agentsare expectedto handleprivate informationin a responsibleandsecure manner.
Robustness:Agentsshould be designed to deal with unexpectedchangesin the environment.Theyshould include
mechanisms
to recover both fromsystemerrors andhumanerrors. If errors preventcompletionof their given
tasks, they still mustreport the problembackto their
users.
Multi-platform: Agents should be able to communicate
across different computer
systemarchitecturesandplatforms. For example,very sophisticated agents running
on a high-endplatformshouldbe able to carry out tasks
in cooperationwith relatively basic agents runningon
low-endsystems.
Autonomy:Advancedagents should have some degree of
decision-makingcapability, and the ability to choose
among
different strategies for performing
a giventask.
Notethat our list doesnot commit
to the use of anyparticular
form of reasoning or planning. Althoughadvancedagents
mayneedgeneral reasoningand planningcapabilities, our
experimentshaveshownthat interesting agent behaviorcan
alreadyemergefromsystemsof relatively simpleagents.
6 Conclusions
Wehave described a bottom-upapproachto the design of
softwareagents. Wehavebuilt and tested a bot systemthat
addresses a real-world problem,namelyhandling the communication
involvedin schedulinga visitor to our laboratory.
Currentlyweare extendingour systemto incorporatesoftware
agentscreated by other researchgroups.
Ourexperimenthelpedus to identify crucial factors in the
successfuldeployment
of agents. Theseincludeissues of reliability, security, andeaseof use. Securityandease of use
wereobtainedby separating task-specific agents frompersonal userbots. This architecture providesan extensibleand
flexible platformfor the further development
of practicalsoftware agents. Newtask-specific agents immediatelyobtain
a flexible andreliable graphicaluser interface for communicating with users via the userbots. Furthermore,additional
modalities of communication,such as speech and FAX,can
be addedto the userbots, withoutmodifying
the task-specific
bots.
Ourexperimentshave convincedus that software agents
mustblend unobtrusivelyinto the ordinaryworkenvironment
in order to be acceptedby real users. Webelieve that the
48
empiricalapproachtakenin this paperis essential for guiding
theoreticalresearchtowardthe truly centralanddifficult issues
in agentdesign.
7 Acknowledgements
WethankOrenEtzioni for stimulatingdiscussionsabout softbots duringhis visit to Bell Labs,leadingus to initiate our
ownsoftbot project. Wealso thank Ron Brachman,Mark
Jones, DavidLewisChris Ramming,
Eric Sumner,and other
members
of our center for useful suggestionsandfeedback.
References
[1] L. Dent, J. Boticario, J. McDermott,
and D. Zabowski.A
personal learning apprentice. In ProceedingsofAAAI-92,
pages 96-103. AAAIPress/The MITPress, 1992.
[2] OrenEtzioni, Steve Hanks,DanielWeld,DeniseDraper,
Neal Lesh, and MikeWilliamson.Anapproachto planning with incompleteinformation.In Proceedingsof KR92, pages 115-125. MorganKaufmann,1992.
[3] OrenEtzioni, Neal Lesh, and RichardSegal. Building
softbots for UNIX.TechnicalReport, 1992.
[4] Pattie Maes, editor. Designing Automomous
Agents.
MIT/Elsevier,1993.
[5] Pattie Maesand RobynKozierok. Learning interface
agents. In Proceedingsof AAAI-93,pages 459--464.
AAAIPress/The MITPress, 1993.
[6] R.L. Rivest, A. Shamir, and L. Adleman.A methodfor
obtainingdigital signaturesandpublic keycryptosystems.
Communications
of the ACM,21(2): 120-126, 1978.
Yoav
Shoham.
Agent-oriented
programming.Artificial
[7]
Intelligence, 60:51-92,1993.