KAoS:A KnowledgeableAgent-oriented System
From: AAAI Technical Report SS-94-03. Compilation copyright © 1994, AAAI (www.aaai.org). All rights reserved.
Nicholas J. George
Robert J. Jasper
Monica Rosman LaFever
Katrina M. Morrison
Daniel B. Rosenthal
Stephen R. Tockey
John D.:Woolley
Seattle University
Jeffrey M. Bradshaw
EuropeanInstitute of Cognitive Sciences and Engineering (EURISCO)
and The Fred Hutchinson Cancer Research Center
EuropeanInstitute
Guy A. Boy
of Cognitive Sciences and Engineering (EURISCO)
Peter D. Holm
The Boeing Company
Abstract
crease in the comingdecades[Billings, 1991], [Boy
and Hollnagel, 1993]. The complexity, real-time
constraints, and distributed nature of suchtasks require that software not merely respondto requests
for informationbut intelligently anticipate, adapt,
and actively seek waysto support users. Not only
must these systems assist in coordinating tasks
amonghumans, they must also help managecooperation amongdistributed programs.
In this paper, wediscuss an effort to develop
and evaluate a generic agent framework.A
major goal of this workwasto separate genetic agent characteristics from domainspecific characteristics. Totest out our ideas,
we implementeda demonstration prototype
called KAoS(Knowledgeable Agent-oriented System) in SmaUtalk-80on the Macintosh, extending the Smalltalk primitives
in C.
Wedevelopedthe original system to support
local and distributed interapplication facilities using Apple Events, Program-to-Program Communication (PPC), Dynamic
Data Exchange (DDE), and TCP/IP protocols. Weare currently extending the architecture with: a more robust object
interoperability foundation (CommonObject Request Broker Architecture or CORBA), agent authoring and run-time
interfaces, and learning and adaptive mechanisms.
1
Introduction
Based on experience and recent studies, we expect
that automation of dynamic, real-time environmentssuch as air-traffic control will dramaticallyin24
[Brodie, 1989] has discussed the need for intelligent interoperability in such environments.He defines the term to meanintelligent cooperation
amongsystems to optimally achieve specified
goals. A high level of interoperability requires
knowledgeof the capabilities of each system, so
that task planning, resource allocation, execution,
monitoring, and, possibly, intervention between
the systemscan take place. Ideally, an intelligent
agent wouldfunction as a global resource planner.
While a single agent wouldbe workable for small
networks of systems, such a schemewouldquickly
becomeimpractical as the numberof cooperating
systems grows. Theactivity of the global resource
planner wouldbecomea bottleneck for the (otherwise distributed) system. A further step toward intelligent interoperability wouldbe to embedone or
more agents within each cooperating system. Applications would request resources through these
agents, thus providing a level of encapsulation at
the planning level, analogousto the encapsulation
providedin manyexisting applications at the level
of data exchangeprotocols.
Anequally important contribution of research on
agents maynot have to do with any direct technical
advantagethey afford, but rather with the fact that
taking this perspectivehelps us think aboutour software differently. Just as an object-oriented representation moreeasily and clearly expresses some
algorithms than a procedural representation [Kaehler and Patterson, 1986], so it sometimesmaybe
easier to use agents rather than objects. The agent
metaphorencouragesthe user to take an intentional
stance [Dennett, 1987], [Sharp, 1993]in predicting
the behavior of the system. This hopefully allows
the user to better cope with the increasing complexity and dynamicnature of software.
In this paper, we discuss an effort to develop and
evaluate a generic agent framework. The frameworkpromotes moreefficient and coherent communication amongpeople and their programs. After a
general overview of the project and architecture
(sections 2.1-2.3), we discuss the characteristics
that are common
to all KAoSagents (section 2.4).
response to newapplication requirements, we are
extendingthe architecture with a morerobust object
interoperability foundation, agent authoring and
run-time interfaces, and learning and adaptive
mechanisms(section 3).
2
KAoSOverviewand Architecture
KAoS(Knowledgeable Agent-oriented System)
part of a multiyear project to developa distributed
environment for software agents. Specifically,
KAoSprovides an infrastructure for programming
agents that includes: several network communications tools, distributed messaging,an agent communications protocol, and generic agent class
hierarchy, shell, and controls.
Webuilt KAoSusing Smalltalk-80 v. 4.1 and C on
the Macintosh. Weaugmented the underlying
Smalltalk interpreter to performdistributed agentto-application communication.Workon a portable
version that will run on Unix and Microsoft Windowsplatforms as well is currently underway(see
section 3.1).
Weinitially used KAoSto build a demonstrationof
agent-oriented programmingand to simulate various agent activities. Weare nowenhancingit for use
in two applications:
25
¯
real-time collaboration, information management, and decision support for the treatment of
bone-marrow cancer patients [Bradshaw
et al., 1993a].
¯ adaptive mobile performance support of aircraft maintenancepersonnel [Bradshawet al.,
1993c].
Theseapplications have provided both a rich source
of requirements for the KAoSarchitecture, as well
as a numberof interesting newproblemsto solve.
Figure 1 identifies importantelementsof the original KAoSarchitecture. Wediscuss each of them in
turn.
Domain-specific Agent Layer
Generic Agent Layer
Agent Message Layer
Message Server
NetMANIAC
AE
[ vPc [ DDE I TCP/IP
Figure 1. KAoSArchitecture Elements.
2.1
NetMANIAC
The Network Manager for Interapplication Communication (NetMANIAC)provides the foundation for the KAoS
architecture. It provides local and
distributed interapplication communicationfacilities using Apple Events (AE), Program-to-Program
Communication (PPC), Dynamic Data Exchange
(DDE),and TCP/IPprotocols.
2.2 Message Server
TheMessageServer provides a transparent interobject messageforwarding facility. It allows any object to exchange messages with any other named
object withoutknowingthe physical location of that
object.
2.3 Agent Message Services
Theagent messagelayer provides classes and methods for dealing specifically with agent messages.
This includes methodsfor distinguishing between
classes of messages that agents can send. Because
the MessageServer provides mappingof namesto
locations, agents need not knowwhere the agents
they are communicatingwith reside.
¯
2.4 Generic Agent Functionality
Request--sender asks receiver to makea commitmentto the sender.
The Generic Agent facility provides a framework
¯
Cancel--sender asks receiver to removea prefor constructing agents. KAoSprovides a ’generic
vious
commitment.
agent’ class from which you can specialize agents
¯
using inheritance. Thegeneric agent class includes
Refrain--sender asks receiver to not makea
particular commitment.
default behaviors, and includes classes and methods
for representing and updating an agent’s mental Theset of petitions is identical to those describedin
state. Youcreate agents of arbitrary complexityand
[Shoham,1990] and [Thomaset al., 1991]; we use
capabilities using this base class; this providesinthe term petition to refer to these actions in a more
heritance of general characteristics that allow
general way.
agents to be productive and communicateeffectively with other agents. Moreimportantly, program- Responsesare the answersreturned by the receiver
mers can create hierarchies of agents, each layer
of a petition:
¯ Accept--sender accepts the petition, which
specifying more specialized behavior and innate
knowledge.
ends the transaction.
¯
Reject--sender refuses to accept the petition,
A major goal of KAoSis to separate generic agent
characteristics from domain-specific characteriswhichends the transaction.
tics. Ourworkis a logical extensionof the agent-ori- ¯ Counter--senderrefuses to accept the petition,
ented programming paradigm [Shoham, 1990].
but respondswith an alternative. It is up to the
Fromour work, we concluded which characteristics
petitioner to consider the altemative offer.
youcan abstract and incorporateat the generic agent
[Shoham, 1990] and [Thomaset al., 1991] do not
level. Separating out generic characteristics prouse
counters, but [Bowersand Churcher, 1988] invides a powerful frameworkfrom which to create
clude
themin the protocol description. It wasnecagents. Wepresent the following views of these
essary
to add counters to facilitate negotiation
commoncharacteristics:
between
agents. [Georgeet al., 1993] gives further
¯ External view--how agents communicate
details on the protocol and differences from previ¯ Structure--what agents are composedof
ous work.
¯ Dynamics--howagents behave over time
The protocol and architecture allow agents to par¯ Properties--constraints on agent behavior
ticipate in multiple transactions at the sametime
with
different agents. Thearchitecture does not al2.4.1 External View of Agents
low embeddedtransactions; an agent cannot petiWehave modeledthe agent-to-agent protocol on a tion another agent while involvedin a transaction as
small numberof generic speech acts that you can petitioner with that sameagent. This restriction did
extend and specialize for particular domains. The not appear to be a problem. It was both convenient
fundamental unit of agent-to-agent communica- and useful to support parallel transactions; two
agents can participate in twotransactions with each
tion is a transaction. Transactions are sequential
as petitioner (see Figure 2).
sets of messagesthat elicit cooperationor transfer
knowledge between agents. Transactions always Thearchitecture also supports maintainingan entire
terminate with either an accept or reject message.
transcript of the transaction; this is useful duringthe
transaction to keeptrack of whosaid what. ThetranThe KAoSarchitecture includes mechanisms for
script along with a numeric counter for ’counter’
controlling communicationsbetween agents, stormessages helps avoid unproductive or repetitive
ing the context of transactions, and avoidingrepetmessages (and provides some guarantee that the
itive and unproductive communication between transaction will eventually terminate).
agents. Webased the design of the transaction protocol on petitions and responses. Petitions are entreaties madefrom one agent to another. Generic
petitions consist of:
¯ Inform--sender asks receiver to update the
receiver’s knowledge
26
agenta J --,,
I
agentd
Birth
1
Life
( agentb
agentc
Ipetitioner
Genetic
agente )
Update
Structure }’~
agent f )
Fulfill
Desires
"-- responder
Figure 2. Multiple and Parallel Transactions.
2.4.2 Agent Structure
The KAoSarchitecture and genetic agent class
provide a consistent structure for agents; this
includes mechanismsfor storing, updating, and
inheriting: knowledge,commitments,choices, and
capabilities. Figure 3 showsthese structures.
Knowledge
is a collection of facts and beliefs. Facts
are simply beliefs in which the agent has complete
confidence. Commitments
are obligations the agent
has made.Choices are simply obligations the agent
has madeto itself. Capabilities are an exportedlist
of those services or functions that an agent can provide.
" barge
q[Commitments)
¯ Knowledge
¯ Facts
¯ Beliefs
¯ Commitments
¯ Choices
¯ Capabilities
Figure 3. Structure and Dynamicsof Agents.
Someapplications mayrequire agent death to free
resources or simply deal with agents that are no
longer useful. Agentdeath poses special problems.
Dependingon the application, it maybe necessary
to include domain-specific procedures for dealing
with agent death. Thesemayinclude notification of
other agents, transfer of any pendingcommitments,
Our original design included similar mechanisms or transfer of knowledge.
for agent desires. Weconcludedthat desires tend to
be so domain-specific
that there is little valuein cre- 2.4.4 Agent Properties
ating generic structures and mechanismsfor them. There are several general properties the KAoS
However,we found it easy to programagents with architecture provides [Shoham,1990]:
domain-specificdesires using the structure already ¯
Internal consistency--agents should have no
provided by knowledge, commitments, capabiliconflicts in their mental state. Updates to an
ties, and choices. Thecurrent design provides mechagent’s mental state can only occur through
anisms for inheriting desires within the agent
mechanismsthe architecture provides. These
hierarchy.
mechanisms include consistency checks to
2.4.3 Agent Dynamics
assure each agent’s mental state is consistent
withitself.
Because agents are autonomous entities,
each
¯
Rationality--agents should attempt to fulfill
agent goes through birth, life, and typically death.
their desires. The overall control structure
At birth, agents are instantiated with specific
shown
in Figure 3 provides this property.
innate knowledgeand capabilities. During their
° Good faith--agents
should only commit to
lives, agents go through a continuous cycle of
things
that
they
are
capable
of and intend to
reading messages(communicating),fulfilling their
carry out. Because each agent has a published
desires, and discharging any commitmentsdue at
list of capabilities, the agent will not accept
the current time. Agents mayacquire additional
anyrequests that it can not carry out.
knowledgeand capabilities as they interact with ¯ Introspection--agents should be aware of their
other agents and their environment.
ownmental state. KAoSprovides each agent
27
with full access to its ownmentalstate. It can
only obtain information about another agent’s
mentalstate through a request.
Persistence of mental state--agents should not
change their mental state randomly. Updateto
an agent’s mental state can only occur through
mechanismsthe architecture provides (e.g.,
inform messages, inference).
2.5 Domain-specific Agents
The Domain-specific Agent layer allows users of
KAoS
to create specialized agents. As part of our initial application, we implementedseveral domainspecific agents. Oneparticularly useful class of
agents developedwas the service broker.
As part of a follow-on effort called agONy!,we are
currently reimplementing NetMANIAC
and the
MessageServer to take advantageof the capabilities
of Distributed Smalltalk. Alongwith the Berkeley
Sockets mechanism,we will support Apple Events,
DDE,PPC, and eventually OpenDocand OLE2.0,
so that data and services from Macintoshand Windowsapplications are available to KAoS.
Theadoptionof an open standard for object interoperability as the foundation for KAoSwill makeit
easier for us to port subsets of the KAoS
architecture
to other CORBA-compliant
programmingenvironments and applications.
3.2 Authoring and Run-time Interfaces
Service broker agents function to mediate between In the original version of KAoS,you could develop
and monitor agents only through Smalltalk browsclient agents and external resources and services.
Weprovidedtwo additional layers of abstraction be- ers and rudimentaryrun-time interfaces. In our current work, we are applying principles from
tweenthe service broker and the actual application.
The service broker handedrequests to a resource knowledge acquisition, end-user authoring, and
programming-by-demonstrationresearch to develmanagerwhohandled particular kinds of services
op and evaluate more adequate tools [Bradshaw
(e.g., database applications). Resourcemanagers
turn forwarded requests to an application manager etal., 1993b], [Cypher, 1993], [Erickson, 1991],
[Laurel, 1990], [Nardi, 1993], [Orenet al., 1990],
whocontrolled a specific application (e.g., Oracle).
[Spohreret al., 1991].
3
CurrentDirections
In this work, weare interested in knowinghowthe
use of agents affects the wayweperceiveand use the
While the original design of KAoSwas sufficient
system. Users approachinterfaces with a host of exfor testing a numberof basic concepts,wedid not inpectations and assumptions,based on their previous
tend it to be a robust and completeimplementation experience
with computersand the specific presenof an agent-oriented programming
and run-time entation of the system. Metaphorsconsistent with the
vironment. The requirements of our medical and everyday
experienceof users can speed their learnaerospace performance support applications have
ing
of
computing
conventions. For example, the
motivated extensions in three main areas:
desktop
metaphor
takes
advantage of users’ previ1. Incorporation
of the OMGCommonObject
ous
knowledge
that
office
artifacts are visible, are
Request Broker Architecture (CORBA).
passive,
have
locations,
and
maycontain things. On2. Agentauthoring and run-time interfaces.
tological
knowledge
of
a
different
sort comesinto
3. Learning and adaptive mechanisms.
play whenyou employthe agent metaphor [Erickson, 1991]. For example, users assumethat agents
3.1 Incorporation of CORBA
can hide, can initiate things, can go places, and can
Since the time of the first KAoSimplementation, makechoices and commitments.They mayalso asHewlett-Packard has produced a Smalltalk-80 imsumeless tangible qualities like that they can know
plementation of the OMGCommon
Object Request things, can have goals and intentions, they are inBroker Architecture (CORBA)
called "Distributed
ternally consistent, rational, act in goodfaith, caninSmaUtalk."This environmentallows transparent actrospect, can cooperate to achieve common
goals,
cess to objects and methodsnot only amongdifferand that their mentalstate persists.
ent Smalltalk environments, but also amongthe
As we develop authoring and run-time tools for
growing number of CORBA-compliantapplicait is importantto evaluatetheir effectiveness
tions. Distributed Smalltalk uses a Berkeleysockets agents,
from
the
end-user’s point of view.
mechanismthat ParcPlace Systems implements for
Unix, Macintosh, and Microsoft Windowsenvironments.
28
3.3 Learning and Adaptive Mechanisms
Individual and collective agent knowledgeis represented as networked"blocks." The block represenIn complexdynamicenvironments, it is very diffitation permits agents to interactively acquire
cult to anticipate situations or contexts that agents knowledge
about relationships between pieces of
will encounter. Thus, these environmentsmust perrelevant
information
and the problem context. A
form knowledgeacquisition of situation patterns
symbolic
learning
method
elements of the
and appropriate behavior online and incrementally analytical knowledgeintotransfers
situation patterns, and
as agentsperformtasks in the real world. Weare pro- subsequently assists with knowledgebase restrucviding a framework
for the acquisition of situational
turing. Mostof the learning mechanisms
workin the
knowledgeby reimplementingand refining the Sit- .background,
requiring minimal overhead effort by
uation Recognition and Analytical Reasoning
Theresult over time is a set of agentsthat have
(SRAR)model and its associated "block" knowl- users.
learned by experiencehowto adapt to particular usedge representation [Boy, 1991], [Boy and Math6, ers and situation patterns.
1993]. The SRARmodel was originally developed
in 1986as part of a project to aid astronauts in diConclusions
agnosing faults in the orbital refueling system of 4
NASA’s
space shuttle. It has subsequentlybeen ap- Thereis every reason to expect that future applicaplied at NASA-Ames
to develop a suite of Comput- tions will needto intelligently anticipate, adapt, and
er-Integrated Documentation (CID) applications
actively seek waysto support users. Amixof object[Boy, 1992]. Workingin collaboration with reoriented and agent-oriented programming parasearchers at NASA-Ames,
wewill integrate selectdigmsappears to be a fruitful area of future applied CIDcontextual learning mechanismsinto the
cation and research. Based on our experience, an
KAoSarchitecture to assess their value in perforarchitecture for programmingagents by inheriting
mancesupport applications.
from more general and generic agents appears to
provide manybenefits. Further workbeing carried
The SRARmodel provides a formal frameworkfor
out in the context of current applications will prointegrating situational (problem-statement situavide feedbackon the extensibility and generality of
tional patterns) and analytical (problem-solvingrethe architecture.
sources) knowledge(Figure 4). In the beginning,
intelligent systemsare "inexperienced"and mustrely on broad analytic knowledge. Learning mecha- References
nisms in such systems rely on the reinforcement of
successful actions, the discovery of failure condi- [Billings, 1991]C. E. Billings. Human-centered
tions, and the generation of recoveryactions to imAircraft Automation: A Concept and Guideprove performance. Elements of the analytical
lines. NASATechnical Memorandum103885,
knowledgeare transferred into situation patterns.
August 1991.
Overtime, situational patterns multiply and become
[Bowers and Churcher, 1988]J. Bowers and J.
more complex, while analytical knowledge beChurcher. Local and global structuring of comcomesmorestructured.
puter-mediated representation: DevelopinglinSituation
Pattems
Beginner
guistic perspectives on CSCWin Cosmos.
Proceedings of the Conference on Computersupported Cooperative Work, Portland, OR.
[Boy, 1991]G.A. Boy. Intelligent Assistant Systems. AcademicPress, London,England.
[Boy, 1992] G.A. Boy. Computerintegrated documentation.In E. Barrett (ed.), Sociomedia:Multimedia,
Hypermedia, and the Social
Construction of Knowledge, pages 507-531,
MITPress, Cambridge, MA.
[Boyand Hollnagel, 1993] G. A. Boyand E. Hollnagel. Cockpit Evolution and Human-centered
Automation. European Institute of Cognitive
Sciences and Engineering (EURISCO),September 1993.
Analytical
Knowledge
Gr3
GT3
-~
al
)
-~
an
)
Expert
(
sn
)-
Figure 4. The SRARModel.
29
[Boy and Math6,1993] G. A. Boy and N. Math6.
Operator assistant systems: An experimental
approachusing a telerobotics application. In K.
M. Ford and J. M. Bradshaw(eds.), Knowledge
Acquisition as Modeling, pages 271-286.
Wiley, NewYork, NY.
[Bradshawetal.,1993a]J.
M. Bradshaw, C. R.
Chapman,K. M. Sullivan, J. H. Boose, R. G.
Almond,D. Madigan, D. Zarley, J. Gavrin, J.
Nims, and N. Bush. KS-3000: Applying
DDUCKS
to bone-marrow transplant patient
support. Proceedings of the Seventh European
Knowledge Acquisition for Knowledge-based
Systems Workshop (EKAW-93),Toulouse and
Caylus, France, July 1993.
[Bradshawetal.,1993b]J.
M. Bradshaw, K. M.
Ford, J. R. Adams-Webber,and J. H. Boose.
Beyondthe repertory grid: Newapproaches to
constructivist knowledgeacquisition tool development. In K. M. Ford and J. M. Bradshaw
(eds.), KnowledgeAcquisition as Modeling,
pages 287-333, Wiley, NewYork, NY.
[Bradshawet al., 1993c]J. M. Bradshaw,T. Richards, P. Fairweather, C. Buchanan,R. Guay, D.
Madigan, and G. A. Boy. Newdirections for
computer-based training and performance support in aerospace. Proceedings of the Fourth
International Conference on Human-Machine
Interaction and Artificial Intelligence in Aerospace, Toulouse, France, 28-30 September
1993.
[Brodie, 1989]M. L. Brodie. Future intelligent
information systems: AI and database technologies workingtogether. In J. Mylopoulosand M.
L. Brodie(eds.), Readingsin Artificial Intelligence and Databases, pages 623-642. Morgan
Kaufmann,San Mateo, CA.
[Cypher, 1993] A. Cypher (ed.). WatchWhatI Do:
Programming by Demonstration. MIT Press,
Cambridge, MA.
[Dennett, 1987]D. C. Dennett. The Intentional
Stance. MITPress, Cambridge, MA.
[Erickson, 1991]T. Erickson. Design Issues for
Enhanced Interfaces: Models and Metaphors.
Apple Computer Human Interface
Group,
Cupertino, CA,26 November1991 (draft).
[Georgeetal., 1993]N. J. George,R. J. Jasper, M.
R. LaFever, K. M. Morrison, D. B. Rosenthal,
and S. R. Tockey. KAoSagent-to-agent protocol
description. In KAoS: KnowledgeAgent-oriented System, Volume4, Seattle University,
Seattle, WA.
3O
[Kaehler and Patterson, 1986]T. Kaehler and D.
Patterson. A small taste of Smalltalk. BYTE,
pages 145-159,August 1986.
[Laurel, 1990]B. Laurel. Interface agents: Metaphors with character. In B. Laurel (ed.), TheArt
of Human-ComputerInterface Design, pages
355-366. Addison-Wesley, Reading, MA.
[Nardi, 1993] B. A. Nardi. A Small Matter of Programming: Perspectives on End User Computing. MITPress, Cambridge, MA.
[Orenet al., 1990]T. Oren, G. Salomon,K. Kreitman, and A. Don. Guides: Characterizing the
interface. In B. Laurel (ed.), The Art of HumanComputer Interface Design, pages 367-382.
Addison-Wesley, Reading, MA.
[Sharp, 1993] M. Sharp. Reactive Agents. Technical
Report. Apple Computer,Cupertino, CA.
[Shoham, 1990] Y. Shoham. Agent-oriented programming.Artificial Intelligence, (60) 1:51-92,
March 1993.
[Spohrer et al., 1991] J. C. Spohrer, D. Vronay,and
R. Kleiman. Authoring intelligent multimedia
applications: Finding familiar representations
for expressing knowledge. Proceedings of the
1991 IEEE International Conference on Systems, Man,and Cybernetics, pages 1751-1756,
Charlottesville, VA,13-16 October, 1991.
[Thomaset al.,1991]B. Thomas, Y. Shoham, A.
Schwartz, and S. Kraus. Preliminary thoughts
on an agent description language. International
Journal of Intelligent Systems, 6(5):497-508,
August 1991.