The reusability graal
Achieving reusability requires lose coupling: every dependency to other classes makes the reusability more difficult because it adds more constraints. For example if reusing your actuator requires reusing your state and and your commands, which themselves may require to reuse I don't know what, and so on, it may not be so reusable after all.
How to reduce the coupling in your case ? Your (hopefully) clean interfaces is certainly the beginning. But you will need some dependency inversion as well, for example i dependency injection . This allows some kind of run-time configuration. So instead of having a class to know the command class to create new commands, you'd use an abstract command and provide to the class a command factory.
Now that we are mentionning interfaces and abstract classes, you'll also need to ensure that the deived classes behave according to the rules. And here Liskov Substitution Principle may help.
If you just follow the SOLID design principles, you get these 3 for free ;-)
Your requirement is:
to make the agent as well as each of the components that are exposed
by those interfaces re-usable so that I can substitute more advanced
... or dynamic ... without any code change to the agent or unchanged
components (and preferably no re-compilation).
Of course, you can do this using templates. This has the benefit of facilitating reuse. No special constraint for T and T1 classes: just provide the required meta-interface. (But where are the requirements for T and T1 described ?)
Unfortunately templates, despite their power and flexibility, are compile-time. This does not allow run-time polymorphism, nor make dynamic loading of the right class possible.
In view of your design goals, I'd therefore recommend to get rid of the templates and opt for a polymorphic design, using an abstract
Command class and an abstract
State class and provide the factories to create those.
It is possible that your dynamic model will provide much more features than your simple abstract state. The advanced kinematics might also require some more exchanges than the basic one.
For this you could opt for a decorator pattern, to add new functionality and responsibilities. However, your agent would need to know about these. Another approach would be to use an architectural pattern that is common in games, the Entity-Component-System: here you could add advanced features as an optional component, and let your agent search in your actuator entity, for the most suitable component.