The buyer toolkit only has one component---buyer agent. The toolkit provides end users a quick way to configure their buyer agents and to deploy them on the network. Since there are many different transaction scenarios, flexibility is provided by allowing users to generate buyer agents with different behavioral characteristics.

The function of a buyer agent is to search for product information and to perform {\em fairly routine\/} goods or services acquisition. When it receives a purchase request from a user, it engages a directory agent to locate the corresponding seller agents. Each purchase request consists of several parameters supplied by the user. Examples of such parameters include:

Category of goods Generic names as `car', `CD', `TV', etc., may be specified as good categories since end users may not know specific details before they preview the goods available from the shops. With this category information, a buyer agent prompts the user for search criteria so as to find the specific item to be purchased. This is similar to the kind of questions posed by shopkeepers when customers are not sure about their buying needs.

Using `CD' as an example, a user may be asked to specify attributes such as `type', `album', `language', `artist', and so on. Here, we assume that every category of goods comes with some standard set of attributes and they are supplied by a directory agent (Section 5). Besides specifying desired values for each attribute, the user may also provide weightage (from $0$ to $1.0$) for each attribute. For instance, an attribute with weightage $1.0$ is a mandatory attribute while another one with $0$ can be ignored. When multiple goods satisfy the search criteria, the buyer agent displays the list of qualified goods (including their attributes and prices) to the user. The user may then choose from the list those items to be purchased.

Acceptable price range and desired price The user is required to provide an acceptable price range and the most desired price within that range. Price information is used in strategies adopted by the buyer agent to decide which seller agent to purchase from. If no item is within the range of acceptable price, the buying transaction will be reported as unsuccessful.

Purchasing strategy When multiple seller agents have the same item within the acceptable price range, a choice will be made using a strategy specified by the end user. Here are the strategy options for the user to choose:

• Lowest To buy the one with the lowest price.
• Highest To buy the one with the highest price (some consumers believe that the higher is the price, the better is the goods).
• Medium To buy the one with the medium price (some consumers may feel cheated when the price is too low or too high, they prefer the average price).
• Nearest To buy the one whose price is the nearest to the desired price specified by the user. If the user does not specify the most desired price, then he is only required to choose from the first three strategies.

Quantity The user should also specify the quantity of the goods he wants to buy.

Final decision option The buyer agent supports both `automatic' and `manual' as decision options when a final purchase decision is to be made between the buyer agent and the chosen seller agent. A manual final decision option implies that the buyer agent has to inform the user when the buyer agent has completed the price negotiation and has chosen a seller agent. The user reserves the right to accept or reject the purchase option proposed by the buyer agent. If the user wants the buyer agent to make automatic purchase decision, an automatic final decision option should be given. In this case, the buyer agent will complete the transaction without notifying the user.

Figure 3: Structure of a buyer toolkit.

In our system, the end user of a buyer agent (or a seller agent) monitors the status of transactions through the options provided by the agents. Any transaction can be terminated by the user when necessary.

An interesting feature of our buyer agents is that they are able to learn from experience. By keeping the attributes of goods and the records of past transactions (including the user's requirements of previous transactions), it is easier and faster for buyer agents to buy the same goods that have been purchased before. A buyer agent directly displays the last description of the similar buying task as the default one, and allows the user to modify it. Figure 3 shows the inner structure of a buyer agent. The components include:

User interface A human user interacts with the buyer agent via a user interface module. In the beginning of a transaction, the user supplies all necessary information such as those specified in the above buyer agent example (earlier in this section). The user interface allows users to control and monitor the progress of transactions, and to query past transactions.

Transaction manager Upon the initiation of a transaction, a transaction manager is responsible for getting the input from the user interface and deriving the complete plan for carrying out the transaction. Sometimes, the plan of a transaction consists of a simple task that purchases one good. However, for a complex transaction, a plan may involve a set of tasks related by some inter-task dependencies. For example, a trip arrangement transaction can be broken up into multiple tasks to book and pay for flights, and/or to book and pay for hotels. Depending on user preference and the goods to be purchased, the transaction manager may have to schedule these tasks appropriately. The plan for a transaction can be generated with reference from a plan library.

Task processor Each task in a transaction plan is evaluated by a task processor. To quickly locate a seller agent, the task processor accesses a transaction record database which records past transactions and tasks. At any point during the task evaluation, the task processor updates the transaction manager of the task status. The completed task information is also recorded in the transaction record database. The transaction processor further informs the user about the transaction status via the user interface.

Communication module As in the case of a seller agent, a communication module is required to forward/receive messages to/from seller and directory agents.