Something might be called an actor if it can:
1) Create other actors at runtime 2) Send and receive messages to/from other actors asynchronously 3) Can do something in response to messages and then optionally change this behavior in anticipation of the next message.
(Meaning: if you have to predefine all "actors" at compile time, this is not actor model. If you have to predefine "exchange points" AKA channels to communicate between two actors synchronously, this is not actor model. If you can't change your behavior at runtime, this is not actor model.)
Actors are very dynamic entities operating in a wild west environment without any guarantees (about delivery, or message ordering, etc -- just like the IP stack). Messages are sent in "fire and forget" fashion. The power of actor model is that it can be useful even in such an environment.