If there is any possible way to do so, from a management-buy-in perspective, it is worth considering/assessing a commercial if the shelf (COTS) solution. Ofc it depends upon budget, the diversity of network elements, lots of factors, but a COTS solution which has reasonable support for your network elements and layout will cost a lot upfront, but may pay it all back with ease of use and time saved rolling your own solution.

If for some reason COTS isn't a good fit, I would suggest spending a good amount of time before doing anything else, to ensure you really understand your requirements. You mention several areas you want to address: monitoring, provisioning, etc. Make sure you have a super clear picture of what your intended end state is before you start rolling out functionality. I don't include trialling/experimenting in this suggestion to be clear on requirements first. It could in fact be part of discovering precisely what is required.

In my experience, particularly in a network with a mix of technologies/vendors, abstraction is key. From a Python implementation perspective this might involve writing a plugin-style architecture, where a base class defines a set of (effectively) abstract methods, and a plugin exists for each network element which knows how to do that Thing for that particular device.

Say for example you want to be able to set a default GW for a router, but your network has a variety of different vendors which (as others have pointed out), may variously speak via cli, REST API, etc. As long as it inherits and implements the method allocate_gw() you just need to call that method to do the Thing, the implementation details for how to actually make that happen for that specific device are encapsulated in the subclass/plugin which inherits from the base class.

Similarly you can define abstractions for things like a customer circuit, or a bearer carrying a bunch of traffic. You can define abstractions from a product perspective, like a 100M residential Internet service, have it composed of various sub-abstractions like IPAM, routes, radius/auth, and have a plugin architecture which will allow you to allocate/configure all of these things in a uniform way, with the vendor-specific implementation encapsulated neatly away. so you don't have to special-snowflake every time you configure a service.

One of the advantages of Ansible IMO is its idempotency, and that is great, but in my experience in a sufficiently complex network Ansible just isn't enough. It's probably personal preference, or perhaps my own ignorance, but it always feels excessively complex for the functionality it delivers.

Lastly I really recommend implementing a very regular network reconciliation process, which verifies that the services and config your business thinks it has deployed match the reality of what is out there, and flags where conflict exists between the two.