Looks like I finally ended up with something which does work not so bad. I am using an asyncronous runnign "Job Manager" which basically cares for assigning jobs to idle agents. To do there is some job queue for manually issued jobs and if this is empty, the Job Manager queries different zones, if they have job to do.
A stockpile is such a zone, and if queried it will determine if there are any ressources lying around which need to be hauled and if so, they will generate a job which is then assigned to the next idle agent. This should basically keep the queue of "open jobs" relatively small. There is several object locking and caching arrays involved for everything to work well with the renderer and keeping the impact on the framerate as low as possible, but under some circumstances (i.e. a fully locked in agent) will still clog everything up a bit. I do need to make a lot of compromisses between object locking and performance and was quite busy with a lot of bugs evolving around that. In the video some of those bugs a re still visible but most of them are already fixed.
Another issue with this system currently is, that the items in the world (which ressources are) are currently a "global list" together with partioned references for them on every chunk. While this has benefits in some situations I am not enterily sure if this will be viable in a highly populated world and so this may change to a fully partioned system with the drawback of having any lookups being slower in some cases.
Current tests with a lot of agents worked out pretty well, beside the fact, the more agents are assigned a job, the longer it will take until everyone has finished it's pathfinding, but there is no way around it and with complexer environments this will slow down even further.
In the current system, there are sort of Job-Chains. So each job can basically have follow-up-jobs defined during creation of the job itself. This is in order to lock/reserve any involved resources. In the example of hauling, the stockpile creates a job, reserves a space for it and locks the item on the map. An agent will now have the order to pick up that item and a follow up job, to drop down the item to a specific spot.
Problems arises, when such a job chain needs to be canceled for whatever reason (agent died, way blocked) as now the full chain needs to be processed in order to free up any reserved spots or items. With follow up items that is pretty straight forward, but there may be situations where this is not enough. Need to see if it's sustainable.
Anway, still a lot of things to play around with and I am eager to actually see the agents building something, felling trees or seeing stacked items displayed differently or having storage containers.