The key to a functioning agent architecture is the interagent communication language. We explain ours in terms of its form and content. Regarding the former, three speech act types are currently supported: Solve (i.e., a question), Do (a request) and Post (an assertion to the blackboard). For the time being, we have adopted little of the sophisticated semantics known to underlie such speech acts [, , ]. However, in attempting to protect an agent's internal state from being overwritten by uninvited information, we do not allow one agent to change another's internal state directly -- only an agent that chooses to accept a speech act can do so. For example, a fact posted to the blackboard does not necessarily get placed in the database agent's files unless it so chooses, by placing a trigger on the blackboard asking to be notified of certain changes in certain predicates (analogous to Apple Computer's Publish and Subscribe protocol).
Although our interagent communication language is still evolving, we have adopted Horn clauses as the basic predicates that serve as arguments to the speech act types. However, for reasons discussed below, we have augmented the language beyond ordinary Prolog to include temporal information.
Because delegated tasks and rules will be executed at distant times and places, users may not be able simply to use direct manipulation techniques to select the items of interest, as those items may not yet exist, or their identities may be unknown. Rather, users will need to be able to describe arguments and invocation conditions, preferably in a natural language. Because these expressions will characterize events and their relationships, we expect natural language tense and aspect to be heavily employed []. Consequently, the meaning representation (or ``logical form") produced by the multimodal interface will need to incorporate temporal information, which we do by extending a Horn clause representation with time-indexed predicates and temporal constraints. The blackboard server will need to decompose these expressions, distribute pieces to the various relevant agents, and engage in temporal reasoning to determine if the appropriate constraints are satisfied.
With regard to the content of the language, we need to specify the language of predicates that will be shared among the agents. For example, if one agent needs to know the location of the user, it will post an expression, such as solve(location(user,U)), that another agent knows how to evaluate. Here, agreement among agents would be needed that the predicate name is location, and its arguments are a person and a location. The language of nonlogical predicates need not be fixed in advance, it need only be common. Achieving such commonality across developers and applications is among the goals of the ARPA ``Knowledge Sharing Initiative,'' [] and a similar effort is underway by the ``Object Management Group'' (OMG) CORBA initiative to determine a common set of objects.
A difficult question is how the user interface can know about the English vocabulary of the various agents. When agents enter the system, they not only register their functional capabilities with the blackboard, they also post their natural language vocabulary to the the blackboard, where it can be read by the user interface. Although conceptually reasonable for local servers (and somewhat problematic for remote servers) the merging of vocabulary and knowledge is a difficult problem. In the last section, we comment on how we anticipate building agents to enforce communication and knowledge representation standards.
Figure: Example of agent interaction