vSphere 7 Update 1 added a new "vSphere Clustering Service (vCLS)" and according to the doc:
Basic Architecture
The basic architecture for the vCLS control plane consists of maximum 3 virtual machines (VM), also referred to as system or agent VMs which are placed on separate hosts in a cluster. These are lightweight agent VMs that form a cluster quorum. On smaller clusters with less than 3 hosts, the number of agent VMs is equal to the numbers of ESXi hosts. The agent VMs are managed by vSphere Cluster Services. Users are not expected to maintain the lifecycle or state for the agent VMs, they should not be treated like the typical workload VMs.
It's very confusing to me how these vCLS VMs can help provide Clustering Service. These VMs even don't have network adapters so they cannot directly talk to each other. It's the cluster's ESXi hosts who are actually exchanging their status info. So technically speaking, an ESXi service (running as processes) can do whatever the vCLS VMs can do.
Try Googling "vsphere disable vcls" and you'll see this new feature really introduced some confusion to users. So what's the point of using the vCLS VMs?
"so they cannot directly talk to each other" - there's more ways for VMs to talk to each other and to vCenters than just ethernet/IP.
Since DRS and HA were introduced they were essentially dependant on the vCenter being up - the VC decided what VMs to move for DRS and orchestrated the hosts moving them, and HA needed the VC to help coordinate the HA voting process and plan the 'failure map'.
vCLS allows for both DRS and HA to not only continue in the absence of a VC but also to allow HA voting and plans to evolve based on host availability with the VC in place. Think of it as the <7.0u1 VC DRS and HA functions shipped out of the VC into a three-way cluster to do this role for it - does that make sense?
Anyway just ignore them, they're effectively self-managed, by all means stick them in their own VM folder to hide them away but don't worry about them.