John White is the Field CISO for EMEA at Torq. A respected security executive with more than 20 years of leadership experience, John previously served as CISO at Virgin Atlantic, where he led a multi-year transformation deploying the Torq AI SOC Platform to modernize cyber operations. Prior to Virgin Atlantic, he built and transformed security functions for global organizations, including ASOS, Liberty Global, AEG Europe, and KPMG.

Every CISO I speak to eventually arrives at the same meeting: the one where you have to show what the investment bought you. And almost everyone walks in to defend their AI SOC ROI with the same number: hours saved.

It’s the weakest number you can bring. It invites the obvious follow-up question about headcount, which you don’t want to answer because the answer is that you aren’t cutting anyone. Worse, it describes a fraction of what actually changed. AI SOC ROI means different things depending on who’s asking, and “how many hours did we save?” is only one form of return.

Here’s how I’d measure it instead.

Measure AI SOC ROI as an Incremental Return

Adding AI agents doesn’t mean firing analysts, so don’t frame it as money saved. Frame it as an incremental return: for the extra you spend on agents, how much more do you get back?

Take an illustrative team of 10 analysts, still overwhelmed by volume and short on coverage across controls and projects. Add an agentic layer at roughly the cost of two or three good analysts, and you can automate the vast majority of your team’s Tier 1 work. Those analysts are released from the mundane and repeatable work and reallocated to higher-value activities. Compliance improves because the team now covers more controls. Risk from machine-speed attacks drops because triage and response happen at machine speed. Re-motivated analysts start engineering and delivering new capability on timeframes you couldn’t have committed to before.

That’s a significant uplift across the board, and it would have taken a team twice the size under a traditional, human-scaled model. That’s the number to bring.

Run Two Dashboards, Not One

One transformation, two audiences. I’d split measurement into a strategic dashboard and an operational one.

The strategic dashboard tracks what the board cares about: what you spent, how headcount was reallocated, how far risk came down, whether control metrics are improving, and whether the auditors are satisfied. If you’re reporting upward, ROI might mean that risk thresholds are met, the likelihood of breach is reduced, the cost of exposure is reduced, and legal and regulatory obligations are satisfied. It might mean showing no increase in committed headcount while efficiency and control coverage both go up. It might mean proving you delivered this transformation alongside a tech debt program or an ERP onboarding without derailing either.

The operational dashboard tracks how the work itself has changed: how many people moved from operations onto projects, which roles were refactored into the new structure, and how far case resolution time has dropped. In one enterprise I know, that went from 30 minutes to two. Quality improves as well, because every case arrives enriched with more context before anyone makes a decision.

The link between the two is capacity. Freed capacity isn’t a saving sitting in a spreadsheet: it’s value you redeploy, and the strategic dashboard is where that shows up.

The Benefits Most CISOs Aren’t Measuring

The secondary effects are where a lot of the real value hides, and most teams never put a number on them.

Reallocated hours change your risk posture. Reduced exposure changes what the business sets aside for cyber insurance. There’s the story you tell a regulator, for example, about running strong, agentic security inside critical national infrastructure, and there’s the evidence you can produce for the EU AI Act and the Cyber Resilience Act. 

None of that is technical, and all of it counts. The business benefits matter as much as the operational ones.

Get the Right People in the Room

The measurement conversation can’t stay inside the SOC, and this is where I see good programs undersell themselves.

You need the GRC team, enterprise risk, and procurement involved. Often, you want your other vendors too, because they’re seeing reduced volumes and faster response on their side, and that’s evidence you can use. Bring in any IT outsourcing team that owns part of the process. Don’t forget the regulators. Each of them measures your success differently, and if you’re the only one defining the measure, you’ll define it too narrowly.

Score AI SOC ROI Across All Three Layers

I’ve written before about the three layers you’re buying with an AI SOC: outcome, judgment, and execution. Measurement works the same way, and each layer has a tangible, measurable benefit.

