In this document, we present AgentBuilder, an integrated toolkit for constructing intelligent software agents developed by Acronymics, Inc. This toolkit utilizes a high-level, agent-oriented programming language called Runtime Agent Definition Language (RADL); programming is accomplished by specifying intuitive concepts such as beliefs, commitments and actions.
We discuss the architecture of AgentBuilder, which is based on the agent programming languages called Agent-0 from Shoham for constructing cognitive agents and PLACA from Thomas for constructing agents with the notion of planning. An overview of an agents execution cycles and the agent interpreter is given. An overview of the AgentBuilder environment is presented and some tools are highlighted that are essential for building up an intelligent agent application. We also present a summary of some AgenBuilder based applications and compare AgentBuilder with Zeus.
With the growth of technology, different organizations want to integrate their information systems with those of their suppliers and customers. As more complex tasks are delegated to the software such as developing complex enterprise applications, they require powerful new methods and techniques for conceptualizing and implementing such software system. Agent-Oriented based languages can be used to solve complex problems. However, solving these problems with the help of intelligent agents requires lot of knowledge of various domains like knowledge representation, inferencing, network communication methods and protocols, etc. Some applications might also require expertise in machine learning and machine planning technology.
There is also need of tools to formalize and describe concepts, relations and objects relevant to a particular domain and to specify the behavior of the agent(s) operating in that domain. Also, different tools are required to specify collection of agents, analyze and specify the messages and message protocols between agents, and execute and evaluate the actions of the agents. AgentBuilder provides all of these capabilities.
AgenBuilder defines a new agent programming language called Runtime Agent Definition language (RADL), which is based on the concepts like belief, capabilities, commitments, behavioral rules and intentions. AgentBuilder consists of two major components: the run-time execution environment and the development tools. The run-time system provides a high-performance agent engine that executes these agent programs. The development tools are used for analyzing an agent’s problem domain and for creating an agent program that specifies agent behavior.
Agents constructed using AgentBuilder communicate using the Knowledge Query and Manipulation Language (KQML) and supports the performatives defined for KQML. In addition AgentBuilder allows the developer to define new inter-agent communications commands that suit his particular needs.
The AgentBuilder toolkit and the run-time engine are implemented using the Java programming language. Agents created with AgentBuilder are themselves Java programs and will execute on any platform with a Java virtual machine.
In section 2 we describe how AgentBuilder is related with other agent oriented programming languages. The architecture of the agent execution in AgentBuilder is explored in section 3. Section 4 presents an overview of the development tools of AgentBuilder. A comparison with Zeus (one of the agent based toolkit) is done in section 5. Different applications developed in AgentBuilder are investigated in section 6. Finally section 7 ends with conclusion.
Shoham presented two primitives for defining an agent’s mental model, which are belief and commitment. Beliefs are the facts that an agent knows or learns from the environment and have complete faith about them and follows them until there is a contradiction. On the other hand, commitment is treated as a decision to act rather that a decision to pursue a goal.
In his agent programming language Agent 0, Shoham describes two action types, namely private actions and communicative actions. Private actions of an agent are the necessary steps which an agent needs to accomplish its tasks, for example executing SQL queries on a database. Communicative actions are mechanism for exchanging messages with other agents.
Agents in Agent-0 are governed by an agent program. Typically an agent program consists of some initial beliefs, initial commitments, the capabilities of an agent and the commitment rules. Initial beliefs and initial commitments are presented in the mental state of an agent at the startup. Capabilities are the actions that an agent can perform and are fixed for the lifetime of the agent. Commitment rules determine the actions performed and the mental changes of the agent in all situations. In general, the agents defined in Agent-O can receive messages, send messages, perform private actions and update their own mental model.
Thomas extended the work of Shoham by developing PLAnning Communicative Agents (PLACA) that is an agent programming language very similar to Agent-O but adds the notion of planning for agents.
The architecture of the AgentBuilder is based on the concepts given in Agent-0 by Shoham in developing cognitive (i.e. mental model) based agents and the agent programming language PLAnning Communicating Agents (PLACA) by Thomas. AgentBuilder further refines the work of Shoham and Thomas to build an agent-oriented programming language. This object-oriented language is called the Runtime Agent Definition Language (RADL). AgentBuilder provides graphical tools for creating RADL programs that execute in AgentBuilder’s run-time system. The following paragraphs describe the run-time language and agent architecture in more detail.
Perhaps the most important part of an agent’s mental model is its beliefs. Beliefs represent the current state of the agent’s internal and external world and are updated as new information about the world is received. An agent can have beliefs about the world, beliefs of other agent’s beliefs, beliefs about the interaction with its environment and beliefs about its own beliefs. In AgentBuilder mental model integrity is improved by having types for belief instances and pattern variables, so the agent’s inference engine can ensure that comparisons between mental model elements are always valid. Furthermore runtime efficiency is also improved by having belief templates allowing the agent’s inference engine to focus its search when looking for beliefs that match specified conditions. In most situations only one, or at most, a small set of beliefs need to be examined.
A capability is a construct that is used by an agent to associate an action with that action’s necessary preconditions. The action can only be performed once these preconditions are satisfied. Capabilities are static and remain fixed till the lifetime of the agent. Actions can change depending on the change in an agent’s beliefs because beliefs can alter the truth value of precondition patterns in the capability. For example, the capability for making queries on a database is defined as the precondition of the agent’s belief that the database is online. Once this precondition is meet only then an agent can take its actions.
AgentBuilder defines two main categories of actions, private actions and communicative actions, as did Shoham. Private actions are the actions taken by an agent during an interaction with its environment and communicative actions are those taken by sending messages to other agents. Capabilities are further used to adopt a commitment; an agent will not adopt a commitment to perform an action when it can never perform that action.
Commitment is an agreement, that an agent makes with another agent to perform a particular action at a particular time. For example, agent A wants to make query to a particular database during a particular time of the day, than A sends a commitment request in a message to another agent B. Agent B can accept or reject that request based on its behavioral rules and current mental models (beliefs, other commitments, etc). On accepting a request agent B makes a commitment of querying the database at that particular time. It should be noted that commitment is not a guarantee that an action will be performed; it’s just an attempt of trying to perform that action at that particular time provided that all the necessary preconditions are meet.
Once the specified time and current time is meet, based on its capability agent B will then test the necessary preconditions like the availability of the database. To test the preconditions, B must match the precondition patterns against its current beliefs. If all the patterns evaluate to true, B can initiate execution of the committed action otherwise it cannot. In general an agent cannot be sure that execution of the action is successful because there are tasks beyond the control of the agent, like a disk could crash during the database access. To cope with such conditions, agent B monitors the execution so that it should be able to send a message back to agent A reporting a success or failure of the commitment.
Behavioral rule in AgentBuilder is an extension of the idea of commitment rule described by Shoham and is used to represent a more general Behavioral rule. Behavior rules determine the course of action an agent takes at every point throughout the agent’s execution. If a rule’s conditions are satisfied by the environment, then the rule is applicable and the actions it specifies are performed.
Basically, a behavioral rule is a set of WHEN-IF-THEN statements. The WHEN portion of the rule addresses new events occurring in the agent’s environment and include new messages received from other agents. The IF portion compares the current mental model with the conditions that are required for the rule to be applicable. Patterns in the IF portion match against beliefs, commitments, capabilities and intentions. The THEN portion defines the agent’s actions and mental changes performed in response to the current event, mental model, and external environment. These may include:
• Mental model update
• Communicative actions
• Private actions
A behavioral rule is allowed to have any combination of the possible actions and mental changes outlined above.
The following listing describes the format for the behavioral rules.
NAME rule name
WHEN
Message Condition (s)
IF
Mental Condition (s)
THEN
Private Action (s)
Mental Change (s)
Message Action (s)
The above listing specifies that a behavior rule with any NAME can only be executed WHEN the conditions of the massage are matched and IF the mental conditions are true at that time THEN only the actions can be taken.
An intention is an agreement, usually committed to another agent, to achieve a particular state of the world at a particular time. Intensions are similar to commitments but the difference is that a commitment is an agreement to perform one action whereas Intention is an agreement to perform whatever actions needed to achieve a particular state of the world. The agent performing the actions has a better understanding of its own area of expertise within the problem domain and may be able to skip unneeded actions, redo action when necessary, find alternate actions that will achieve the goal, etc.
In order to achieve the goal specified by an intention, the agent must be able to construct plans to achieve the goal, monitor the success of the actions performed, and construct alternate plans if the original plan fails. Thus, support for processing intentions requires an additional level of sophistication and capability in the agent.
Having discussed the basic concepts such as Beliefs, capabilities, commitments, behavioral rules and intentions that are used in the architecture of AgentBuilder, we now proceed with the agent interpreter that is responsible for the execution of an agent program.
Figure 1 illustrates the AgentBuilder intelligent agent architecture. In this architecture an interpreter continually monitors the incoming messages, updates the agent’s mental model and takes appropriate actions.
At start-up, an agent is initialized with initial beliefs, initial commitments, initial intentions, capabilities, and behavioral rules. A non-trivial agent requires at least one behavioral rule; the other elements are optional. For example, if an agent has no initial commitments then the agent is not initially committed to do anything (for itself or anyone else). The same logic applies to initial beliefs and initial intentions. If the capabilities list is empty the agent will not be able to perform any actions.
The mental model contains the current beliefs, commitments, intentions, capabilities, rules of the agent. Although rules and capabilities are static, the agent’s beliefs, commitments, and intentions are dynamic and can change over the agent’s lifetime.
The agent execution cycle consists of the following steps:
• Process new messages
• Determining which rules are applicable to the current situation
• Executing the actions specified by these rules
• Updating the mental model in accordance with these rules
• Planning
Building software agents in AgentBuilder does not require the knowledge of the general theory of Intelligent Agents. While in other toolkits it is essential that the software developer must understand the basic concepts of intelligent agents in order to design an agent based application. Furthermore, AgentBuilder allows automatic creation of Agent Code from a set of objects and attributes defined in the analysis phase of a software project. AgentBuilder uses an accumulator paradigm for accumulating complex patterns and expressions from its different tools and builds mental condition rules for the agent. Some naming conventions are also posed by the environment but they are not obligatory, for example, %name for binding KQML messages, ?name for binding objects in the agents mental model and $name for temporary variables. AgentBuilder gives a mechanism for the agents to interact with their environment with the help of Package Accessory Classes (PACs).
Agents constructed with AgentBuilder can use a combination of built-in Java classes (supplied by the AgentBuilder toolkit) and domain-specific Java classes provided by the developer. All of these classes used by the AgentBuilder agents are referred to as Project Accessory Classes (PACs) .The AgentBuilder toolkit provides a basic suite of commonly used PACs, such as kqmlMessage PAC used in agent communications.
Most projects will utilize domain-specific PACs to perform action specific to the problem domain or to represent domain concept. PACs can be written entirely in Java, or can be written in C/C++ and invoked via the Java Native Interface (JNI). PACs can perform any computation that can be performed using Java, C or C++. Furthermore, PAC objects can be enclosed inside kqmlMessage objects and sent between agents, allowing agents to reason and communicate with complex objects.
A number of PACs are available that software developers can use to extend the functionality of their agents. Currently available PACs include:
• Email
• HTTP Interface
• FTP
• USENET News Interface
AgentBuilder has been used in various applications from building e-commerce based agents to the distributed controlling and monitoring multi-agent systems. Agents are particularly useful in distributed applications involving peer-to-peer processes.
For instance, Smart*DER, developed by the personnel of Acronymics, Inc, is a complex AgentBuilder application for distributed control and monitoring of energy resources. It federates different multiple agents where each agent can have its own goals, objectives, cost and profit objectives. Further, these agents can work together to form markets with agents buying and selling electric power and changing their role of buyer or seller as their electric power requirement change. A network of intelligent agents has been implemented that provides a powerful problem-solving mechanism that is ideally suited for use in the electric power industry.
Other useful AgentBuilder based applications include,
1. P-Mail, A Private Email System
2. Intelligent Agents for Buying and Selling Electric Power in Dynamic Auctions
3. Shopping Agents
4. Custom Agent Applications, like searching the internet, finding resumes, retrieving and analyzing documents, etc
AgentBuilder is considered one of the complete platforms for building agent oriented applications. Comparatively, Zeus is one of the toolkits that provide ease of building software agents. Both of these environments have plenty of documentation available. These tools offer many graphical interfaces for help in quick development. Additionally, both of the tools provide utilities for “debugging”. However, both of the tools are very complex with their implementations and models which increase the learning curve of the users. In the case of AgentBuilder some knowledge is required for understanding the details of a RADL program, management of ontologies, execution engine, protocols used and different interfaces of the environment. The learning of Zeus is also very long because of the need of understanding the modeling techniques like “Role Modeling” which is always essential in order to build useful agents. There is also a need of understanding different editors that provide many services more or less sophisticated, for example, ontologies, tasks, resources, rules, protocols for interaction, system visualization, etc.
Both of the platforms provide useful interfaces to hide their complex implementations but they both lack some difficulties at the level of flexibility and extensibility. The learning curve of both of the platforms is also quite long.
In this document, we presented AgentBuilder, a toolkit based on an agent programming language called Runtime Agent Definition Language (RADL) having the features like beliefs, capabilities, commitments, behavioral rules and intentions. We gave an overview of the architecture of AgentBuilder particularly focusing the runtime execution environment of the agents. We also presented an introduction of some of the development tools available in AgentBuilder for creating RADL programs that execute in AgentBuilder’s run-time system.
Complex applications can be created very easily in AgentBuilder compared with other existing toolkits. However, building agents may not require any theoretical knowledge but the use of toolkit requires some knowledge to use its graphical editors more effectively. Once the user becomes used to of the toolkit then the use of development tools will make the development tasks much easier.
AgentBuilder R.M., An Integrated Toolkit for Constructing Intelligent Software Agents, AgentBuilder, Reference Manual, April 2000.
AgentBuilder R.M., An Integrated Toolkit for Constructing Intelligent Software Agents, AgentBuilder, User’s Guide, April 2000.
Lee L. C., Ndumu D. T., Nwana H. S., ZEUS: An Advances Tool-Kit for Engineering Distributed Multi-Agent Systems. In Proceedings of the Practical Application of Intelligent Agents and Multi-Agent Systems, p. 377-392, London 1998.
Sebas A., Delisle S., Badri M. A Comparative Analysis of Multi-Agent System Development Methodologies: Towards a Unified Approach, Third International Symposium “From Agent Theory to Agent Implmentation” (AT2AI-3), Sixteenth European Meeting on Cybernetics and System Research, Vienna (Austria), 2-5 April 2002, Volume 2, 599-604.
Shoham, Y. Agent-Oriented Programming, Artificial Intelligence, Vol. 60, No.1, p. 51-92. March 1993.
Thomas, S. PLACA, an Agent Oriented Programming Language, Ph.D. Thesis, Computer Science Department, Stanford University. 1993.
Tony G, Sylvain D., Programmation orientée agent: évaluation comparative d’outils et environnements, Université de Québec à Trois-Rivières, Canada. 2002.
http://www.agentbuilder.com
http://www.acronymics.com
http://www.labs.bt.com/projects/agents/zeus/