Here is a full report on "What kinds of languages can agents use to communicate?". Multi-Agent System (MAS) is composed of multiple heterogeneous intelligent software systems called agents. Agents need an Agent Communication Language (ACL) in order to interact in a shared language, hiding the details of their internals and to build communities of agents that can tackle problems that no individual agent can.

1. Abbottabad University of Science & Technology
Report on Multi-agent System Issue
Submitted By: Ahsan Rahim (1838)

2. What kinds of languages can agents use to
communicate?
ulti-Agent System (MAS) is composed of multiple heterogeneous intelligent software
systems called agents. Agents need an Agent Communication Language (ACL) in
order to interact in a shared language, hiding the details of their internals and to build
communities of agents that can tackle problems that no individual agent can.
Introduction:
As a Multi-Agent System (MAS) is composed of multiple heterogeneous intelligent software
systems (called agents) which can compete, negotiate or cooperate. In recent years the interest in
MAS has grown tremendously and today agent technology is being used in a large range of
industrial applications. Agent technology is widely used to help users to achieve various tasks in
diverse domains such as network management, air-traffic control, telecommunications, and
electronic commerce.
Communication is considered as a negotiation game where agents negotiate about proposed
communicational states. An agent proposes a communicational state and other agents react to the
proposal by accepting, rejecting the proposed communicational states or even asking for further
information. Such an action establishes a relationship between the communicational states and
the agent that is called an agent's positioning.
Agent technology is widely used to help users to achieve various tasks in diverse domains such
as network management, air-traffic control, telecommunications, and electronic commerce.
Agent applications have one thing in common: agents must be able to communicate in order to
decide which actions to perform. In a multi-agent system, we distinguish two levels of
communication: agent/user communication and agent/agent communication. In both kinds of
communication, industry is trying to find a standard communication language. To assist
developers in the use of agent technology, some multi-agent system tools have been developed.
However, these tools are still suffering from the following drawbacks:
 There is no standard architecture for Multi-Agent Systems
 There is no standard design method for the design of a Multi-Agent System
 There are no standard communication protocol agents /users.
Agents suggest a paradigm for software development which emphasizes autonomy (both at
design time and run time), adaptivity (change is everywhere) and cooperativity (humans agents
do it all the time, so should the software ones, too). This approach seems appealing in a world of
distributed, heterogeneous systems. Languages for communicating agents promise to play the
role that language played for their human counterparts.
M

3. The Communication Model:
When interacting, agents can engage in two kinds of communication:
i. Agent/user communication
ii. Inter-agent communication
Agents communicate with users in order to characterize their needs and to provide them with
answers or solutions. Agents communicate with each other in order to exchange various kinds of
information. When communicating with other agents, an agent uses a specific Agent
Communication Language (ACL). An ACL provides agents with a means to exchange
information and knowledge. At the technical level, when using an ACL, agents transport
messages over the network using some lower-level protocol (SMTP, TCP/IP, IIOP, HTTP, etc.).
The ACL itself defines the types of messages (and their meaning) that agents may exchange.
Agents though, do not just engage in single message exchanges but they have conversations, i.e.
task-oriented, shared sequences of messages that they follow, such as a negotiation or an auction.
At the same time, some higher-level conceptualization of the agent's strategies and behaviors
drives the agent's communicative (and non-communicative) behavior.
An agent's architecture contains a communication process which handles communication
activities as well as other processes used to perform various tasks such as planning, decision
making or negotiation.
Agent Communication Protocols
There are a variety of interprocess information exchange protocols. In the simplest, one agent
acts as a client and sends a query to another agent acting as a server and then waits for a reply ,
as is shown between agents. The server's reply might consist of a single answer or a collection or
set of answers. In another common case, shown between agents A and C, the server's reply is not
the complete answer but a handle which allows the client to ask for the components of the reply ,
one at a time. A common example of this exchange occurs when a client queries a relational
database or a reasoner which produces a sequence of instantiations in response. Although this
exchange requires that the server maintain some internal state, the individual transactions are as
before.

