My thought exactly. It loads the key into memory and never exposes it, just lets you perform operations such as signing and returns the result.
It seems primarily geared at clients rather than servers, but in theory can be used for both (I'm not even sure you can load your openssh server key into ssh-agent, can you?)
> (I'm not even sure you can load your openssh server key into ssh-agent, can you?)
Yes, actually, as of OpenSSH 6.3 you can. (I wrote most of the patch that added that feature.) However, even without doing that the OpenSSH server performs crypto operations in a separate process from the network-facing child process (unless you've disabled UsePrivilegeSeparation). The purpose of having the server talk to an ssh-agent was to allow keeping your host keys encrypted on-disk or loading them from a smart card.
> I'm not even sure you can load your openssh server key into ssh-agent, can you?
No need, servers only need to do signature verifications during authentications, thus they only need users/clients public keys which must be listed as authorized_keys.
Edit: I maybe didn't fully grasp you question, if you were referring to ssh host keys, in this case to my knowledge you're right they can not be used with ssh-add.
Its also similar to an abstraction in Erlang. The crypto application is started and all processes defer to the crypto application for operations. I don't know of the implementation is as secure as the article describes, but the abstraction is simple and straightforward.