1. At the outcome layer, you set risk reduction targets, machine-speed defense requirements, compliance obligations, and the confidence you need to demonstrate to your board, your regulators, and your insurers. These get defined up front and measured within the judgment function.
2. At the execution layer, you measure the incremental return described above. That’s where the leverage lives, as long as you measure it the right way.
3. At the judgment layer, you measure continuous improvement, decision quality, and audit transparency. Can the system show you its reasoning? Can you tune it? Does it get better? That’s the layer that tells you whether you bought a capability or just a tool.

If a vendor can only show you the execution layer and can’t speak to judgment or outcomes, the relationship will stall. That’s worth knowing before you sign rather than after.

The Org Change That Makes the Metrics Move

There’s a hard truth underneath all of this. Without organizational change, the metrics plateau no matter how good the technology is.

Adopt the three-layer model as a product approach. Lay out your services, define the capabilities that deliver them, and measure how every capability performs. Move people into roles that understand this approach — something service- and capability-oriented — and split them into connected teams that deliver on outcomes, execution, and judgment. 

The technology gives you the capacity. The organization decides whether that capacity turns into results.

Inaction Is Its Own Risk

At the very least, after all of this, have a plan. If your plan is not to adopt an AI SOC yet, you need a justification that stands up to scrutiny, and I’d challenge you to find one. Are you saying machine-speed threats aren’t a risk to your organization? Do you have the resources to cope with current alert volumes, let alone next year’s?

Look at how fast a machine-speed attack actually moves. If your first line of defense runs at human speed, you’re handing attackers the dwell time they need before you’ve begun to respond. The exposure that comes from standing still outweighs the risk of taking a first step in the right direction. A tentative, risk-based, well-planned move forward beats waiting for a certainty that isn’t coming.

Whatever you choose, run it like a program rather than a purchase. Start with the repeatable Tier 1 work that eats the most time, prove it, measure it in terms your board and your auditors care about, and expand as trust builds.

You need a plan. Start building it now.

The full AI SOC Buyer’s Guide has the measurement dashboards, the incremental AI SOC ROI model, and the questions to bring into the room with every vendor on your shortlist.

Noam Cohen is Head of Artificial Intelligence at Torq, where he leads the AI research and engineering work that powers the platform’s agentic SOC capabilities. Noam’s work at Torq spans the core AI systems behind autonomous threat investigation, SOC memory, confidence-based decision thresholds, and the guardrails that make agentic AI trustworthy enough to act in production security environments.

The new platform is approved. The pilot went well, the budget is signed, and the team is ready to move. Then someone in the kickoff asks the question nobody planned for: what happens to our history?

Three years of closed cases. Every alert someone already proved benign. Every host that turned out to be the red team’s box. Every incident write-up that explains why a particular 2am login pattern is fine for that one service account. That history is where most of a SOC’s hard-won knowledge lives, and it sits in a schema the new platform has never seen.

The usual approaches are both bad. Spend a month building a migration pipeline, or go live with an AI that knows nothing about you and let your analysts re-teach it from scratch. Plenty of teams pick a third option: they don’t switch.

We built Torq Retrospect so that the question has a short answer. Retrospect takes your case history from whatever system holds it today and rapidly makes it usable in Torq, already validated, indexed, and recency-weighted.

Every SOC Switch Starts With Amnesia

Think about the last time you set up a new phone. Ten years ago, that meant losing half your contacts and emailing yourself photos. Now you put the two phones next to each other, and twenty minutes later, your apps, messages, and photos are just there. Nobody would buy a phone that made them start over.

SOC platforms are still in the ten-years-ago era. Switching tools, whether from a legacy SOAR, a ticketing system, another AI SOC, or an MDR’s case portal, usually means your new system starts with an empty case history.

That matters more for an AI SOC than it did for older tools. A playbook engine doesn’t care what happened last year. An AI that triages alerts does. When it sees a suspicious PowerShell execution on a finance workstation, the most useful thing it can know is that your team saw the same pattern forty times last quarter, and every one of them was a patching script. Without that precedent, the AI reasons from first principles every time (and first principles are exactly what produces the false positives your analysts are tired of closing).

Traditional Migrations Move Data and Lose the Meaning

So teams migrate. Someone exports the old cases. Then the bespoke pipeline work starts: cleaning malformed records, matching the old fields to the new ones, deduplicating cases that were merged or reopened, and converting formats that never quite line up. Teams we’ve talked to say this takes anywhere from weeks to a month, and that’s when it goes well.

