That is how I have the lower level (which I called “pleb” in this case) structured. The service sends a request to the commander for a new destination. A more optimal way to set this up would be to have it be a task instead of a service and have it add the lower level AI to an array on the commander’s end. Whenever the commander discovers a new location to search, the commander would do a second EQS search using the array of waiting “plebs” as context for the search. This would allow the closest pleb to be selected, and this would mean that the pleb wasn’t asking for a duty every 1 second or so.
This is the version of the commander tree that I discussed in earlier posts. This one is OK for the most part, although the decision making for the data nodes could be improved slightly. Perhaps pick a random data node that exists already, and check it for line of sight to any other data nodes would save the work load and allow for a much more robust scan.
To boost this further, you would need to track which nodes even have an eligible point somewhere in their pathing grid. If they do not, remove them from the possible selections.
These are all untested hypotheticals, but if you wish to use this in a live project, I hope this helps in some way.