STEAM: A Shell for TEAMwork

Release 1.0

Milind Tambe

STEAM is a general model of teamwork, intended to enable agents to participate in coherent teamwork. It has so far been applied in three different complex multi-agent domains. Two of the domains involve building teams of pilot agents for distributed interactive simulation environments: (i) synthetic helicopter attack, (ii) synthetic helicopter transports. A third domain is building a team of virtual players for RoboCup simulated soccer. While synthetic pilot-teams based on STEAM are currently participating in the STOW-97 exercises (virtual battlefield exercises involving thousands of virtual and real entities), our player-team based on STEAM won the third place in the RoboCup-97 synthetic soccer tournament held at IJCAI-97 in Nagoya, Japan.

STEAM can facilitate development of agent teams, and you may find it useful in your application. If agents adopt certain representational conventions for states and operators, STEAM will facilitate their participation in teamwork. For an overview of STEAM's capabilities, please see the publications listed below all available here. The first paper is particularly relevant.

[1]   Tambe, M.
      Agent architectures for flexible, practical teamwork.
      In Proceedings of the National Conference on Artificial Intelligence
         (AAAI).  August, 1997. 

[2] Tambe, M. Teamwork in real-world, dynamic environments. In Proceedings of the International Conference on Multi-agent Systems (ICMAS). December, 1996.

[3] Tambe, M. Tracking dynamic team activity. In Proceedings of the National Conference on Artificial Intelligence (AAAI). August, 1996. (This paper is does not directly related to STEAM, but to team tracking; nonetheless, it is a useful reference.)

STEAM is currently based in Soar. A key component of STEAM is the notion of a "team operator", which generalizes the use of operators in Soar. In particular, while operators are used by individuals to engage in individual activities, team operators are those performed by multiple team members together, as a team --- of course, without a physically shared memory. Team operators are based on the joint intentions framework (Cohen and Levesque, 1991, Smith and Cohen, 1996); please read the references above for pointers and other details. Team operators are distinguished from normal individual operators, because they are tagged as modeling a team activity, and because they activate the rules in the package listed below. However, individual operators are also within STEAM scope, at least to the extent that they bear upon team activities. Thus, STEAM's rules can apply to team operators, as well as individual operators. (Simultaneously, it is possible to circumvent STEAM if you must, since there are areas where STEAM falls short in modeling teamwork).

By no means is STEAM an end-point of an investigation of teamwork. Instead, I hope this turns out to be a collaborative future effort -- I volunteer to maintain code for different styles of teamwork. In the following, I will assume that readers have gone through the papers listed above (all of these are fairly short papers), and/or are quite familiar with the basic concepts used.

The documentation provided here may not be sufficient for you to run a new application. Please do let me know, and I can add further documentation depending on your need.


The following set of files contains rules written in Soar that make up the STEAM package. Anyone using team-operators will be able to make use of STEAM rules. The rules use Soar7, and they depend on some representational conventions (to be described below), for encoding domain knowledge. The total number of rules here is close to 253 (please see note at the end of this page). However, several issues must be noted. First, IT IS NOT NECESSARY TO LOAD ALL OF THE RULES. For instance, you may decide to load only a certain set of rules say for establishing and terminating team activities, and none of the rules involved in repair. Indeed, it is possibly a good strategy to first load just a few sections of STEAM and then extend your coverage. Second, due to the expressivess of the rule language, certain rule types have to be repeated --- bloating the number of rules. That is, once you understand the rule type, it is easy to see the repeating pattern.

First, here is a tar file for STEAM rules. Once you download this file, you will need to run the following to untar the file:

		tar xvf filename.tar
There are two types of rules here: (i) General rules, to be used in your application without any change, and (ii) Domain-specific rules, not to be used in your application, but these may provide guidance as to how to write up some of the domain-specific rules required for reasoning in STEAM. The domain-specific files are loaded via load-domain-specific.soar; you should ensure that these are not loaded in your application. (Just a handful of domain-specific rules may have unfortunately crept into the general rules, but it should be possible to delete those).

The following are brief descriptions of the general rules. Once you untar the tar file, you should see the following files, that contain the general rules. The domain-specific rules are contained in two directories that contain the name "*domain-specific".

Team formation follows the request-confirm protocol. The relevant rules are in the following four files, and in the directory "establish-jpg" (jpg stands for joint persistent goal). Gamma stands for the "gamma" used in the AAAI97 paper listed above. Within the establish-jpg directory, we have files for sender and receiver. Functional-models-for-jpg file is the unachievability condition when an agent fails in establishing a jpg.

