The idea so far is to create a version of PureMVC which allows the different main components (commands, proxies, mediators) to be independent agents in the system.
Why are you of the mind that you need a special version of PureMVC?
On the AgentScape website it says:
Agents are active entities in AgentScape that interact with each other by message-passing communication.
Well, the PureMVC actors (mediators, proxies, commands) are already have their own way of communicating (notifications). But usually these actors work together to perform the work of a core or an application. I imagine a modular approach where PureMVC cores are the agents of the system is more likely what you want.
1) Is there a recommended way of working with Request/Response based UIs? As far as I understand, with flash it's possible to adjust individual user interface components as soon as changes are necessary; But with the Request/Response mechanism the whole interface (layout) usually needs to be re-constructed every time and only served to the client once complete.
It would depend on your widget toolkit how you do this in the language/platform you're working with. From the AgentScape site, I'm assuming you're using Java.
You want to encapsulate much of the UI behavior in the component itself as possible. With Flex, it is possible to do this with Flex view states. So you can have a component receives data and change its visual aspect to display or edit data.
For instance, a view component might contain a list and when you select an item and click a button, it fetches the detail data for that item and displays it. You might have the view component have a 'FETCHING' state that is displayed after the button is pressed. It would no longer have the 'View Details' button, but in its place would appear an indeterminate progress bar saying 'Fetching item'. Then when the service returns the data, the proxy sends a notification that the mediator hears and sets the data on the component. When the data is set, the component might go into a 'VIEW_DETAIL' state where the progress bar is gone and an 'Edit Details' button appears.
The PureMVC apparatus mostly just shuttles data between the View and Model tiers. How you manage view behavior is entirely in the view component and not a matter of the framework. With the StateMachine utility, you can have application-wide states, but you still need to reconcile your individual view components states with the overall application state. This is a matter of the mediator for each component listening for application state changes and telling their view components to hide, show or reconfigure themselves appopriately.
2) How tightly coupled are different parts of the system? How much do they need to about each other? Notifications I can convert into inter-agent-messages when necessary I think, but I'm not sure about cases when e.g. mediators directly instantiate proxy-classes...
Mediators don't often instantiate proxy classes. That is usually handled at startup of the application in a command. That's not to say they couldn't they just usually don't. According to the MVC concept the view may update the model, and so mediators often retrieve and cache a reference to frequently accessed proxies when they are registered. After all, the view has no other purpose in life than to display and let the user interact with the model, so it is understandable that the view will have some dependencies on the model tier actors.
The separation we want to be most careful about is from the model to the view. The Proxies should not know anything at all about the rest of the application. Always assume that some or all of the model tier will be reused in another application. This will keep you from making dependencies on the Mediators or Facade or Notification names of this app. It is also why Proxies don't listen for notifications. It would be too tempting to make dependencies on the app.
Many people choose to separate the view from the model with the aid of the controller. That is instead of having a mediator retrieve a proxy and make a call on it, they instead send a notification, which is mapped to a command, which retrieves the proxy and makes the call. This is perfectly fine, but not necessary. If it makes you feel cozy that there is a one to one relationship commands and model interaction initiated from the view, then by all means go for it. But, it can also be seen as adding unneeded complexity. If you are making the same call from 5 places in your app, then sure pushing that into a command and sending 5 notifications is probably called for.
Basically, things are as loosely coupled as they need to be to implement MVC.