Open Agent Architecture (OAA) v2.x FAQ
Contents
The Open Agent Architecture is a framework in which a community of
software agents running on distributed machines can work together on
tasks assigned by human or non-human participants in the community.
Distributed cooperation and high-level communication are two ideas
central to the foundation of the OAA.
In the Open Agent Architecture, an agent is defined as being software
which conforms to the communication and functional standards imposed by
the OAA. In order for multiple agents to be able to cooperate,
OAA agents can delegate and receive work requests through a Faciliator agent.
These requests are expressed in an Interagent
Communication Language common to a all agents. In addition, agents
possess a common set of functionalities, such as the ability to install
local or remote triggers.
The OAA is useful for building complex systems in which there are many
heterogeneous components, and in which flexibility and extensibility is
important.
It is certainly true that if you have a frozen system, this system could be
built without using an agent architecture; however, if you want a system
that is adaptable, and can easily be extended (incrementally),
delegation-based agent architectures offer a new paradigm of solutions.
At SRI, we are using the OAA as a way of integrating both commercial (or legacy)
systems with artificial intelligence technologies, such as planning, speech
recognition, natural language, etc.
The ability for humans to be able to communicate easily and naturally with
the community of agents is an important design requirement of the OAA.
OAA has been used to implement more than 30 systems/prototypes where
a community of agents provide services to humans. Two early examples were:
- Multimodal Maps:
The Open Agent Architecture is being used to implement
synergistic multimodal interfaces to distributed data sources.
- Automated Office:
Control your office from remote locations -- agents
provide access and monitoring of your calendar, email, or database
applications over the telephone, a laptop, or PDA.
For a more complete list of OAA-based applications, see the
"applications" section of the
OAA Homepage.
In our opinion, at least two characteristics distinguish distributed agents from distributed objects:
- Whereas programs accessing distributed objects must use low-level remote procedure call or method
invokation, agent communication takes place at a higher-level declarative level. The language used by
the agents to communicate must be powerful enough to describe natural language requests, so that humans
can communicate easily with other agents.
- Whereas distributed objects are generally passive sets of data and library routines, distributed agents
can ideally participate actively in a process. Agents may have their own goals and may reason about the
interactions of other agents, proactively providing information when appropriate. In addition, agents
can receive or make requests to install triggers or monitors of various kinds, keeping track of events
for another agent or human peer.
OAA's claim-to-fame is it's use of a "delegated computing" model,
where the control for how components interact with each other is
the result of a cooperative process among at least four processes:
- The requester can choose to partially specify how a goal
should be accomplished by the community in a rich tasking language.
Control parameters not explicitly stated by the requesting agent will
be filled in by other members of the community.
- Service providers, during the registration process with
a Facilitator agent, can specify test-condition code and performance
estimation values which will both impact how and under what
circumstances the agent receives work.
- The Facilitator agent possesses domain-independent
routing strategies for parcelling out work to the agent community
based on an incoming request and service providers' capabilities
descriptions.
- Collections of meta-agents (domain experts) can
collaborate to provide the Facilitator with domain-specific knowledge
that guides how tasks are performed by the overall community.
For a more detailed comparison between OAA and the other distributed
frameworks cited by this question, see the OAA Technical
Whitepaper.
A Facilitator is an agent whose capabilities (solvables) involve
distributing and coordinating tasks among a number of client agents.
A Facilitator can be thought of performing three functions:
- Maintaining a registry of agent service and data declarations.
- Planning an execution strategy for a given query.
- Executing the plan: breaking tasks into subtasks, matching subtasks
to service providers, and routing and collecting information among
the distributed participants.
Domain independent -- the same Facilitator can be used for all
applications (although different Facilitators may exist, providing varying
levels of sophistication in interagent management).
The Facilitator possesses a number of services and domain independant
strategies for coordinating distributed processing. Domain-specific
knowledge can be encoded in subordinate meta-agents or mediator
agents, which apply whatever "intelligence" they possess (e.g. neural
networks, learning, planning, rules) to help the Facilitator make key
decisions.
In its most simple form, where one Facilitator serves a number of
client agents, the Facilitator is both a communication bottleneck
and a single point of failure for the entire system. However,
we believe that through careful engineering, the openness and
flexibility captured by the OAA can be preserved while skirting
these problems. See the OAA presentation slide on
scalability
for ideas about how this might be accomplished.
All inter-agent communication is expressed using an OAA-specific
language called, originally enough, the Interagent Communication
Language (ICL). For OAA's ICL, we chose a logic-based language
similar to Prolog, because for our research purposes, it was important
that the language the agents speak could represent and easily
translate back and forth to human (or natural) language.
Perhaps the most important characteristic of the ICL is that it
separates out the what from the how. Control
parameters specifying how the task should be routed, who should
perform the task, and so forth, are optional and separate from the
task description itself.
Triggers in OAA (sometimes called "monitors" or "watchdogs") allow
agents to persistently keep track of different types of events in
the real world (or agent community) and then take some action if a
condition becomes true. OAA triggers are delegated in a
similar manner to how tasks or data are routed through the agent
community.
In OAA, there are four types of triggers identified:
- Task triggers: watches agent-supplied conditions, such
as "when email arrives about XXX, notify me."
- Comm(unication) triggers: looks for specific low-level
agent-communication events, such as "when an agent-disconnect event is
sent, record time."
- Data triggers: keeps track of changes to information
stored using the OAA data management facilities, such as "when the
telephone status becomes 'free', notify me."
- Time triggers: time-based events, such as "Every
thursday at 2pm from now until christmas, send me a meeting reminder."
The one agent that is used in every agent application is the Facilitator agent.
In addition, a growing number of support agents exist that are domain
independent and can be useful as participants in a given application domain.
Examples of such include:
- Natural Language Parsing Agent (three currently exist, which varying
characteristics and functionality)
- Speech Recognition Agent
- Natural language generation
- Text-To-Speech Agent
- Database Agent
- Phone Agent (to permit mobile access to speech recognition from
remote locations)
- Start-It: an agent responsible for executing and monitoring a
community of agents.
- Monitor: graphically displays and records an agent community and
their communications.
- Debug: A generic user interface that lets a programmer send
messages to the agent community using either ICL or natural language.
In OAA 1.0, agent libraries and tools exist to create agents in the
following programming languages:
- Prolog
- C
- C++
- Perl
- Lisp
- Microsoft Visual Basic
- Borland Delphi
- Sun's JAVA
- Compaq's Web Language (hereinafter abbreviated to WebL, its former name)
OAA 2.x currently supports four languages: Prolog, C, Java and
WebL.
A new agent can be created in a few minutes to a few days or longer,
depending on how easy it is to access the API of the functional core of the
system an agent is interfacing with.
This assumes the programmer is familiar with OAA programming concepts and
functionality.
The basic template of an agent is very small. Here is a fully
functional agent written in Prolog:
:- [com_tcp]. % load communications library of choice
:- [oaa]. % load OAA agent library
% define capabilities
capabilities([solvable(play(tts,Msg), [callback(tts_events)],[])]).
% for each capability, define the code to execute it.
tts_events(play(tts,Msg),Params) :-
tts_api(Msg).
start :-
capabilities(C),
com_Connect(parent, ConnectionInfo),
oaa_Register(parent, tts, C),
oaa_MainLoop(true).
To create a new agent, an agent developer usually performs the following
tasks.
- Specify what services an agent can provide and what services an
agent needs, expressed in the syntax of the Interagent Communication Language (ICL).
- Write the code for the agent, implementing the capabilities declared
solvable by the agent.
- Document the agent's functionalities, usually in Internet-readable
form so as to provide easy access to the documentation through
Web browsers and Internet search tools.
- Add vocabulary for the agent to the appropriate service agents such
as Nuance Speech Recognition or Gemini Natural Language agents.
- Include the agent as a community member for agent-based systems
which might make use of its services.
See the OAA tutorial for a more in
depth discussion about how to create an OAA agent.
Version OAA 2.x is released under a version of a
community license, enabling the community to use, distribute and
extend OAA for non-commercial purposes. See the license for details.
As for commercialization, SRI has thought about creating an "OAA-Pro",
a more commercial-quality instantiation of OAA's ideas, but we are not
making an announcement at this time.
The OAA has been used to implement more than 30 different systems where
distributed agents provide flexible services to humans. See the
OAA Homepage's Application list for descriptions
of some of these projects.
A. The current directions of the OAA group has been focused on bringing
together advanced computer technologies that have currently existed only
in isolation, and through the combination of these technologies, making
computers smarter, easier and friendlier for use for the average human being.
Our future directions will continue along this path, towards this ultimate
goal, according to priorities set by our clients.
B. We believe that many interesting technologies have already been integrated
into the OAA framework, and there are still many yet to incorporate.
In addition, a number of systems
have been built to demonstrate the capacities of these technologies.
However, it is clear that improvements in technology will continue for
many years and we hope that the OAA will continue to be part of
this development.