Time isn’t the only problem. A traditional migration has three ways to fail quietly:

1. Loss in conversion. A field that doesn’t map cleanly gets dropped, flattened into a free-text blob, or truncated. Nobody notices until an investigation needs it.
2. No proof it worked. Ensuring nothing is lost means building a validation process alongside the pipeline. Most teams spot-check a few cases and hope for the best.
3. Imported isn’t usable. Even if every record arrives intact, the new system still has to find the right one at the right moment. Dump three years of cases into an index with equal weight, and the 2023 incident tied to a decommissioned server competes with last week’s case on the same alert type. The history is all there, and it’s mostly noise.

In 2026, there’s an obvious shortcut: Point an LLM at the old cases and have it rewrite each one in the new format. It sounds efficient. It also means a probabilistic model is regenerating thousands of records you may one day need in an audit or a post-incident review. One invented hostname or one “summarized” timeline, and your history is no longer your history.

We wanted neither.

Torq Doesn’t Recreate Your Data. We Learn How to Copy-Paste It.

The hard part of a migration was never moving bytes. It’s translation: working out that a field called src in one system, Attacker Address in another, and Origin IP in a third all mean the same thing in Torq’s data model. Field names across security tools agree only loosely. Some are obvious synonyms. Some mean the same thing only in context. Some look alike and mean different things.

That kind of loose-similarity matching is exactly what LLMs have become good at. So Retrospect uses the model where it’s strong, on the schema, and keeps it away from the records.

Retrospect works in four steps:

1. The LLM reads both schemas. It sees your source system’s fields and Torq’s case data model.
2. It proposes a mapping. Each source field has a destination in Torq’s model, including cases where the names are only mildly similar.
3. The mapping becomes deterministic. Once validated (more on that below), it’s a fixed translation. Every record goes through the same rules.
4. The records are copied, not regenerated. The value in your old system is the same as the value in Torq. The model wrote the instructions for the move. It didn’t touch the cargo.

The LLM’s work happens once per source schema, not once per case. That’s why the job takes minutes instead of weeks. It also means the thing you have to get right is the mapping, and you check it once instead of auditing every record.

Nothing Falls Through Without Someone Seeing It

A deterministic copy still raises the obvious question: what about the fields that don’t map?

Retrospect measures them. Every field the mapping doesn’t cover is counted as unmapped data, so coverage is a number you can read, not something you find out about three months later. If a source field has no home in Torq’s model, it shows up on that list. It doesn’t vanish quietly.

Then a human looks. Before the migration is called done, someone checks a representative sample of migrated cases against the source. The person checking reviews the translation on cases they recognize. They aren’t auditing a black box.

Silent drops and flattened fields, the things that make traditional migrations risky, show up before go-live instead of in the middle of an investigation.

Imported Isn’t Ready Until It’s Indexed

Getting the records across solves the first problem. Retrospect’s definition of done is stricter: the history has to be usable in triage and investigations the moment the migration finishes.

Migrated cases land in Torq’s case management already indexed, and the index knows when each case was created. Recent cases are more relevant than older ones. When Torq Recall looks for precedent on a new alert, last month’s resolution of the same pattern outweighs a two-year-old case from before your environment changed.

That keeps old data from turning into noise. You don’t need to curate your history before migrating it or decide which years are still trustworthy. Bring all of it. Recency weighting means the old cases are there when nothing newer matches, and stay out of the way when something newer does.

Two Thousand Cases, Under an Hour

One customer brought over 2,000 cases from the past year. With Retrospect, those cases went from export to imported, indexed, and ready for alert triage and investigations in under an hour. Compare that to the traditional, legacy path we described above — bespoke pipelines, cleaning, matching, and dedupe — which takes weeks to a month.

That’s just one customer’s migration. A messier source schema or many more years of history will take longer. The expensive part — translating the schema — still happens once, so more cases don’t mean more translation work.

Next, Your History Becomes Judgment

Torq Recall uses your history as memory: when a new alert comes in, it finds the precedent. That’s the first payoff, and it’s live from the hour the migration finishes.

