Interesting discussion, you’re all basically describing the exact gaps we’ve been trying to solve with io.Insights, so I thought I’d share how we are approaching it.
At a high level, io.Insights is an OpenTelemetry-based observability layer baked into io.Connect Desktop/Browser. Instead of wiring Google Analytics or hand-rolled logging into every app, the platform itself emits metrics, traces and logs about app usage and user journeys, and you can plug that straight into whatever stack you already use (Prometheus, Grafana, Jaeger, Datadog, etc.).
You can use it’s out of the box metrics, to easily get started and understand leading indicators like - which apps/workspaces are actually used, how often, how long they run, crashes/errors, etc.
Because the io.Connect APIs themselves are instrumented, calls to interop, intents, contexts, etc. create spans like interopio.api.interop.invoke, interopio.api.contexts.update, etc.
Those spans can be turned into metrics (“traces as metrics”), so you can, for example, easily count:
-
Number of specific intents invoked across the platform
-
Which apps act as providers vs consumers
-
Error rates / latency for key interop hops
This gives you the platform-level view of FDC3 usage Nicholas mentioned (outputs that are plausible leading indicators for outcomes like better execution or fewer errors).
The same approach using “Traces as metrics” you can use also for timing workflows, establish baselines and have data proof that the interop workflow optimization you have done is indeed improving the life of your users.
Note that io.Insights Traces and Logs are currently in a Beta state and provided on demand to customers. They will be made GA in Q1,2026.
Let me know if you have any questions or want to discuss specific use cases. Happy to explore with you how io.Insights can help you to get this observability in place that can prove ROI and measure the benefits of your work.