tl;dr
How would I represent GUI as agents in a multi agent system.
I am learning more about Multi Agent Systems.
I like the concepts of such systems, it makes a lot of sense and it sounds very useful when I want to create a large system devised of smaller parts for the Web.
So, I created a basic Agent class, taught my agents to negotiate and communicate, created an environment for them to be situated in and such.
So, in a simple app attempt I have:
- Several “InfoBroker” Agents that handles communications with server services, wanting to obtain information about the world and willing to share it under certain terms (They hold an auction if that matters).
- A few agents that coordinate the communication between my services on the client side (Also “InfoBroker” agents I guess).
- A few working agents, that have a simple goal in their environment, performing calculations and performing (very basic) means-end reasoning in the environment. They’re my ‘manual labor’ in the app.
- A few other things specific to my application.
That’s all great, but I have no idea where GUI fits in all that? I need to show information about my system to the user, the GUI isn’t a small part (consider agents that speak to the DOM in a web app). How would represent GUI as an agent in a multi agent system?
Note: I’ve implemented this in JavaScript, but this seems more language agnostic to me.
1
From my point of view there seem to be 3 major ways of integrating the GUI into this multi-agent environment. These largely depend on the purpose and scope of the UI:
-
Gui as system/service
Since you already mentioned that you have agents capable of communicating with external
services, the GUI could be simply one such service to whom agents deliver information and if necessary fetch their input to complete a job. The Gui is not involved in the computation which is useful as the presentation of the work cannot interfere with the actual work of the agents. Interaction is limited to the communication with the agents. On the other hand it only knows what agents are willing to share and when, this could narrow the view of the system. Another drawback is that the Gui would become rather reactive, acting more as a I/O buffer to the system than an integral part of it. -
Gui as Agent
The Gui might have their own agents directly talking to other agents. Within the same logic as the existing InfoBrokers exist, Gui-agents could compete for data (e.g. aforementioned auctions). This would allow the Gui to investigate further and show the state of the accomplished work. It would give the user a way to be pro-active and feel more in control and up-to-date. The parameters and logic when and how information should be shown to the user is distinct of that how the actual work should be accomplished.
Especially when dealing with external services with high latency an agent might only report back to the UI when done with the work. Or it would have to know how to behave while the job is not complete. In addition the GUI could be an integral part of the agent environment. Using the goal oriented reasoning, data could be processed by different agents until it fits the format a Gui-agent requested.
-
Monitor (a.k.a. Petri-dish)
This way seems more suited when a direct observation of the whole environment is required. Each agent and the environment have Gui components which allow manipulatation of each part of the system directly and can display the state as a whole. Logging comes to mind aggregating all output into a global view at each moment. Initially I thought of this as an top-down view, but the more I think about it, it seems as an inside out view, where the user is free to poke and prod around.
Nothing prevents these concepts to be used in conjunction. In the end it all depends what level of interaction you require.