How the parameter set to use is established depends on the (application) protocol entirely. They need to be established before the key agreement operation takes place, but there aren't really any other requirements. Usually they are shared by name or OID (short for Object Identifier usually encoded using Abstract Syntax Notation One or ASN.1) in the protocol, but it is also possible to just allow a single curve for a specific (version of) a protocol. Quite often the domain parameters are simply listed and given an index number in a protocol as well, if just to save space.
Sometimes the entire set of parameter values are simply send over (which is what I would call "sharing"). This is for instance the case for some smart card based protocols as it is a bit unwieldy to store all the curves in the limited storage available. In general you want to trust the party that sends over the parameters though. If some curves or sizes are optional then you may need to come to some kind of agreement between the parties about which curve to use, although I haven't seen many flexible protocols like that. Sharing parameters isn't all that common, usually well known curves are used so there is no need to share the parameter sets.
When it comes to card verifiable certificates in ePassports, the root certificate defines which domain parameters are to be used. The underlying keys (it contains 3 levels) will always use the same curve as the root. And staying with ePassports, there is also a scheme called PACE where the new domain parameters are calculated from a previous set (the sets only differ w.r.t. base point G of course, not the entire set).