That's an important distinction, yeah. Maybe a 20 or so utility functions, but perhaps hundreds of "motivators".
A thought occurred to me because I really like the architecture that Kylotan suggested:
There are many ways to approach this.
One way would be to have a concept of a high level activity ("Retreat") which contains a sequence of low level actions ("Call for help", "Take cover", "Heal", "Leave the area"). If you have a lot of systems that tend to have these sequences or something similar, there is a good argument for using utility systems to pick basic high level activities and for behaviour trees to handle the individual actions.
Having separate utility functions for every action is going to be highly redundant. This might be a moment where I could bring in some of those synergies.
Let's say I have a utility function called "challenge someone for rank". It's calculated as the largest expected value of victory against someone my rank or higher. If I reach a certain threshold, I trigger a behavior tree that selects between several actions.
The obvious action is "challenge the best option for victory".
But the system would also consider actions that challenge the second best option under a few circumstances, effectively aggregating the motivations. Maybe the next best challenge would also kill someone I hate, or also kill a rival on the line of succession.
Similar idea for the food vs combat example. If I'm starving, trigger a behavior tree that selects from several food-finding options. But in addition to "go run around looking for food", the system would also consider "if you're in a combat quest to kill something that is made of delicious meat, just carry on".
I'm reluctant to invent my own solutions because I'm not arrogant enough to think I've figured out something no one else has. But this seems in line with what a few other people are suggesting, and so probably has some basis in good design?