I was thinking that having some kind of sub-ai definitions established when a unit is in a stack, defining the cause for it being there (fulfilling a 'build-to' call for what should be considered a volumized need in a 'well balanced stack') and how it may wish to act independently on certain triggers, could be useful.
Stack composition will be a big issue to make the ai use the combat mod effectively so you may wish to plan how to improve on that in light of some of the combat mod documentation I'm about to add later tonight (though I may not get through it all right away - there's a lot to it.) I have a lot to suggest there for the AI modding that I'm not above trying to help with myself but I'm not in full understanding of the whole ai maze yet, just some fuzzy understanding of basic employed principles so far.
If you're wanting to focus mostly on AI, I could use a bit of improvement on the Cure mission AI as well... which I think is going to require setting up a whole new AI definition for Healing units, which is probably a good idea anyhow for numerous reasons.
I don't think trying to add sub-stack AIs is a good idea (it changes too much of what the entire unit AI is predicated on). What I had (vaguely) in mind was adding a concept of a coordinator stack to a group of stacks (so each stack would have the id of its coordinator, which in many normal cases would just be itself, but in some case might be another stack). When executing its turn part of the regular AI would (at the appropriate point for its own AI type) consult with the coordinator in some way for 'suggestions'. Mostly I'd plan to use this to break up AI SoDs, but keep them loosely coordinated such that they all head for the same target city and so on, but retain the flexibility to make separate local attacks, and to spread out for surround and destroy purposes.
In principal the coordinator doesn't need to be another stack - it's just an abstract suggestion-giver, but pragmatically putting it on a stack gives a vehicle for persisting any data it needs without adding totally new object classes that need serializing (I might change to the more abstract approach as this gets fleshed out however - no sure yet)