The internal architecture may become increasingly important for large multiagent systems deployed in networked environments, as the level of intelligence required of individual agents increases. Cognitively rich internal mechanisms and structures are necessary to model complex communications and plan with (and between) agents. Sloman and Logan proposed three architectures to describe different agent systems [9].

The first internal architecture is purely reactive, where the detection of internal or external conditions immediately generates new internal or external responses, which in turn could trigger new reactions. The internal and external feedback loops and changes of state that alter a reactive agent’s responses to new sensory inputs can combine to achieve quite sophisticated behaviors. This architecture is simple and fast.

A deliberative architecture archives a greater flexibility by allowing sets of possible actions to be assembled and evaluated without necessarily being selected for execution. This architecture requires a large amount of stored knowledge about which actions are possible and relevant in various circumstances and what the effects of various actions are in those circumstances. Reusable short term memory is also needed for building structures representing possible action sequences in order to evaluate their consequences. A deliberative system is much slower than a reactive one. Such a deliberative architecture might be used to cope with the tasks achieving new types of goals or acting in novel contexts.

An additional reflective architectural layer with the ability to monitor, evaluate, and possibly modify internal processes of various kinds may be beneficial when realistic multiagent systems have to take account of internal within-agent conflicts as well as between-agent conflicts and negotiations. This additional layer could be based on a mixture of internal reactive and deliberative processes.

Communication between agents is a crucial point for agent technology. Most agents need to communicate with other agents in order to achieve their goals. Because agents often reside in a distributed and open environment, it is hard to make them communicate and share knowledge. Considering the importance of the Internet as a world wide distributed environment, Internet-based agents will become more and more popular. Communication problems about Internet-based agents are first discussed. Then the agent communication language is discussed.

The ability for flexible interaction and interoperation with other similar software agents is very important to an agent. For software agents to interact and interoperate effectively requires three fundamental components: (i) a common language; (ii) a common understanding of the knowledge exchanged; and (iii) the ability to exchange whatever is included in (i) and (ii). This language should support and facilitate common behaviors of agents.