The second payoff is Torq Reflex, which trains a model on your analysts’ past decisions, so that the AI actually learns your team’s judgment, instead of matching cases one at a time. It picks up the “we always escalate this one” instinct that no prompt captures.

A model like that needs decisions to learn from. Retrospect brings them across, each case with its analyst’s verdict attached. Your migrated history is the material Reflex learns your team’s judgment from, so it doesn’t have to start from zero after a switch.

What Torq Retrospect Means for Your Team

• Switch without starting over. Your closed cases and their verdicts come with you, in Torq’s data model, from day one.
• Minutes, not a migration project. No bespoke pipeline, no month of cleaning and matching. In the customer case above, it took under an hour.
• Your records stay your records. The LLM translates the schema once. Your data is copied, never regenerated.
• Coverage you can see. Unmapped fields are counted, and a human checks a sample, so gaps surface before go-live.
• History without noise. Recency-weighted indexing puts recent precedent first, so you can bring everything without curating it.
• The foundation for learning. The same history powers Recall today and gives Reflex the decisions it learns from.

Bring Your SOC’s Past With You

The reason teams stay on tools they’ve outgrown is rarely the tool itself. It’s everything they’ve built inside it. Every SOC that has switched platforms knows the cost: weeks of migration work, or a new system that has to be taught everything again.

The cost of adopting better technology is a thing of the past. With Retrospect, it doesn’t have to be.

Torq Retrospect is part of our series on Context, Memory, and Learning in the AI SOC, alongside Recall, Reflex, and the Torq Context Graph.

John White is the Field CISO for EMEA at Torq. A respected security executive with more than 20 years of leadership experience, John previously served as CISO at Virgin Atlantic, where he led a multi-year transformation deploying the Torq AI SOC Platform to modernize cyber operations. Prior to Virgin Atlantic, he built and transformed security functions for global organizations, including ASOS, Liberty Global, AEG Europe, and KPMG.

You’ve signed the AI SOC contract. The question I get next is always the same: where do I start? What can I turn on without worrying about it, and what do I need to watch closely?

The instinct at the start of any AI SOC adoption is to boil the ocean, to point AI at everything at once and prove the whole thesis in a quarter. That’s how good rollouts stall. The faster path is narrower. Lead with agentic triage on the work that’s drowning your team, prove it, then expand as trust builds. Here’s how the first 90 days should go.

The First 90 Days of AI SOC Adoption

Start with why you bought the platform. What are you trying to deliver, and how will you know it’s working? Get your objectives on paper, look at the processes and the team you have, and start designing the plans, automations, and agent roles that will deliver them.

Deploy agentic triage on your highest-volume Tier 1 alerts. You’re putting the plan into practice, pulling people together on a project basis, and working out whether it’s performing. Some of them will start moving into roles that aren’t in their current job description yet, designing the new structure as they go.

The basics are working, and you see real movement from human process to machine speed. Lead with agentic triage to shut the door on machine-speed threats before the noise ever crosses into your SOC, because that noise is what overruns the team first. In parallel, pick a handful of your most time-consuming use cases and automate them. That combination gives you the fastest return. This is also your first review period. You’ll have a board meeting inside these 90 days, and the C-suite, board, and audit committee will want to know what you spent, what you’re getting out of it, what the risks are, and whether there have been mistakes. Positive answers get you the green light to expand.

Start AI SOC Adoption With Triage

The best starting point for an AI SOC deployment is your highest-volume Tier 1 work: triage. It has clear processes, a clear track record of how alerts have been handled, and it’s the single biggest time sink in the SOC. Manually clearing noise is exactly the kind of high-volume, repeatable work agentic AI is built for, so agentic triage is the right first move rather than something you save for later.

There’s a compounding effect here that’s easy to miss. Automating your biggest time sink frees up hours your team can put into the next layer. You spend time now to get far more of it back later.

While triage is coming online, pick a few use cases that eat the most analyst time and automate them too. Whether each one is agentic or deterministic depends on the process. This is the quickest path to visible ROI, and it gives you something concrete to show the board alongside the triage numbers. From there, you pick off the next candidates one at a time.

