Open Agent Architecture (OAA) v2.x FAQ


1. OAA Background Information

1.1 What is the Open Agent Architecture?

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.

1.2 What is an agent?

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.

1.3 What is the OAA good for?

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:

For a more complete list of OAA-based applications, see the "applications" section of the OAA Homepage.

1.4 What is the difference between distributed agents and distributed objects?

In our opinion, at least two characteristics distinguish distributed agents from distributed objects:
  1. 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.
  2. 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.

1.5 How does OAA compare with other distributed technologies, such as CORBA, JINI, KQML, E"SPEAK, Blackboards, publish & subscribe frameworks?

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:
  1. 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.
  2. 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.
  3. 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.
  4. 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.

2. OAA Architecture & Components

2.1 What does the Facilitator agent do?

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:
  1. Maintaining a registry of agent service and data declarations.
  2. Planning an execution strategy for a given query.
  3. Executing the plan: breaking tasks into subtasks, matching subtasks to service providers, and routing and collecting information among the distributed participants.

2.2 Is the Facilitator domain specific or domain independent?

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.

2.3 Is the Facilitator a bottleneck?

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.

2.4 How do agents communicate?

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.

2.5 What are triggers?

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:

  1. Task triggers: watches agent-supplied conditions, such as "when email arrives about XXX, notify me."
  2. Comm(unication) triggers: looks for specific low-level agent-communication events, such as "when an agent-disconnect event is sent, record time."
  3. 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."
  4. Time triggers: time-based events, such as "Every thursday at 2pm from now until christmas, send me a meeting reminder."

2.6 What support agents are provided as builtin agents in the OAA? Can they be used for any application?

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:

3. Developing OAA Systems

3.1 What computer languages can I write OAA agents in?

In OAA 1.0, agent libraries and tools exist to create agents in the following programming languages: OAA 2.x currently supports four languages: Prolog, C, Java and WebL.

3.2 How hard is it to add a new agent to the OAA?

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) :-

start :-
   com_Connect(parent, ConnectionInfo),
   oaa_Register(parent, tts, C),

3.3 What are the basic steps of creating a new agent?

To create a new agent, an agent developer usually performs the following tasks.
  1. Specify what services an agent can provide and what services an agent needs, expressed in the syntax of the Interagent Communication Language (ICL).
  2. Write the code for the agent, implementing the capabilities declared solvable by the agent.
  3. 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.
  4. Add vocabulary for the agent to the appropriate service agents such as Nuance Speech Recognition or Gemini Natural Language agents.
  5. 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.

4. Status

4.1 Will OAA be commercialized? Public Domain?

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.

4.2 What systems have been built using OAA?

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.

4.3 What is OAA's future directions and ultimate goal? How far is it from here?

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.