The Agent Group construct is the 'normal' way to group Agents. Different groups can have different behaviors:
- Always take the first agent in the list that is active
- Round robin thru the list, so the jobs will be distributed
- All/ForEach - this sounds like what you want. The job will be executed on every agent in the group.
I have not tried changing the group membership dynamically, as your original posting suggests. The Groups can be defined to automatically add members (A windows agent group can add transparently add/remove agents as they are defined, same with linux/unix). There are other options for automatically adding new agents to existing groups -- check what is available in your release..
If that is not dynamic enough, I suggest using the Automic API call to add/remove agents from the group, rather than creating a vara and a script to do something Automic already does. One proviso, I would have the API call invoked BEFORE invoking the chain/workflow. Test that behavior out for your exact environment.
You could have the reference to the specific automic job or the name of the OS script to be invoked in a vara, and also set that value BEFORE invoking the chain/workflow.
I would name these AgentGroups in a way to CLEARLY indicate the dynamic nature.
Your note does not make it clear if you are giving the end users access to the GUI and the ability to make these kinds of changes. be careful to limit what they can do.