its not JAMF... the jamf binaries use hardly any cpu... but it could be something you've deployed via JAMF.. like an AV or something that is not configured correctly. . As for the restart.. time to look at the logs.. 

Was just gonna ask if you use any AV or security related agents?

Also, you're on 12.1? Try upgrading the clients to the latest macOS 14 if you're organization allows. At the very least, you could update from 12.1 to 12.7.3.

https://support.apple.com/en-us/HT201222

You can always check the device logs for Jamf at /var/log/jamf.log to see what Jamf is doing – might not be jamf itself, but it could be some policy/install/script that's hammering the device and this log will show what policies are running.

If you are newly deploying Jamf, this is just typical pushback. I'd ignore it and move on, people love to complain and attribute every single issue they see to a new MDM client. Also never accept a preconfigured device into MDM, make devices wipe and load. You must "own" any preexisting issues if you are not wiping devices before enrollment.

If Jamf is not new, the 1st place I would look is activity monitor. It is very unlikely that Jamf is causing any performance issues unless you have a policy that is configured incorrectly, it is more than likely a security tool you are installing which would be supported by the team that owns that given tool. Checking Activity Monitor will show you what is eating the Macs resources.

For example, this is an issue in our environment being caused by one of our security clients. The security team is trying to attribute the issue to Jamf. However, we can verify the faulting process and the parent process. Most security teams are practically useless when it comes to troubleshooting and managing their tools on macOS, but that does not remove them from the responsibility.