Producer-consumer based actor design pattern backed by a Mealy state machine
Key features beyond keeping the same structure and plumbing code regardless of the functionality of a particular actor:
Separation of notions of events, states, and actions
Separate queues for events and actions to facilitate Run To Completion scheduling
State machine implementation where actions can be associated not only with entering a state but also with transitions between states (Mealy state machine)
Isolation of the high level state machine logic (on which event in which state to run which actions and switch to which state) in a dedicated place in the code. This is worse than storing that information as a separate data structure and maybe even in a separate file editable with a specialized editor like it was done in my LabHSM toolkit but still much better than branching depending on the state in the actions themselves.