always end up in the percept database of ${B_{\textsf{Jason}}}$.

   **Step**                      ***Jason* internal actions**                                            **Direct communication**
  ---------- -------------------------------------------------------------------- ----------------------------------------------------------------------
      1       ${A_{\textsf{Lego}}} \xrightarrow{Bluetooth} {A_{\textsf{Jason}}}$    ${A_{\textsf{Lego}}} \xrightarrow{Bluetooth} {B_{\textsf{Lego}}}$
      2       ${A_{\textsf{Jason}}} \xrightarrow{Internal} {B_{\textsf{Jason}}}$    ${B_{\textsf{Lego}}} \xrightarrow{Bluetooth} {B_{\textsf{Jason}}}$
      3                                                                            (${A_{\textsf{Lego}}} \xrightarrow{Bluetooth} {A_{\textsf{Jason}}})$

  : Comparison of communication methods when sharing percepts.[]{data-label="tab:communication_comparison"}

Table \[tab:communication\_comparison\] shows the communication that will happen between the agents (of both kinds), when a percept is sent. The third message sent during the direct communication is not exactly relevant for the process it self, however, whenever an agent ${A_{\textsf{Lego}}}$ perceives something, this is automatically sent to the corresponding agent ${A_{\textsf{Jason}}}$.

The differences should be clear. By using direct communication, one sends three messages using bluetooth, while the use of internal actions enables one to limit the number of bluetooth messages to one. Sending a message internally in *Jason* is assumed to be faster than sending a message using bluetooth. It is therefore straightforward to conclude that using internal actions is much more efficient than using bluetooth communication.

Case studies
============

I have developed a few applications entirely in *Jason* to show the abilities of the Lego-*Jason* framework. First I discuss a classical robot example, and then I try to let two agents cooperate in 