Hi Himansu,
Combining frequency agility with shared channels typically isn't a good idea and I would strongly recommend against it, but it is doable...if you haven't already read the application notes and the message protocol document I would strongly recommend doing so.
As you may already know, frequency agility works by assigning a fixed list of multiple frequencies to all of the channels you are using. The master channel switches to only using acknowledged messages to broadcast data instead of regular broadcast messages, which means any listening slave channels will have to return an ACK to tell the master someone is listening, if the master doesn't hear an ACK for 8 messages, it will jump to the next frequency set on the table, and if the slaves don't see a message for 8 seconds they will do the same, thus avoiding RF interference on that channel.
Shared channels work by having the master and all slave channels share the same Channel ID, but differentiate by using part of the message payload as an additional address for each slave to allow polling of each slave, and using address 0 as a broadcast to all option.
One issue that may arise is that at startup, you may have many many nodes which need to be assigned an address at using the auto shared channel code, and with frequency agility enabled, all of those nodes will be attempting to ACK back to the master, which means that your master may never receive an ACK back and prematurely attempt to jump RF frequencies.
However, what you do have going for you is that the message being ACK'd back by all of the nodes are identical as they all share the same Channel ID, so it's very likely that at least 1 of these ACK's will "win", or the ACK's will overlap perfectly in time and the transmission is not corrupted. Really basic testing indicates that this part will work with at least 4 nodes so far.
The main issue is if you have nodes which are entering/leaving the area of the shared channel often. When the master channel goes to poll your shared channel address and that slave is gone, after 8 messages the master channel will switch RF frequencies, assuming it cannot hear from the slave. You could attempt to mitigate this by using very short polling cycles (around 4 messages or less), so as long as only occasional nodes enter/leave you should be ok.
TL;DR: Doable, but test, test, test.
Cheers
