I'm a bit confused - agent vs. agentless isn't obviously correlated to continuous vs. on human action to me. Write a cronjob / systemd timer / scheduled task / Jenkins job / Travis cronjob / GitHub Actions scheduled event / CloudWatch + Lambda / whatever you like to run your Ansible playbook, from one machine/container/whatever, on your entire fleet. (It's certainly no harder than writing a cronjob or whatever to run your config management on every machine - if you can schedule tasks on all your machines, you can certainly schedule them on one.)

That gets you the standard advantages of agentless setups, including not requiring the runtime of your config management tool to be everywhere, being able to reprovision ephemeral + immutable cloud resources, and being able to centrally report errors, without any more risk of configuration drift or bitrot.

while ansible does push more commonly (and checkout mitogen for speed increases there), its also trivial to do pull mode with some loss of multi-node orchestration, and just cron/systemd timer it.

Have also had issues with agents in high security areas.

Machines sitting behind VNets, governed by security review boards makes getting agents approved a bit tricky

This behaviour is why I'm using (and liking) Chef these days, where six years ago I absolutely hated Chef.

I still love Ansible, especially for small quick things. As with many tools, though, it's not the only one I reach for any more.

Salt agents in particular call out to the master making NAT a non issue. While it does have problems of its own (connection scaling), it made automating servers across 600 physical locations much easier.

I manage thousands of machines with rrconf