この図の例でも分かるように、KQMLプロトコルで明示されているキーワードに対応する情報だけでは、プロセスモデリングの結果として表現すべき情報（例えば、eventやexceptionのタイプ、ワークエレメント間の依存関係等）が指定できないので、キーワードのcontentの属性として、各ドメインのオントロジに則ったメッセージ仕様を定義して通信することになる。どのような内容を定義するかは、エージェントがどのような固有情報を保持し、何をエージェント間で交換するかによって決定される。
ユーザーがアプリケーションを操作したイベント、エージェントがユーザーに対して知らせたい情報なども、KQMLプロトコルを介してやり取りされる。例えば、他の設計者とメールを交換したというイベントは、電子メールアプリケーションから、また、PMのデータを変更したというイベントは、CADアプリケーションからエージェントに通知される。
(3) メッセージ処理機能
受信したメッセージに対する、エージェントの応答処理機能である。オントロジに従って解析した受信メッセージを、推論機能に渡すことで、エージェントがどのような動作をすべきかを決定し、メッセージに対応する応答処理を実行する。
また、これまでどのような通信を行ったかを履歴として保存し、エージェントの推論に役立たせる。
(4) 推論機能
エージェントが動作するための知識となる部分であり、メッセージ処理機能から渡されたイベント情報などから、エージェントが設計者をどう支援するかを記述したルールに従って、何をすべきか推論する機能である。例えば、設計者が操作するアプリケーションから、データの変更操作イベントがメッセージとして送られてきた場合、これまで受信した操作イベントなどから、どのワークエレメントであるかを推論し、そのワークエレメントを参照したすべての設計者のエージェントに、変更メッセージを送信するといった手順を、推論ルールとして記述できる。
