> I want to iterate on that thought a little further: Is this an effect that was caused by shitty tooling?
Not shitty tooling per se, but ineffective communication, which can limit the actionability or requires context switches on the operators side. MITREs ATT&CK framework is helping solve some of these symptoms by tying things back to tactics/techniques and a common taxonomy, but there is still a long way to go.
> With the peer-to-peer approach of our Agent, we can mitigate most of the critical issues automatically, and the deployment and rollout/update strategies are also measured in whether or not they affected the health status
Most companies are trying to have less agents on their boxes, not add more. Tools that are agentless tend to have much greater chances of success, even if that means having a more complex architecture.
eBPF + SSH configuration of for example a local log system or even pushing a collector/broker can be your best bet.
You want to avoid an agent when selling to security people for 2 big reasons:
1) most of the time, security teams will not own the systems they want to put agents on, they have to get permission from the app/service owners and many times there is significant pushback. Many, if not most orgs have been burned by "just deploy this agent, there isn't a performance impact".
2) when you don't own the systems, you can increase the sales cycle and complexity of the sale, since you now are effectively requiring multiple groups to agree on something and agree that this is a priority. If there is disagreement, you can get vetoed by a group that wouldn't even be responsible for it.
I am 100% not telling you that agents are impossible, but in most enterprises, it will be more difficult than you think to get it deployed. It might take what is normally a 3 month proof of concept to something that is 6 or 12 months, or could kill it before even starting.