When you measure it for that board conversation, be careful how you frame it. Adding agents rarely means cutting analysts, so this isn’t a story about money saved. It’s an incremental return: for the extra you invest, how much more do you get back in threats handled, time to contain, and work closed within SLA? The capacity you free up gets redeployed into higher-value work, and that redeployment is its own line of value.

Build Trust Process by Process

You don’t earn autonomy in one move. You earn it one process at a time. When outcomes match expectations and nothing goes sideways, trust builds. You’ve shown your C-suite it works, so you can sell the next phase with evidence instead of enthusiasm. Continual results earn continual buy-in.

This is also where the org starts to change, and it’s worth planning for deliberately. The analysts who set up autonomous triage are the ones who understand it best, and they move into Tier 2, engineering, and assurance roles as the layer matures. I wrote about that shift in detail in the AI SOC org chart, so I won’t repeat it here, but keep it in view: the platform handles the work, and you redesign the team around what that frees up.

The Mistake That Stalls AI SOC Adoption

The common failure I see with AI SOC adoption is handing everything to AI agents at once, without a risk-based approach. Shore up the front door first, then expand deliberately. Try to do it all in one go, and you run out of resources, and you start confusing what’s running agentically versus manually, doing part of a process one way and part another.

Shore up the front door means exactly what it says. Machine-speed attacks are already here, and human-speed response is the lag attackers exploit. Get your highest-volume triage running at machine speed, prove it, measure it in terms your board and your auditors care about, and grow from there. That’s how you turn a tool into an operating model and bring the organization with you.

The full guide lays out the 90-day plan, the measurement dashboards, and the questions to ask a vendor about how they’ve done this with other teams.

David Melamed is Head of Emerging Technologies at Torq. He joined through Torq’s acquisition of Jit, which he co-founded and has led as CTO since 2020, building agentic security on a production Context Graph. A cloud security veteran with 20+ years of experience, David previously held senior technical roles at Cisco (via the CloudLock acquisition) and MyHeritage.

For all the gods and monsters in The Odyssey, the ship mostly moves for one reason: men row it. Divine wind is promised often and arrives sometimes, but it never lasts. Sooner or later, the sail goes slack, and the crew bends back over the oars and moves the ship the only way that reliably works, by hand.

Security operations were promised a wind, too. We called it SOAR (which stands for Security Orchestration, Automation, and Response), and the pitch was that you would set it up once and the SOC would start to run itself. How convenient, right?

But… it never did. And understanding exactly why it did not is the difference between falling for the same promise a second time and knowing what to demand instead.

Here is the claim up front. SOAR’s automation worked. What failed was the idea behind it: that enough flowcharts, stacked together, would add up to a SOC that runs itself. The industry is about to repeat that mistake with AI, and the only protection is to demand proof before you buy the promise.

We Have Heard This Promise Before

SOAR arrived as the answer to the problem described in the first and second posts in this series: too many alerts, too few people, and decisions that would not scale. The pitch was clean: encode your analysts’ playbooks once, wire the tools together, and the machine runs the repetitive work while humans supervise. In a nutshell: the self-driving SOC.

Teams bought it, built it, and then found out what they had actually bought.

What You Actually Bought Was Maintenance

A playbook automates the steps a human mapped in advance. That works for the narrow, stable path: this specific alert type, this enrichment, this ticket, this case. But unfortunately, security does not stay on the narrow path. A new detection, a renamed field, an unexpected response from a tool, an edge case nobody foresaw, and the playbook breaks, usually quietly, and usually at the worst moment.

So someone has to keep it alive. Every integration change, every new alert source, every tuning cycle adds to a backlog of playbook upkeep. The automation that was supposed to free the analyst turned the analyst into its mechanic. Ask anyone who has lost a Friday afternoon to a playbook that broke because a third-party vendor quietly renamed a field. The work did not disappear. It just moved from investigating alerts to maintaining the thing that was supposed to investigate alerts.

And it shows up in the data, not just in the war stories: 80% of security leaders say they rely on disconnected point tools, 80% say that fragmentation creates operational complexity, and 85% would prefer a single unified platform. The wiring was never finished because in a stack that keeps changing, it never can be.

The Mistake Was Deeper Than Brittleness

