Improvements in repository pattern
I'm skeptical of the value of this design pattern, for two reasons:


The Repository class is basically just a Python dictionary.  You never use Repository.all() anyway.
Repository is actually a glorified namespace.  It's a disguised mechanism for you to make a bunch of global variables.


Additionally, I see some puzzling aspects to the code:


Why would UserRepo() make its .validator configurable?  And why would it default to None?
Since UserRepo and CompanyRepo contain nearly identical code, why not consolidate them?  At the least they should have a common base class.  Maybe they could even be handled by one class.
The WorkerAdder object seems contrived.  Why split the work between a WorkerAdder() constructor and an .add() method?  Why is the company name and address hard-coded?


Some minor remarks:


It's customary to chain to the superclass constructor first, not as the last statement in the subclass's constructor.
Serialization means turning an object into a string representation; your User.serialize() returns a dictionary instead.  The string representation needs to  contain enough detail to reconstruct the object exactly; your User.serialize() omits the .created_at and .update_at timestamps.


In summary, Repository is just a dictionary that serves as a namespace for global variables.  There's not much point to it, since symbol tables in Python are also dictionaries.  UserRepo and CompanyRepo do serve a purpose, but you would have to reinvent the wheel (implementing the persistence mechanism, for example) to make them useful.  You might as well use a real database (which could be as simple as sqlite) with an ORM.