Key encapsulation: one side publishes a key, the other draws a secret and returns something only the first side can turn back into it.

The shape is not ML-KEM's alone, which is why this is a class in a module of its own rather than part of any one algorithm: MLKEM is one instance of it, and a caller that does not care which it has can be written against this.

A bare Diffie-Hellman exchange is deliberately not an instance, even though the shapes line up. The KEM a Diffie-Hellman group gives is DHKEM, of RFC 9180 section 4.1, and that is not the raw exchange: its shared secret is the exchange's output run through HKDF with the ephemeral and the recipient public keys as context, under labels that name the ciphersuite. The binding to those two keys, and the separation between suites, are what the KEM security argument rests on; the raw value has neither. A protocol can supply the binding at its own level -- TLS 1.3 does, in the key schedule -- but then the binding belongs to the protocol, not to this class, and offering the raw exchange here would invite its use somewhere that supplies nothing.

DHKEM proper is an instance, and it is not here either: the labels it derives under carry the HPKE ciphersuite identifier, which is an IANA registry value rather than anything a primitive knows, so the instances live beside the registry in the hpke package.