Brittleness was the symptom. But the real reason SOAR could never deliver autonomy lies in the premise beneath it.

SOAR asks you to encode judgment as part of the flowchart. But the hard part of a Tier 1 analyst’s job is not executing known steps. It is deciding what to do when the situation matches no known step. That is judgment, and judgment is not a decision tree with more branches bolted on. You cannot pre-write the response to a case you have never seen. So the exact work that would define an autonomous SOC, handling the alert nobody scripted, was the one thing a playbook, by its nature, could not do. SOAR automated everything except the part that actually required an analyst.

To be fair to the category, orchestration and automation were never the problem, and they are not going away. Wiring tools together and executing a known response at machine speed is real value. The error was believing that enough of those wired-together steps would add up to judgment. They never do.

The Same Promise Is Back on the Table

Now a new generation of vendors promises autonomy again, and most of the demos look exactly like the self-steering ship: clean data, a confident verdict, a slide that says “autonomous.” The lesson from SOAR is not to stop believing in automation. It is that the promise and the proof are different things, and the gap between them only shows up after you have signed, when the platform meets your real stack, your real volume, and your real compliance rules.

So treat the new promise the way a burned crew treats a fresh guarantee of fair winds. Make it prove it holds in your environment before you trust it to carry the ship. Ask the questions a polished demo is built to avoid:

• Can it reason across your whole stack, or only the clean slice on the slide?
• Can it show its work, or only hand you a verdict?
• Can you govern what it is allowed to do?
• Can it prove impact with named customers and real numbers, not logos on a wall?

Torq published a list of 20 such questions for exactly this reason: the honest answers are what separate a real AI SOC from a repackaged one, and we would rather you ask them of everyone, us included.

What SOAR Could Never Do

There is one thing that genuinely separates this wave from the last, and it is not more automation. It is reasoning: the ability to make sense of context and work an investigation that no one pre-scripted, choosing the next step based on what the last step turned up, the way a human analyst does. That is the single capability a flowchart could never capture, and it is why the autonomous SOC is finally a real conversation rather than a rerun of 2016.

Odysseus got home the moment he stopped waiting for a wind to do the work for him and started navigating by judgment. Security operations are at the same point. SOAR was the last promised wind. What comes next is not a better flowchart. It is a different kind of propulsion.

Next in this series: From playbooks to reasoning, what agentic AI actually changes, and why it can finally do the one thing SOAR never could.

John White is the Field CISO for EMEA at Torq. A respected security executive with more than 20 years of leadership experience, John previously served as CISO at Virgin Atlantic, where he led a multi-year transformation deploying the Torq AI SOC Platform to modernize cyber operations. Prior to Virgin Atlantic, he built and transformed security functions for global organizations, including ASOS, Liberty Global, AEG Europe, and KPMG.

Every vendor in this category now says the same word: agentic. I understand why. It’s what the market wants to hear. But when you’re the one signing the contract, “agentic” tells you almost nothing. I’ve sat on the buying side of enough of these conversations to know that the label and the capability are often two very different things.

The SecOps industry spent the last two years proving that a large language model can read an alert and produce a credible analysis on day one. That was a real breakthrough, and it was the relatively easy part. Every vendor now builds on the same handful of frontier models, so reasoning on its own no longer sets anyone apart. 

What’s harder, and what actually separates one platform from another, is the layer beneath the agents: the context that grounds a decision, the memory that gives it precedent, and the learning that teaches it your team’s judgment. A model that reasons well but forgets every decision it makes, misses the context of your environment, and never learns your analysts’ judgment will hand you confident wrong answers at scale.

You don’t need a data science degree to tell the difference. Three questions do most of the work, and they map to the three AI SOC differentiators that actually matter. Can the platform reason about your environment, learn from your analysts, and act with control? Context, memory, autonomy. 

Differentiator 1: Context: Can It Reason About Your Environment?

Not all AI reasoning is equal. The real differentiator is whether an AI SOC tool understands your environment or just processes your alerts.

The clearest way I’ve found to frame it is as a knowledge graph versus a context graph. A knowledge graph tells you what you have: assets, identities, network topology. That’s an inventory. A context graph determines what all of that means: the relationships, the interaction patterns, what’s normal and what’s abnormal in your specific environment.

