There are different concurrency paradigms:
To my untrained eyes, these all do the same thing. If they are all available, when should I use one over the other? Are they compatible? Can they be used together?
Asynchronous programming has a long history. Most of that history is filled with callbacks or events, which are very difficult to program with.
The big benefit Promises/Futures brought was that an asynchronous operation was now represented by a single object, which had its own list of callbacks/notifications. This fixed most problems with old callback/event-based asynchronous programming styles, but could still be awkward when coding things like loops (e.g., exponential retries).
async/await builds on Promises/Futures by adding an even more convenient syntax; with async/await, asynchronous methods are finally almost as simple as synchronous methods. Most async implementations build on promises (e.g., Promise in JavaScript, Task<T> in C#, asyncio.Future in Python, Future trait in Rust).
Actors are a completely different kind of thing. Actors are more about distributed programming, where an actor can run on any machine and has its own error recovery, etc. The original OOP ideas were very Actor-like (sending "messages" to "instances" that could be remote), but these days OOP has settled into a concept where they are restricted to the same local process. Actors in some ways represent a resurrection of the original OOP ideas.
As far as usage guidelines, I'd recommend async/await over Futures/Promises because it's a further evolution of the same idea (asynchronous coding patterns). Actors are a different technology solving a different problem, so I'd say use them only if you need them.