Since the old days of procedural programming, the most common scheduling mechanism for large HENP applications has been the Finite State Machine. This FSM has often been implemented in a rather inflexible way. In particular, every module in the application must usually implement a "transition" method or function for each and every one of the predefined states (beginRun(), nextEvent(), etc.). As a consequence module developers are sometimes forced to provide dummy state transition methods and, crucially, it has proved to be next to impossible to extend the list of allowed states beyond the initially defined ones. The Dynamic State Machine we have prototyped for the Atlas software framework, Athena, was inspired by the Multicast pattern. It allows the developer to define which of the existing state transition her module should take part to, or to define a new state without the need to recompile any of the existing modules. Each state and each transition have their own types, allowing the compiler to statically check any mismatch between states, transitions and modules taking part to them. We believe that this scheme will allow to exploit the simplicity and elegance of the FSM mechanism in an environment with hundreds of modules (and developers) for the expected life-time of the Atlas collaboration.