Context in isolation leads to poor decisions. A phishing alert judged through your email gateway alone looks very different once identity data, endpoint telemetry, and network behavior feed into the same determination. That’s an architectural requirement, not a marketing claim: multiple data points reasoning together on one platform.

In an AI SOC demo, I’d ask the vendor to show me how the platform uses its integrations, where the data goes, and whether a single determination draws on more than one source or each integration sits in its own silo. The risk of not asking is ending up with something that carries an AI label but behaves like a collection of disconnected tools. A platform that can’t reason across your whole environment will make ‘confident’ decisions on partial information, and that’s worse than no decision at all.

Differentiator 2: Memory: Does It Learn, or Just Respond?

This is the question most vendors gloss over, and the one that separates a platform that scales from one that stays stuck at triage.

There are two kinds of memory that matter, and they do different jobs. 

1. The first is precedent: Has your SOC seen this exact thing before, and what did your team decide? Torq Recall does this with exact matching on real observables like IPs, file hashes, and hostnames, so an old verdict only counts when it’s genuinely relevant. 
2. The second is judgment: How does your team actually rule, and what evidence do they demand before they escalate? Torq Reflex learns over time and applies that learning to alerts it has never seen before.

The tell is what happens on day 100. An AI SOC platform that learns runs a continual improvement loop: it makes a determination, stores what it learned, and applies it the next time the same question comes up. What I call “the next better decision”. An agent without memory reasons from scratch every time. It may land on a good answer, but it doesn’t carry forward what it found or what your analysts corrected, so it re-investigates the same benign pattern next week and can call the same alert differently on Monday and Tuesday.

Here’s my favorite way to cut through it: product, not promises. Every vendor says their platform “learns.” Ask them to prove it. How are the models trained and maintained? Can you show me a case where past precedent changed a verdict? Can you show me the accuracy curve over time, not just a day-one benchmark? If a vendor can’t describe that ongoing work, the learning claim is hollow.

Differentiator 3: Autonomy: Can It Act With Control?

Every vendor claims to be autonomous. Two things decide it: whether the platform exercises sound judgment and whether it can show you the receipts.

Start with how the agents are built: their roles, permissions, purpose, and the environments and timings in which they can operate. Then ask how granular they are. Like a human analyst who accrues permissions across role changes and never gets them decommissioned, an agent with too much responsibility ends up with keys to too many kingdoms. What you want is precise control over exactly what data each agent can touch, which actions it can take, and under what conditions, with anything outside that carved into a separate agent.

Assurance lives in the audit trail. You need to inspect any point of a decision, see why it was made, and keep the ability to change it. When an analyst disagrees with an outcome, the system should accept the correction and fold it into the next determination. If you can’t get into the reasoning and change it, you’re looking at a black box, and a black box has no place acting autonomously in your environment.

The framing that matters most: autonomy is a dial you set, not an all-or-nothing switch. You start eyes-on and skeptical, verify the outcomes against what a good analyst would have done, and widen the dial process by process as trust builds. Where to draw the line between autonomous action and escalation isn’t the vendor’s decision. It’s yours.

The AI SOC Differentiators That Hold Up on Day 100

A real platform answers these questions with specifics. When you ask how it reasons, how it learns, and how it’s governed, you should hear about a bitemporal graph that stays isolated to you, deterministic retrieval that weighs signal strength, and a per-tenant model with a calibrated confidence score and an audit trail you can open. A vendor that can only give you “fully autonomous” and “self-learning” is deflecting.

The next model release won’t fix any of this. It’s in your environment, your history, and your analysts. That’s exactly why the AI SOC differentiators worth paying for sit beneath the agents rather than in them. A day-one demo can be dressed up by anyone. What tells you the truth is the foundation on day 100, after months of your alerts and your corrections have run through it. Ask who is still learning by then. And it all comes down to a simple test: If it can’t take action across the threat lifecycle, it isn’t an AI SOC.

Context, memory, and autonomy are the short-form AI SOC differentiators that matter. The AI SOC Buyer’s Guide turns them into questions to bring into the room, with the specific things to ask under each one.