There are several things that I would suggest, mostly to make things easier for yourself and so you might be able to troubleshoot what is going wrong.
Your picking of objects is a bit confusing, which I think make things harder for you. You shouldn't mind adding several picking sub levels. A good rule of thumb I think, is to always make sure that a Pick <something> is always the last thing you do in a picking event. If you need to pick more different objects, add a new sub level.
The first picking order should be:
(X) = line in your the picking
(1) Every 0.032 seconds <------------ This can be removed, as (2) will check every tick and doesn't really impact performance a lot.
(2) Collisionsprite is overlapping Front
(3) For each Collisionsprite <----- This will act as a Pick <Something> so will be the last condition in the first pick, so add a new sub level.
So the above two conditions will pick all the relevant collisionsprites that you are interested in.
In a new sub level pick, you add:
(4) Collisionsprite is overlapping front <----------- You don't need this, as you have already tested for that in (2), so you already know that you have the correct objects, so this should be deleted.
This is what is important for the Front object. So add those next or add them above line (2) in the first Pick event.
(5) ai_enabled = 0
(8) Front is not attacking
Something seems wrong with (6) and (7)
(6) System Pick.... Front where ....
(7) Pick instance with UID collisionspite.AI_ID
(I don't know what is stored in collisionsprite.AI_ID, But I would double check that what you are doing here is correct and working. But these two conditions seems opposite of each other and my guess is that your problem is found with these two picks.)
But assuming these are correct. you can add the last Pick here as well:
(9) Pick a random Front
The sub event (10)
I assume that if the "Front" object is alive it should cast a fireball. If thats the case i would move it to a separate Attack group that handles Attack of AI. Mixing things together like movement and Attacking etc. Is most likely going to cause problems for you at some point.
In your actions, you use a rotate behavior, which seems to complicate things, there is an action for sprites called rotate towards position, which will let you rotate the sprite at a certain speed towards a target. That way you can get rid of the timer and rotate behaviors.
Not sure why you disable collisions? It seems wrong, but thats just a guess and there might be a reason for it.
I would strongly advice that you never use Wait actions as it can cause serious problems, and should only in my opinion at least, be used if you are 100% sure it wont cause problems. Besides that adding the wait as the last action will as far as I can see have no effect unless you actually create an object that you need to change some settings for later during the tick. (meaning until the program have ran through all the code and started a new cycle (tick), if this makes little sense, it have something to do with when objects are created in Construct and when they actually exist in your program. So an object created during a tick will not be available before the next tick, so it needs to be initialize at the same level or a lower sub level...., The wait can be used to "fake" it, and that is where problems starts, as the wait doesn't actually make Construct wait, it simply fires off after the wait is over, which is when problems can occur and make it very difficult to pin point the exact cause of bugs, as these can happen with something that is completely unrelated to the place you used the wait. If it still makes no sense, just remember Wait = problems )
Last you have a check called "On collision" which will trigger once while its true, you could use that instead. However if you have a lot of objects that need to use it, it will hurt performance a lot more than using "Is overlapping".