# forming a team

The operators fired in a subgoal for establish-jpg are to be loaded from the directory "establish-jpg" which contains the following files. The sender is the team-leader, responsible for establishing team goals, and the receivers are the other members of the team.



Trace of you will see in agents' behaviors as a result of these rules is listed below. "Execute-mission" is the team operator being performed by an agent team of type company (enclosed in ()). In your application, you may have other team operators. For the sender, you will see something like this:

    61:    O: O36 execute-mission (company)
    62:    ==>S: S18 (operator no-change)
    63:       O: O65 establish-jpg (vehicle)
    64:       ==>S: S19 (operator no-change)
    65:          O: O67 sender (vehicle)
Establish commit to: execute-mission
    66:          O: O68 sender-obtains-commitments (vehicle)
    67:          ==>S: S20 (operator no-change)
Established JPG 

For the receiver, you will see something like this:

    61:    O: O36 execute-mission (company)
    62:    ==>S: S18 (operator no-change)
    63:       O: O65 establish-jpg (vehicle)
    64:       ==>S: S19 (operator no-change)
    65:          O: O67 receiver (vehicle)
    66:          ==>S: S20 (operator no-change)
    67:             O: O68 wait 
    68:          O: O69 receiver-confirms (vehicle)
    69:          ==>S: S21 (operator no-change)
Established commitment to: execute-mission

The following files are used in deciding whether operators are achieved, unachievable or irrelevant. The unachievability file is the most interesting here, since it reasons about failures that arise if individuals in a team fail to fulfill responsibilities. The conditions for achieved, unachievable and irrelevant operator status are divided into three categories: "actual", "derived", and "indirect". These three categories had to be created, since agents must not only terminate operators, but need to communicate about them. To reduce the amount of communication, derived and indirect categories were created, so that agents can refer to objects associated with their team operators, e.g., they can can say "scouted current battle-position", where current implies the one referenced in their team operator; without necessarily having to specify the shape and size of the battle position to uniquely identify it in other ways. More about this in the representational-conventions section below.

# reason about unachievability

The following files are used to enable agents to communicate upon termination of a team operator. "Tau" stands for the "tau" in the AAAI97 paper listed above. So the first file estimates tau for terminating the current jpg (the joint-persistent-goal, which is at the heart of a joint intention) to be terminated. The next file uses the equation of cost-benefit analysis of communication based on tau. The next file ("create-communicative-goals") actually creates a communicative goal in the agent's memory. The file "communicative-private-beliefs.soar" finally broadcasts the message to the team indicated in the communicative goal. As a result of communication, or because the information is assumed to be common knowledge, the next file (assume-common-knowledge) updates the team state or mutual beliefs.

# communications to terminate a team operator

The above files should lead to a communication operator being installed. The type of messages that can be generated a result of these rules are listed below. The first message below is generated by an agent named "cheetah421", and it asks for the current jpg (the joint-persistent-goal, which is at the heart of a joint intention) to be terminated. The joint intention to be terminated is "fly-flight-plan". There is also a cause for why such a termination occurs: because the agents are to evade an enemy tank seen at location 54000 33000 to the right. The message type is "constant" -- this type information is required for the interpretation of the message.

In general, it should be possible to provide a natural language gloss for such messages, but we havent done that so far.

 (i)  cheetah421 terminate-jpg constant fly-flight-plan evade tank 54000 33000 right 

 (ii)  cheetah425 terminate-jpg derived wait-while-bp-scouted scouted battle-position 54641 33700 

Communication occurs as follows:

Step 1: the rules in file create-communicative-goals are used to match
an agent's private state (beliefs) with any of the team operator's
termination conditions -- i.e., conditions that would make the team
operator achieved, unachievable or irrelevant. These communicative
goals are only possible as communicative goals at this juncture.

Step 2. the rules in file terminate-jpg-estimate-tau are used
to estimate the likelihood that the given communicative goals
are actually common knowledge in the team. The likelihood is
specified as high, low or medium.

Step 3. the rules in file elaborate-communicative-goals are used
to match the specified likelihoods with the communication costs
to check if communication is possible

Step 4. If communication is possible, rules in communicate-private-beliefs
are used to actually communicate the relevant information to others
in the team.

Step 5. Due to communication, or high likelihood that relevant
information is mutually believed, agents assume that certain
knowledge is now mutually believed.

