https://en.m.wikipedia.org/wiki/Integrated_Encryption_Scheme
This is intuitively similar to how TLS works, in which asymmetric concepts are used in conjunction with a KDF and hashing algorithm to agree upon a per-session symmetric key.
How TLS 1.3 works.
This way of proceeding was introduced earlier, but wasn't the only option until TLS 1.3, in TLS 1.2 for example, even though chances are any TLS 1.2 sites you run offer a more modern Elliptic curve scheme, it was mandatory to implement TLS_RSA_WITH_AES_128_CBC_SHA.
For TLS_RSA_WITH_AES_128_CBC_SHA (and many other schemes) RSA is being used to transport the session keys chosen by the client (and thus implicitly authenticate the server). This means if an adversary gains possession of the server's RSA private key, even perhaps several years later, that's enough to decrypt the session key and thus decrypt all messages that adversary might have captured before.
Whereas with the schemes using Ephemeral Diffie Hellman (whether conventional or elliptic curve) once those ephemeral values are discarded going forward the only way to decrypt the messages secured by them would be something like Shor's algorithm to break DH, hence the term "Forward Secrecy".
It's impossible to accidentally encrypt a message with the asymmetric cryptographic primitive in the ECC case, but not in the RSA case. This makes ECC misuse-resistant in a way that RSA isn't.
(Although, strictly speaking, you can "encrypt directly" with elliptic curve schemes if you use ElGamal--which might even be desirable in weird systems. Fortunately, most high-level cryptography libraries that offer ECC don't expose the APIs to facilitate this.)