Conceptual big-picture architectural approaches of different ways of using Unity as a sub-component of a larger system

We have a rather large and complex real-time simulation system, with many millions of AI agents, distributed to an unknown amount of hosts (>100).

Today the output consists of static reports and graphs and a very rudimentary live view of the current state of the simulation using GDI+

Everything is written in C# and we use VS 2017 Pro.

We are now mainly looking for some kind of graphical platform to handle the visualization of the simulation, and since Unity also uses C# it seems like a god candidate.

Everything we have read so far indicates that Unity should be run as a stand alone process, and that Unity is the main application, and that you can extend functionality in unity by scripts, and external dll:s.
We would rather have it the other way around, that is, if possible we would like to load Unity as a dll, and then tell Unity what to show and in what way to show it.
We would like to have events fire back from Unity to our distributed agents.
At the same time we want to offload and take full advantage of as much functionality as possible in Unity. For example, if possible, we would like to replace the internal physics system we have today with PhysX, and if possible, integrate that as well with Unity and our distributed agents.

1. Is anything like this possible with Unity?

2. Are there any conceptual big-picture architectural documentation available on how to use Unity in a scenario like this?

3. Is Unity a good solution for this, or is this outside of the intended use of Unity?

4. If Unity is not the right tool/platform for this, then any suggestion of what might be?