KQML or the Knowledge Query and Manipulation Language is a language and protocol for exchanging information and knowledge [1]. It is part of a larger effort, the ARPA Knowledge Sharing Effort (http://www.cs.umbc.edu/kse/) which is aimed at developing techniques and methodology for building large-scale, sharable, and reusable knowledge bases. KQML is both a message format and a message-handling protocol to support run-time knowledge sharing among agents. KQML can be used as a language for an application program to interact with an intelligent system or for intelligent systems to share knowledge in support of cooperative problem solving.

The KQML language focuses on an extensible set of performatives defining the permissible operations that agents may attempt on each other's knowledge and goal stores. The performatives comprise a substrate on which to develop higher-level models of inter-agent interactions such as contract nets and negotiation. In addition, KQML provides a basic architecture for knowledge sharing through a special class of agent called communication facilitators which coordinate the interactions of other agents. Current research status of KQML can be found in UMBC KQML Web (http://www.cs.umbc.edu/kqml/).

After the draft of KQML was published in 1993, KQML has become a de facto standard of agent communication language. This does not mean that the definition of KQML is complete and diligent, but implies that a common language is needed for agents to communicate. However, because KQML is not very complete, several implementations and variations also exist in practice. These variations impede the application of KQML. After the FIPA ACL (http://www.fipa.org) has been released in October 1997, it is rapidly spreading to replace KQML as the ACL of choice [6].

Both KQML and ACL are interlingua languages, intended to provide a common linguistic basis for independent agents to communicate with each other. Both languages are based on speech act theory, which states that individual communications can be reduced to one of a small number of primitive speech, or more generally, communicative acts, which shape the basic meaning of that communication [2].

There are several needs in inter-agent communication which are querying and information passing, managing multiple responses to queries, managing capability definition and dissemenation, and managing communications. KQML attempts to define a core set of performatives that together meet all of these needs, while balancing a desire for parsimony in the language. ACL does not attempt to cover all of these needs within the language. Instead, some categories are explicitly devolved to the agent management system (see part 1 of the FIPA 97 specification, http://www.fipa.org) or are the responsibility of the content language.

FIFA 98 specified an agent ontology service on agent communication (FIPA 98, Part 12, http://www.fipa.org). FIFA 99 proposed new communicative acts (CAs) and new interaction protocols, enhanced the FIPA agent communication framework with mechanisms to facilitate developing a variety of mediated multiagent systems, and clarified the use of common content languages in a wide range of applications [3].

The mobile agent is a kind of agent which can migrate from one place to another when needed. It can reduce network traffic for applications processing large quantities of data. It can overcome network latency. Mobile agents also provide some autonomy, because they themselves can decide dynamically where and when to travel to a particular node to perform some required work. Mobile agents also give the user a natural mode of asynchronous interaction. The user can send the agent to a remote host and disconnect the network as desired. The autonomy and asynchronous nature of mobile agents is also especially effective in protecting mission-critical applications from failure caused by unreliable networks.

Java is a suitable language to support mobile agents. A generic Java-based mobile agent architecture is proposed in [10]. It consists of six major components. The agent manager sends agents to remote hosts and receives agents for execution on the local host. The security manager protects the host and the mobile agents against unauthorized access. The reliability manager ensures the robustness of the mobile agent system. The interagent communications manager facilitates communication between mobile agents dispersed throughout a network. The directory manager can be used to identify the location of an application server. And the application gateway serves as a secure entry point through which agents can interact with application servers (such as legacy databases).

The design, implementation, and debugging of mobile agents is much more difficult than agents without mobility. On the other hand, most tasks of mobile agents can be implemented by non-mobile agents. For example, an agent can access a remote host directly instead of send itself to the host. Therefore, a designer should be quite careful before he/she decide to use mobile agents.

The autonomy of agents in e-commerce systems is a mixed blessing – it must be managed to avoid the possible chaos. The main basis for managing autonomy lies in the notion of commitments. A flexible formulation of commitments can provide a natural means through which autonomous agents may voluntarily constrain their behaviors. This approach can achieve a coherent state in the ongoing interactions of the participating components. This not only facilitates automation, but is also more intuitive and closer to some aspects of human social behaviors [6].

A commitment is a relationship between a debtor, a creditor, a context, and a proposition. The debtor owes it to the creditor to make the proposition true; the context serves as a witness and as the adjudicator of disputes. A sphere of commitment (SoCom) is viewed conceptually as a scope within which a commitment applies. The operations on commitments (create, discharge, cancel, delegate, assign, release) are typically governed by metacommitments. The set of applicable metacommitments effectively defines the structure of a multiagent system.

Spheres of commitment can be applied naturally in the SMART project (http://smart.npo.org/), which is run by the National Industrial Information Infrastructures Protocols (NIIIP) consortium (http://www.niiip.org/).

Because HTML is not semantically encoded, software agents and search engines have difficulties in accessing the online information and services. The CommerceNet’s eCo system (http://www.commerce.net) tried to develop an XML Framework to solve this problem. Extensible markup language (XML) can encode information and services with meaningful structure and semantics that agents can readily understand. Publishing XML-encoded documents, such as data sheets, price lists and orders, can make the buyers compare products across many vendors and catalog formats, and sellers publish their catalog information once to reach many potential buyers.

XML’s power derives from its extensibility and ubiquity. Business Interface Definitions (BIDs) which include business document definitions are XML extensions defined by the eCo System [5]. The Common Business Library (CBL) is an extensible, public collection of generic BIDs and document templates that companies can customize and assemble to go online quickly. The basic CBL elements can be used to implement the basic business forms used in X12 EDI transactions, as well as those in OTP, OBI, and other emerging Internet standards.

Some XML-based specifications for the business information have been developed, including Open Trading Protocol (OTP, http://www.otp.org), RosettaNet (http://www.rosettanet.org), XML/EDI (http://www.xmledi.com), Open Buying on the Internet (http://www.openbuy.org), Information and Content Exchange (http://www.w3.org/TR/1998/NOTE-ice-19981026), and Open Financial Exchange (http://www.ofx.net).