Just as we have standard set of rules for communication we have also included rules for accepting information from others. These messages all relate to the termination of a team operator, caused by the rules in the files above. Messages are expected to arrive in particular formats, which is what the accept-message takes advantage of. message-elaborations.soar is used to extract the right elaborations from the message -- note that this aspect is not covered by the theory, and it is not described in the papers. convert-names-to-internal-objects.soar is used because agents communicate names of other agents (they obviously cannot send each other any internal symbols representing different agents); hence after communication, these names are converted by a receiving agent to internal symbols.

# accepting messages

Repair team operator is entered if an operator is found unachievable, either a team operator or an individual operator. Since repair is itself cast as a team operator, "functional-models-for-repair" lists the achievement conditions for the repair. Repair other role is invoked if there are non-critical roles, that need to be repaired.

# repair operators

Files for repair are to be loaded from the directory "repair-team-op", which contains the following files. In this set, team-formation-failure.soar addresses errors in team-formation (in establish-jpg). Other files handle failures when individuals are found unable to perform their roles.


Given specification of role dependency (see the representational conventions listed below), the following install appropriate role-dependency links. Furthermore, when an agent is unable to perform its role, propagate-non-performance is used to understand its implications in the overall organization.

# role hierarchy

This following is related not directly to the termination of a team activity, but rather to an individual's non-performance and hence its threat to the team activity. The agent then communicates this inability to perform role to others.

# role non-performance messages

Complete failure is invoked if there is no repair available. Complete failure leads to "actions-on-complete-failure", which is in the directory "domain-knowledge".

# complete-failure if repair impossible

The following two are not discussed in the above papers. The role-performance-enquiry comes up when an agent is unable to perform its role, but it is also unable to communicate that it cannot perform own role. Others must thus query it as to its status in performing assigned role.

# other communication not strictly covered in the theory

An agent only declares that certain message be conveyed via a certain communication method. The following types of files get used to implement this communication method. Not exactly a general file, this should actually be moved to domain-specific parts.

# implementing communication methods
cd "implement-communication-methods"
cd ".."

Search control among the various teamwork operators

# search control

Whether a team contains subteams.

# subteams

Representational Conventions

Postscript file of representational conventions adopted.

*******STEAM Communication examples with explanations********

The following communication is from the Attack domain mentioned in the papers above. It involves a company of synthetic attack helicopter pilot agents performing their mission in a synthetic battlefield. The pilot team begins this mission after the initial mission briefing. There are five members in this company, cheetah421, cheetah422, cheetah423, cheetah424, and cheetah425. Cheetah421 is the commander.

1. The first set of messages relates to the IFOR commander ensuring that all members of the company are ready and committed to begin executing the specified mission. To achieve this, the company commander (cheetah421) first broadcasts a radio message to its company asking that all members of the company:

cheetah421: "commit to executing their current mission".

Each member of the company responds in turn, announcing that they are: "committed to executing mission"

This means the remaining members of our IFOR company are ready and committed to executing their mission. If and when all members of the company respond in this fashion, the IFORs begin executing their current mission. (Some IFORs may take some extra time getting ready, and may not respond immediately). These messages became necessary, as otherwise, some IFORs would not be ready by the time the company took off.

The actual messages exchanged in the internal IFOR language (the following may not be very useful).

 cheetah421 establish-commitment execute-mission 
 cheetah422 established-commitment execute-mission 
 cheetah423 established-commitment execute-mission 
 cheetah424 established-commitment execute-mission 
 cheetah425 established-commitment execute-mission 

2. The mission specification indicates that the company is to halt at a phase line, on-order. So after taking off to begin executing their specified mission, the company halts at the phase line. When the company commander (cheetah421) receives a "resume" command from the battalion commander, it (cheetah421) broadcasts to the members of the company that they: "terminate halt, and resume"

The actual messages exchanged in the internal IFOR language (the following may not be very useful).

 cheetah421 terminate ordered-halt --- resume point 

3. When the company reaches the holding area, a team of scouts is sent ahead to scout the battle position and engagement area. These scouts -- in IFOR company lets call them cheetah424 and cheetah425 -- move ahead into their individual observation positions. They mask in these locations, hiding from the enemy. Here, once again, they exchange radio messages to ensure that they are both ready to observe the enemy. This exchange occurs by cheetah424 asking that the other team member to be ready and committed to observing the enemy. Cheetah425 responds by saying that it is ready and committed to observing the enemy. After cheetah425 responds, the scouts start unmasking and observing the enemy.

