Sufficiently recent versions of ssh (7.2, released early 2016, and newer) have an option AddKeysToAgent which does just that:

AddKeysToAgent

Specifies whether keys should be automatically added to a running ssh-agent(1). If this option is set to yes and a key is loaded from a file, the key and its passphrase are added to the agent with the default lifetime, as if by ssh-add(1). If this option is set to ask, ssh(1) will require confirmation using the SSH_ASKPASS program before adding a key (see ssh-add(1) for details). If this option is set to confirm, each use of the key must be confirmed, as if the -c option was specified to ssh-add(1). If this option is set to no, no keys are added to the agent. The argument must be yes, confirm, ask, or no (the default).

As to differences in behaviour: the ssh-agent protocol follows a standard, which boils down to the following: the client (ssh, or ssh-add, or anybody else interested) knows who to talk to by looking at the environment variable SSH_AUTH_SOCK. The protocol, slightly simplified, has the following operations:

1. key management operations: add, remove, list available keys

2. message operations: sign, encrypt, etc.

Usually, you'd use ssh-add for the first kind. But, as said, new sshs will add as well. When you ask about on-demand loading of keys: an agent might do something fancy when you ask for a list of available keys – the standard implementation requires you to add all the keys beforehand, but a desktop environment implementation might have keys in some wallet storage protected by a master password, and ask for the password when you first try to use any key. (Or maybe you mean keys are shared between different terminal windows? That's just a matter of getting the environment variable SSH_AUTH_SOCK into all your terminals, which is why it's good to start the agent in your session, so all terminals inherit the variable.)

Sufficiently recent versions of ssh (7.2, released early 2016, and newer) have an option AddKeysToAgent which does just that:

AddKeysToAgent

Specifies whether keys should be automatically added to a running ssh-agent(1). If this option is set to yes and a key is loaded from a file, the key and its passphrase are added to the agent with the default lifetime, as if by ssh-add(1). If this option is set to ask, ssh(1) will require confirmation using the SSH_ASKPASS program before adding a key (see ssh-add(1) for details). If this option is set to confirm, each use of the key must be confirmed, as if the -c option was specified to ssh-add(1). If this option is set to no, no keys are added to the agent. The argument must be yes, confirm, ask, or no (the default).

As to differences in behaviour: the ssh-agent protocol follows a standard, which boils down to the following: the client (ssh, or ssh-add, or anybody else interested) knows who to talk to by looking at the environment variable SSH_AUTH_SOCK. The protocol, slightly simplified, has the following operations:

1. key management operations: add, remove, list available keys

2. message operations: sign, encrypt, etc.

Usually, you'd use ssh-add for the first kind. But, as said, new sshs will add as well. When you ask about on-demand loading of keys: an agent might do something fancy when you ask for a list of available keys – the standard implementation requires you to add all the keys beforehand, but a desktop environment implementation might have keys in some wallet storage protected by a master password, and ask for the password when you first try to use any key. (Or maybe you mean keys are shared between different terminal windows? That's just a matter of getting the environment variable SSH_AUTH_SOCK into all your terminals, which is why it's good to start the agent in your session, so all terminals inherit the variable.)

Sufficiently recent versions of ssh (7.2, released early 2016, and newer) have an option AddKeysToAgent which does just that:

AddKeysToAgent

Specifies whether keys should be automatically added to a running ssh-agent(1). If this option is set to yes and a key is loaded from a file, the key and its passphrase are added to the agent with the default lifetime, as if by ssh-add(1). If this option is set to ask, ssh(1) will require confirmation using the SSH_ASKPASS program before adding a key (see ssh-add(1) for details). If this option is set to confirm, each use of the key must be confirmed, as if the -c option was specified to ssh-add(1). If this option is set to no, no keys are added to the agent. The argument must be yes, confirm, ask, or no (the default).

Sufficiently recent versions of ssh (7.2, released early 2016, and newer) have an option AddKeysToAgent which does just that:

AddKeysToAgent

Specifies whether keys should be automatically added to a running ssh-agent(1). If this option is set to yes and a key is loaded from a file, the key and its passphrase are added to the agent with the default lifetime, as if by ssh-add(1). If this option is set to ask, ssh(1) will require confirmation using the SSH_ASKPASS program before adding a key (see ssh-add(1) for details). If this option is set to confirm, each use of the key must be confirmed, as if the -c option was specified to ssh-add(1). If this option is set to no, no keys are added to the agent. The argument must be yes, confirm, ask, or no (the default).

As to differences in behaviour: the ssh-agent protocol follows a standard, which boils down to the following: the client (ssh, or ssh-add, or anybody else interested) knows who to talk to by looking at the environment variable SSH_AUTH_SOCK. The protocol, slightly simplified, has the following operations:

1. key management operations: add, remove, list available keys

2. message operations: sign, encrypt, etc.

Usually, you'd use ssh-add for the first kind. But, as said, new sshs will add as well. When you ask about on-demand loading of keys: an agent might do something fancy when you ask for a list of available keys – the standard implementation requires you to add all the keys beforehand, but a desktop environment implementation might have keys in some wallet storage protected by a master password, and ask for the password when you first try to use any key. (Or maybe you mean keys are shared between different terminal windows? That's just a matter of getting the environment variable SSH_AUTH_SOCK into all your terminals, which is why it's good to start the agent in your session, so all terminals inherit the variable.)