I'd be interested in seeing an agent interacting with a less popular API as well. Personally, you won't catch me with a smartphone unless it is at the far end of a hammer, and if you find me on facebook or linked-in please let me know because I believe in GDPR and my right to be offline.
The other end of the spectrum from facebook would be "niche sensitive data services" - imagine an bespoke API for a set of services - how could I run that on a general purpose agency? I'd have to upload code that runs on another infrastructure (much like a cloud). In certain markets the network is now trusted (like a phone line), but uploading and executing source code snippets "in a public/private cloud" is a lot like doing yoga at a public/private nude beach - no matter what, you are exposing a lot - and for the people consuming bespoke APIs, even a private cloud is a bit revealing.
my solution to this problem was something I called a "micro-agency" - the micro agency supports a very limited set of services for a very limited set of DIDs - where the edge cases get interesting as "very limited" grows. And it conflicts with the concept of DID = Agent, sorta.
it depends upon how DID = Agent, and IO = Agent play out. If you have an agent w/ multiple DIDs, supporting something "in common" - like a 'primary DID' which serves as the link to the IO. This adds a layer of "multi-DID routing" to the Agent which is not needed if "Agent = DID" - one agent, one DID.
But if you have Agent = DID, then you need to have the ability for an Agent to support everything a single DID might ever get up to, and that is a crazy burden to put on an agency unless you have an agency be the scale of "App Engine", where people upload code ..... wait a minute.... (we've been here!
So I think agents need to support a set of "services", and the DDO should speak to "a set of agents" - where the total number of services supported by the DID is "the set of agents that know the secret cryptographic handshake" - your agents out there are the ones you can TLS with - and they are agents At-A-Place, For-A-Purpose.....
In such a world you might have a "public agent" which sits on a well known agency, answers your email, routes your APIs, provides your public face. You might also have some, "discrete agents" which operate on your behalf for specific purposes (e.g. your banking on Hong Kong, your reporting to the United States Internal Revenue Service)
In this way your Hong Kong Financial Representative (agent_(< DID1 >< HONGKONG >) ) would sit there, operated by the Hong Kong Monetary Authority, interacting with Hong Kong Banks on your behalf, ensuring comprehensive and detailed compliance (think of the accounting savings!) - and it would be wholly different and insulated from the Social Media presence of your Hong Kong Financial Identity.
These two agents, operating for the same DID, on an agreed upon disjoint set of services (partitioning service_endpoints in the DDO?) - form the online expression of your identity, with the subscription to each service depending upon the backend services provided by the Agency itself. It disassociates, in a fundamental way, the connection of an IO with an Agency itself, and replaces it with the association of an IO with an Agency (for a purpose) - and that, I think, is important for the Trust Framework - particularly in determining the liability transfer characteristics of the IO/Agent relationship.
It's a round-about way, but I hope not too meandering, way of requesting the comparison of a Facebook level sovrin/non-sovrin interaction in parallel with MyLocalCoffeeShopAPI sovrin/non-sovrin interaction.