4. Basic concepts of an Agent Communication Language
An ACL provides agents with a means to exchange information and knowledge; Genesereth has
gone as far as equating agency with the ability of a system to exchange knowledge using an
ACL. Of course other means and pproaches have been used over the years to achieve the lofty
goal of seamless exchange of information and knowledge between applications. From Remote
Procedure Call (RPC) or Remote Method Invocation (RMI), to CORBA and Object Request
Brokers (ORB's) the goal has been the same. What distinguishes ACLs from past such efforts are
the objects of discourse and their semantic complexity. ACLs like KQML or FIPA ACL, stand a
level above CORBA, because: (1) they handle propositions, rules and actions instead of simple
objects (with no semantics associated with them), and (2) the ACL message describe a desired
state in a declarative language, rather than a procedure or method. But ACLs by no mean cover
the entire spectrum of what applications may want to exchange. More complex objects can and
should be exchanged between agents, such as shared plans and goals, or even shared experiences
and long-term strategies.
At the technical level, when using an ACL, agents transport messages over the network using
some lower-level protocol (SMTP, TCP/IP, IIOP, HTTP, etc.). The ACL itself defines the types
of messages (and their meaning) that agents may exchange. Agents though, do not just engage in
single message exchanges but they have conversations, i.e. task-oriented, shared sequences of
messages that they follow, such as a negotiation or an auction. At the same time, some higher-
level conceptualization of the agent's strategies and behaviors drives the agent's communicative
(and non-communicative) behavior. Traditionally, we understand the message types of ACLs
as speech acts, which in turn are usually accounted for in terms of beliefs, desires, intentions and
similar modalities. This kind of intentional-level description can either be just a useful way to
view a system or it can have a concrete computational aspect. The latter case describes a large
range of BDI3 agents which have some (implicit or explicit) representation of the corresponding
modalities.
This representation is built on top of a substrate that describes the conceptual model of
knowledge, goals and commitments of an agents, commonly known as a BDI theory. Despite the
criticism that BDI theories and BDI agents have faced, such as the number and choice of
modalities and the fact that multimodal BDI logics have neither complete axiomatizations nor
they are efficiently computable, they offer an appealing framework to account for agent
communications, because agents, when communicating, they communicate their BDI states and
attempt to alter their interlocutors BDI states.

5. Basic concepts of ACL
The Knowledge Sharing Effort initiated circa 1990 by the Defense Advanced Research Projects
Agency of the US Department of Defense, enjoyed the participation of dozens of researchers
from both academia and industry. Its goal was to develop techniques, methodologies, and
software tools for knowledge sharing and reuse at design, implementation, or execution time.
The central concept of the KSE was that knowledge sharing requires communication, which in
turn requires a common language; the effort focused on defining that common language. In the
KSE model, software systems are virtual knowledge bases that exchange propositions using a
language that expresses various complex attitudes. The proper term is propositional attitudes.
An ACL provides agents with a means of exchanging information and knowledge; Michael R.
Genesereth has gone as far to equate agency with the ability of a system to exchange knowledge
using an ACL.3 Of course, other means have been used to achieve the lofty goal of seamless
exchange of information and knowledge between applications. From remote procedure call and
remote method invocation (RPC and RMI) to CORBA and object request brokers, the goal has
been the same. What distinguishes ACLs from such past efforts are the objects of discourse and
their semantic complexity. ACLs stand a level above CORBA for two reasons:
• ACLs handle propositions, rules, and actions instead of simple objects with no semantics
associated with them.
• An ACL message describes a desired state in a declarative language, rather than a procedure or
method.
But ACLs by no means cover the entire spectrum of what applications might want to exchange.
Agents can and should exchange more complex objects, such as shared plans and goals, or even
shared experiences and long-term strategies.
The KQML Language
Communication takes place on several levels. The content of the message is only a part of the
communication. Being able to locate and engage the attention of someone you want to
communicate with is a part of the process. Packaging your message in a way which makes your
purpose in communicating clear is another. When using KQML, a software agent transmits
content messages, composed in a language of its own choice, wrapped inside of a KQML
message. The content message can be expressed in any representation language and written in
either ASCI I strings or one of many binary notations (e.g. net work indep endent XDR
representations). All KQML implementations ignore the content portion of the message except to
the exten t that they need to recognize where it b egins and ends.
The syntax of KQML is based on a balanced parenthesis list. The initial element of the list is the
performative and the remaining elements are the performative's arguments as value pairs.
Because the language is relatively simple, the actual syntax is not signicant and can be changed

6. if necessary in the future. The syntax reveals the roots of the initial implementations, which were
done in Common Lisp, but has turned out to be quite exible.
KQML is expected to be supported by an software substrate which makes it possible for agents
to locate one another in a distributed environment. Most current implementations come with
custom environments of this typ e, these are commonly based on helper programs called routers
or facilitators. These environments are not a specied part of KQML. They are not standardized
and most of the current KQML environments will evolve to use some of the emerging
commercial frameworks, such as OMG's CORBA or Microsoft's OLE2, as they become more
widely used. The KQML language supports these implementations by allowing the KQML
messages to carry information.
CG-KQLM+ : an extension of KQML:
CG-KQLM is a first attempt to provide a standardized Agent Communication Language (ACL)
came forth from the ARPA knowledge sharing project and produced KQML. In the context of
that project, researchers developed two main components:
i. a representation language used to express message contents.
ii. a communication language KQML (Knowledge Query Manipulation Language).
KQML has been designed to facilitate high level cooperation and interoperation among agents.
KQML offers an extensible set of so-called performatives which specify what kind of
communication actions agents can perform. KQML performatives are either assertive (used to
state a fact) or directives (used to give orders or send requests). A typical KQML message has
the following syntax:
(tell
: sender A

7. : receiver B
: content "raining”)
KQML and ACL Concepts:
KQML (knowledge query and manipulation language) illustrates the basic concepts of existing
ACLs. KQML is a high-level, message-oriented communication language and protocol for
information exchange independent of content syntax. So, KQML is independent of the transport
mechanism (TCP/IP, SMTP, IIOP, etc.), independent of the content language (KIF, SQL, STEP,
Prolog, etc.) and independent of the ontology assumed by the content.
The KQML language is divided into three layers: the content layer, the message layer, and the
communication layer. The content layer bears the actual content of the message; in the programs
own representation language. KQML can carry any representation language, including languages
expressed as ASCII strings and those expressed using a binary notation.
Every KQML implementation ignores the content portion of the message, except to determine
where it ends. The communication level encodes a set of features to the message which describe
the lower level communication parameters, such as the identity of the sender and recipient, and a
unique identifier associated with the communication. It is the message layer that is used to
encode a message that one application would like to transmit to another.
The message layer forms the core of the KQML language, and determines the kinds of
interactions one can have with a KQML-speaking agent. The primary function of the message
layer is to identify the network protocol to be used to deliver the message and to supply a speech
act or performative which the sender attaches to the content (such as that it is an assertion, a
query, a command, or any of a set of known performative).
KQML Routers
Routers are content independent message routers. Each KQML speaking software agent is
associated with its own separate router process. All routers are identical each is just an executing
copy of the same program. A router handles all KQML messages going to and from itsassociated
agent.
Because each program has anassociated router process, it is not necessary to make extensive
changes to each program's internal organization to allow it to asynchronously receive messages
from a variety of independent sources. The router provides this service for the agent and provides
the agent with a single point of contact for the rest of the network. It provides both client and
server functions for the application and manages multiple simultaneous connections with other

8. agents. The router nev er lo oks at the content elds of the messages it handles. It relies on the
KQML performatives.
Conclusion
The concept of a standard communication language for software agents that is based on speech
acts has found wide appeal, both among researchers interested in working out the theory of agent
communication as well as those with the aim of engineering practical software systems. Many
researchers believe that the development of an effective, rich ACL is one of the keys to the agent
paradigm.
The KQML language was among the first such ACL to be developed and used. Moreover, is the
only one which has enjoyed substantial use by more than its developers to date. However, after
eight years of experimentation and experience there are still serious signs of immaturity. In
general, different KQML implementations can not interoperate; (2) there is no fixed specification
sanctioned by some consensus-creating body; and (3) there is no agreed-upon semantics
foundation. Is the KQML experiment a failure? We think not. KQML has played a large role in
defining what an Agent Communication Language is and what the issues are when it comes to
integrating communication into agent systems. Although existing KQML implementations tend
not to interoperate, this is mainly due to a lack of a real motivation to do so. Agent-based
systems research is still at an early stage of development, and there has been no benefit to
individual research groups in focusing on the interoperability issues. Although the lack of a
sanctioned specification has probably impeded the adoption of KQML for many big projects, it
has had the benefit of allowing much experimentation with dialects and variations on the theme.
We hope that the current FIPA effort will supply the needed sanctioning body for the next
iteration of a KQML-like language. Finally, the semantics issue is in practice much less
important than it sounds as long as the problem of defining and identifying conformance to the
semantics, is not resolved. But given the possibility that it might be impossible to find a
satisfactory solution to the latter problem, we will be left with a justifiable sense of
disappointment, as computer scientists, for a language that lacks formal, verifiable semantics.