We do not utilize the AI features that much. When it comes to general AI features of Torq, we are just slowly starting to implement them because I feel that not just Torq, but most companies are just starting to figure out how best they can utilize it. It is not something we have found a lot of value in yet. Personally, I have not utilized it enough. It is a two-way road where I did not see enough value in it and I did not give it enough attention yet. It is not personally the tool we go to for that purpose. It is not something I think we adopted for that purpose. I am not saying it is a pivot of theirs, but because it is something that we have not given enough attention yet, we rely on other tools in our stack to be that center point. We have not used something previously, and Torq has been one of the tools in our growing stack. It is something that is always available as other tools, but we have not picked it internally as our AI SOC tool. Because we have not seen enough value, I cannot give you a lot of information about that. In general, in the niche that Torq is in the market, I think the biggest comparison they get is with N8N. Whenever I see a demo of them or look at a video or documentation, I always say that I would rather pick Torq over it. I feel that it is not just because I am used to it at this point; it was the best way to get into this kind of niche in the market. N8N is not hard and is also easy to get into, but for our use case, Torq, even when we started and it had fewer features than it has now and fewer steps that we can do in the workflow, filled our gap very quickly. It was immediately usable for our use case. That is the strong point. We always strive for more features. I find myself sitting sometimes in front of a workflow wondering why it works this way because it feels like a convoluted way of doing this step. However, it is still something I can do. It is a good point and a bad point about Torq. I do not remember the last time I sat in front of trying to build something in Torq and said to myself that this is impossible and the platform does not allow it. There is always a way to do it. It might just not be the smartest way to do it. When I compare it to a lot of other applications we work with, most of the time, you just cannot do it and it becomes a feature request. Usually, nine out of ten times, if I have a problem with Torq, it is just that I do not the way I need to do something more so than that I just cannot do it. Their AI is an area for improvement. When I heard about them implementing these features and going to agentic approaches, and when they showed us the AI features about a year ago, I became very harsh on AI features in general in the market because every company introduced them without a lot of value in it. Torq has a very difficult game to play where AI steps, on one hand, ruin the point of their workflows, and on the other hand, if implemented well, can be utilized amazingly. When you build a workflow in Torq for at least our use case, you want some sort of rigidity. I want to know that I will always get the same result that I want. The second you put in any AI step, you cannot guarantee that result. If you ask ChatGPT the same question ten times, you might get ten different answers. Torq has a very hard problem of how to implement AI as a model that you use in a step but still get ninety-nine out of one hundred times the result you want, which is usually good enough. Even today, and especially at first, I was not happy with a lot of AI features because I do not see a lot of value in them. Even now, we have workflows that are in production that use AI steps and I get different results, making it unusable to some degree. I try to implement AI steps, give it a couple of runs, and I see that it has about an eighty percent success rate of what I want. I need to go back to rigid steps. It is a good and bad point where I appreciate that they pivot into it, but I do not think it is at a good place right now, at least for our use case, because it negates the point of rigid workflows. There are a lot of small things about Torq where quality of life changes are needed, but that comes with no-code automation in general. Eventually, you build a huge branching tree of steps and it might be hard to navigate and might lag a little because it is huge. It is a very nice UI, but when you build enormous workflows as we do for our use case, it gets hard to navigate sometimes. It is not unusable and easy to jump back into, just hard to maintain. That is the price you pay with no-code automation in general.
Regarding the downsides of Torq, one issue is that as a SaaS product, I sometimes encounter transparency issues about what is going on behind the scenes, necessitating contact with Torq support to get logs in certain situations. From an engineering perspective, I think more error messages and error handling information for our engineering team would be very helpful.
From our research and testing with the tool, we determined there need to be modifications and changes to train the LLM on the back end. It was able to capture data but was unable to differentiate between the agent hostname we are using and the hostname that resides on the back end of the Internet. It was unable to do that sort of classification. We concluded this tool would be more suitable for initial ticket management rather than security automation. Regarding data handling, I would give preference to Torq. For case management, Cortex and its dashboards prove more useful. Cortex and Palo's solutions do not have as much capability as Torq provides with the same tools. However, Torq's dashboards could be improved, especially on the case management side.
Torq is the enterprise AI SOC solution that effectively combines adaptive insights and automation to handle critical threats efficiently. It manages threat lifecycles, swiftly moving from triage to response, ensuring effective risk management.Torq is designed to streamline security operations by aggregating telemetry across your security stack. It investigates significant risks and manages threats from triage to containment and remediation. This AI-driven tool enhances the capabilities of...
We do not utilize the AI features that much. When it comes to general AI features of Torq, we are just slowly starting to implement them because I feel that not just Torq, but most companies are just starting to figure out how best they can utilize it. It is not something we have found a lot of value in yet. Personally, I have not utilized it enough. It is a two-way road where I did not see enough value in it and I did not give it enough attention yet. It is not personally the tool we go to for that purpose. It is not something I think we adopted for that purpose. I am not saying it is a pivot of theirs, but because it is something that we have not given enough attention yet, we rely on other tools in our stack to be that center point. We have not used something previously, and Torq has been one of the tools in our growing stack. It is something that is always available as other tools, but we have not picked it internally as our AI SOC tool. Because we have not seen enough value, I cannot give you a lot of information about that. In general, in the niche that Torq is in the market, I think the biggest comparison they get is with N8N. Whenever I see a demo of them or look at a video or documentation, I always say that I would rather pick Torq over it. I feel that it is not just because I am used to it at this point; it was the best way to get into this kind of niche in the market. N8N is not hard and is also easy to get into, but for our use case, Torq, even when we started and it had fewer features than it has now and fewer steps that we can do in the workflow, filled our gap very quickly. It was immediately usable for our use case. That is the strong point. We always strive for more features. I find myself sitting sometimes in front of a workflow wondering why it works this way because it feels like a convoluted way of doing this step. However, it is still something I can do. It is a good point and a bad point about Torq. I do not remember the last time I sat in front of trying to build something in Torq and said to myself that this is impossible and the platform does not allow it. There is always a way to do it. It might just not be the smartest way to do it. When I compare it to a lot of other applications we work with, most of the time, you just cannot do it and it becomes a feature request. Usually, nine out of ten times, if I have a problem with Torq, it is just that I do not the way I need to do something more so than that I just cannot do it. Their AI is an area for improvement. When I heard about them implementing these features and going to agentic approaches, and when they showed us the AI features about a year ago, I became very harsh on AI features in general in the market because every company introduced them without a lot of value in it. Torq has a very difficult game to play where AI steps, on one hand, ruin the point of their workflows, and on the other hand, if implemented well, can be utilized amazingly. When you build a workflow in Torq for at least our use case, you want some sort of rigidity. I want to know that I will always get the same result that I want. The second you put in any AI step, you cannot guarantee that result. If you ask ChatGPT the same question ten times, you might get ten different answers. Torq has a very hard problem of how to implement AI as a model that you use in a step but still get ninety-nine out of one hundred times the result you want, which is usually good enough. Even today, and especially at first, I was not happy with a lot of AI features because I do not see a lot of value in them. Even now, we have workflows that are in production that use AI steps and I get different results, making it unusable to some degree. I try to implement AI steps, give it a couple of runs, and I see that it has about an eighty percent success rate of what I want. I need to go back to rigid steps. It is a good and bad point where I appreciate that they pivot into it, but I do not think it is at a good place right now, at least for our use case, because it negates the point of rigid workflows. There are a lot of small things about Torq where quality of life changes are needed, but that comes with no-code automation in general. Eventually, you build a huge branching tree of steps and it might be hard to navigate and might lag a little because it is huge. It is a very nice UI, but when you build enormous workflows as we do for our use case, it gets hard to navigate sometimes. It is not unusable and easy to jump back into, just hard to maintain. That is the price you pay with no-code automation in general.
Regarding the downsides of Torq, one issue is that as a SaaS product, I sometimes encounter transparency issues about what is going on behind the scenes, necessitating contact with Torq support to get logs in certain situations. From an engineering perspective, I think more error messages and error handling information for our engineering team would be very helpful.
From our research and testing with the tool, we determined there need to be modifications and changes to train the LLM on the back end. It was able to capture data but was unable to differentiate between the agent hostname we are using and the hostname that resides on the back end of the Internet. It was unable to do that sort of classification. We concluded this tool would be more suitable for initial ticket management rather than security automation. Regarding data handling, I would give preference to Torq. For case management, Cortex and its dashboards prove more useful. Cortex and Palo's solutions do not have as much capability as Torq provides with the same tools. However, Torq's dashboards could be improved, especially on the case management side.