Once again, the internal IFOR messages:

 cheetah424 establish-commitment mask-and-observe 
   cheetah425 established-commitment mask-and-observe 

4. When unmasking and scouting, cheetah425 sees the enemy in the engagement area. It broadcasts to the company that that it has scouted the battle position (therefore, terminate the scouting), and that it sees the enemy at coordinates 54641, 33700. Internal IFOR message:

 cheetah425 terminate scouting battle-position --- 54641 33700 

------------------------------------------------------- 5. The IFORs next replan their firing position. The commander (cheetah421) will be doing the replanning, based on information received from the scouting team (from cheetah425). Once again, cheetah421 ensures that everyone is ready to receive the new firing positions. So, cheetah421 broadcasts a message to the company, asking them to be ready to replan firing positions. (It asks them to commit and be ready to replanning firing positions). When everyone in the company responds (turn by turn) that they are ready, cheetah421 sends them the new firing positions turn by turn. Later, it informs everyone that the replanning of firing positions is completed: terminate replan firing positions

The internal IFOR code messages are as follows, although once again this may not be useful:

 cheetah421 establish-commitment replan-firing-positions 
 cheetah422 established-commitment replan-firing-positions 
 cheetah423 established-commitment replan-firing-positions 
 cheetah424 established-commitment replan-firing-positions 
 cheetah425 established-commitment replan-firing-positions 
Actual transmission of firing position deleted.
 cheetah421 terminate replan-firing-positions replanned-firing-positions *yes*

6. After replanning and communication of the firing positions, each helicopter flies to its firing position. The helicopters are to launch a simultaneous attack on the enemy, by unmasking simultaneously, and launching the first strike. To ensure a coordinated attack, the commander now makes sure that everyone is ready and committed to engage the enemy. (Each helicopter may take a different amount of time to reach its new firing position, and so ensuring coordination becomes important).

This coordination is achieved via the same routine as before. The commander broadcasts to everyone to be ready and commit to engaging the enemy. Each company member responds turn-by-turn when they are ready that they are committed to the engagement. Some members may take a long time to reach their firing position; and may not respond immediately. When everyone responds, the company begins launching a coordinated attack on the enemy.

 cheetah421 establish-commitment engage 
 cheetah422 established-commitment engage 
 cheetah423 established-commitment engage 
 cheetah424 established-commitment engage 
 cheetah425 established-commitment engage 

7. At one point the commander decides to terminate the engagement. It broadcasts a message on the radio to "terminate current engagement, since mission is completed".

 cheetah421 terminate engage completed mission

------------------------------------------------------- 8. After completing the engagement, the helicopters reassemble at the rally point. When the commander (cheetah421) determines that the helicopters have reassembled, it informs them that the reassembling should be terminated, since everyone is assembled at the battle position.

 cheetah421 terminate prepare-to-return-to-base 
		assembled-at-battle-position *yes* 


9. When the company is flying back to the home-base after finishing the engagement, cheetah422 sees enemy anti-aircraft-guns (AAA) enroute. So, cheetah422 broadcasts to the company that they should terminate their current flying along the flight plan, because they have to evade a "AAA" at coordinates of 54000, 33000, to the right of the flight path. So cheetah422 broadcasts to the company to: "terminate fly-flight-plan, by evading AAA at 54000 33000 right"

 cheetah422 terminate fly-flight-plan evade AAA 54000 33000 right 

------------------------------------------------------- 10. After evading the enemy, the company may be in a disarray, as each helicopter may take a slightly different course of action in evading the aaa that cheetah422 announced on the radio. The commander now has to replan the route back to home base. So, cheetah421 first ensures that everyone is ready to receive the new plan, by broadcasting on the radio: to be ready and to commit to repair the old flight plan.

When everyone responds that they are ready to repair the old flight plan, the commander begins replanning.

Soon thereafter, the commander broadcasts the updated plan on the radio to all of the members of the company. In this case, the new plan involves flying to coordinates 59802,36422 and then to 59000,37000

 cheetah421 establish-commitment repair-unachievable-operator 
 cheetah422 established-commitment repair-unachievable-operator 
 cheetah424 established-commitment repair-unachievable-operator 
 cheetah425 established-commitment repair-unachievable-operator 
 cheetah421 terminate-jpg constant repair-unachievable-operator 
flight-plan-change *yes* 59802 34622 59000 37000

Since the release of STEAM 1.0, we have improved it. STEAM 1.1 will be released soon.