Plugin architectures is quite a well-known problem in Object-Oriented Design, where it's usually addressed by defining a set of interfaces that the host program expects the plugins to implement.
On .NET, the Managed Extensibility Framework was explicitly designed to address this problem. Not only does it support interfaces that are defined in advance by the host program, but it can also discover and compose interfaces that one plugin requires (imports), and another plugin implements (exports).
Other mature DI Containers that support convention-based Auto-registration can be configured to supply the same features.
In F#, substitutability and composition is usually achieved with functions instead of interfaces, but I'm not aware of any DI Containers or other composition engines that work on F# functions instead of .NET interfaces. Since I mostly favour Pure DI these days, I also hope never to see this happen.
You may wonder why this is relevant in an F# context, but once you realise that there's a strong relationship between objects and closures, the relevancy may become more apparent.
In any case, the architecture suggested here isn't how plugin architectures are normally implemented. As explained above, plugin architectures are usually defined around a set of predefined behaviours, rather than data. Well-designed interfaces define behaviours, just as functions do. These are strongly typed and substitutable (polymorphic).
Weakly typed data is likely to become a maintenance headache over time, so I wouldn't go with that design.
You can read more about (Object-Oriented) loosely coupled architectures in my book.
You don't write about your root cause for writing an application with a plug-in architecture, but unless you're writing a big shrink-wrapped application like Visual Studio, a browser, a general-purpose web server, or the like, this sort of architecture is most likely overkill.
One of the best features of F# is that it prohibits cycles. In Object-Oriented languages like C# and Java, people often utilise component-based architectures like Ports and Adapters, Onion architecture, layers, etc because at the module level, cycles are prevented (you can't easily create cycles with hard dependencies). However, in F#, you get this assistance from the language itself, so there's much less reason to address coupling with architecture; coupling is already addressed by the language.