SOC Analyst Experience: Tooling, Toil and Retention

The average security operations center loses a quarter of its analysts every year, and the ones who stay spend most of their shift clicking through consoles instead of hunting threats. This is not a staffing problem — it is an operating model problem, and it will not be solved by hiring faster than people quit. This article lays out the architecture, workflows and metrics required to rebuild the SOC around analyst experience as a first-class design constraint, with agentic AI doing the triage so humans can do the judgment.

The hidden cost of a broken operating model

Every SOC leader has seen the numbers: median analyst tenure of twelve to eighteen months, attrition rates between 20% and 40% depending on the survey, and a replacement cost that runs six to nine months of fully loaded salary once you account for recruiting, onboarding and the productivity gap while a new hire ramps. What rarely gets modeled is the second-order cost — the detection debt that accumulates while a SOC is perpetually re-training its bottom two tiers. Institutional knowledge about which alerts are noisy, which business systems generate benign anomalies at month-end, and which threat actors have historically targeted the organization walks out the door with every departing analyst. The SOC does not just lose a person; it loses a working memory that took a year to build.

The instinct in most organizations is to treat this as a tooling problem and buy another dashboard, another SIEM correlation rule pack, or another vendor's threat intelligence feed. But tool sprawl is usually a symptom of the same disease that drives attrition: nobody designed the analyst's day. A Tier 1 analyst in a typical enterprise SOC context-switches across eight to fourteen distinct tools per shift — SIEM, EDR console, ticketing system, threat intel platform, sandbox, email security gateway, identity provider logs, cloud security posture dashboard, and a Slack or Teams channel for escalations. Each tool has its own authentication, its own query language, its own data model for the same underlying event. The cognitive tax of translating a phishing alert from the email gateway's vocabulary into the EDR's vocabulary into the SIEM's vocabulary is toil, and toil compounds into burnout faster than raw alert volume does.

Rebuilding the SOC for the AI era starts with an honest inventory of where the operating model creates friction rather than an assumption that more automation rules will fix it. That inventory has to cover three dimensions simultaneously: the roles and career paths analysts occupy, the detection engineering discipline that feeds them signal, and the metrics that tell leadership whether the system is actually improving or just moving the toil somewhere less visible.

Defining and measuring toil

Google's SRE literature popularized "toil" as manual, repetitive, automatable work that scales linearly with service growth and carries no enduring value. The SOC equivalent is sharper and more corrosive because the manual work is not just operational overhead — it is the primary interface between the analyst and the mission they signed up for. Nobody joins a SOC to copy IOCs between a threat intel feed and a SIEM watchlist by hand, yet that is exactly what happens in organizations that have not invested in enrichment automation.

To manage toil you have to measure it, and most SOCs do not have an instrumented definition of what counts. A useful taxonomy breaks SOC work into four buckets:

• Judgment work — deciding whether an ambiguous signal represents true positive intent, scoping blast radius, deciding containment actions with business context. This is the work that justifies a human analyst's salary and cannot currently be fully delegated to a model.
• Investigation work — pivoting across data sources to build a timeline, correlating identity, network and endpoint telemetry. Partially automatable today, and the highest-leverage target for agentic assistance.
• Enrichment toil — looking up a hash on VirusTotal, checking an IP against a geolocation database, pulling a user's manager and department from the directory, copying results back into a ticket. Fully automatable and should never touch a human queue.
• Administrative toil — updating ticket status, writing shift handover notes, filling in compliance fields that a downstream audit will check six months later. Fully automatable, and the single biggest driver of analyst disengagement because it produces zero sense of accomplishment.

Once you tag work against this taxonomy, the diagnostic question becomes simple: what percentage of a shift is enrichment and administrative toil versus judgment and investigation? In SOCs we have assessed, that split frequently runs 65/35 in favor of toil, and the SOCs with the worst retention numbers are consistently the ones where the split is most lopsided. Flipping that ratio toward judgment and investigation work is the single highest-leverage retention intervention available, ahead of compensation increases, because it changes what the job actually is, not just what it pays.

Measuring this requires instrumenting the SOAR or case management platform to tag time-in-status against the four buckets, not just against SLA timers. Most ticketing systems already capture enough timestamp granularity to reconstruct this if you add a classification field to the alert-closure workflow. The overhead of tagging is trivial compared to the diagnostic value: a monthly toil ratio report becomes as important to a SOC manager as MTTR.

The analyst experience stack: what good tooling architecture looks like

Analyst experience is an architecture decision before it is a UX decision. The number of screens an analyst has to touch to close a case is a direct function of how many independent data planes the organization has stitched together with brittle point integrations, versus how much is unified behind a single case interface. There are three architectural layers worth separating cleanly, because conflating them is what produces the eight-tool shift.

The telemetry foundation is table stakes: log and event normalization to a common schema (OCSF or an internally maintained equivalent) so that a process-creation event from an endpoint agent and a process-creation event from a different EDR vendor land in the same field structure. Most mature SOCs have this, at least for the tools they standardized on five years ago. Where SOCs consistently under-invest is the middle layer — the correlation and enrichment fabric that takes a raw alert and, before a human ever sees it, attaches identity context (is this user a privileged account, did they recently change roles), asset context (is this host a domain controller or a marketing laptop), and threat context (has this indicator been seen in the last ninety days across any other tenant or business unit). Skipping this layer is what forces analysts to manually pivot across eight consoles, because the platform is asking them to do in real time, under SLA pressure, what should have been pre-computed asynchronously.

The top layer, the unified workbench, is where analyst experience becomes visible and measurable. A well-designed workbench presents one case, one timeline, one action panel, regardless of how many underlying tools contributed telemetry. The test for whether a SOC has actually achieved this or is faking it with an embedded iframe wrapper is simple: can an analyst take a containment action — isolate a host, disable an account, block an indicator — without leaving the case view and without re-authenticating to a different console? If the answer is no, the workbench is cosmetic, and the toil has simply moved from tool-switching to tab-switching, which still fragments attention and still shows up in mean-time-to-respond numbers.

This is the architectural thesis behind an agentic SOC: rather than asking humans to be the integration layer between disconnected tools, an orchestration layer of specialized agents does the stitching, the enrichment, and the first-pass correlation, and surfaces a pre-investigated case to the analyst with a recommended action and the evidence chain that supports it. That does not remove the analyst from the loop — it removes the analyst from the plumbing. Platforms built around an AI-native stack treat this correlation fabric as the central design object rather than a bolt-on, which is why the distinction matters more than any single feature comparison.

Detection engineering as a first-class discipline

Most SOCs still treat detection content as something a vendor ships and an analyst tunes reactively after a false-positive storm. That model does not survive contact with an adversary landscape where technique variants rotate every few weeks and where the same detection logic has to run consistently across cloud, on-premises and increasingly air-gapped environments with no ability to pull down live threat feeds. Treating detection engineering as a proper software discipline, with its own lifecycle, is what separates SOCs that get ahead of the threat landscape from SOCs that are permanently one incident behind it.

A functioning detection engineering lifecycle has five stages, and skipping any one of them is where most programs quietly fail:

1. Hypothesis and coverage mapping — detections are written against a framework, typically MITRE ATT&CK, with an explicit coverage map showing which techniques have detections, which have partial coverage, and which are intentionally out of scope because the organization has accepted the risk or has compensating controls elsewhere.
2. Detection as code — detection logic lives in version control, not in a vendor console's rule editor. Every rule change goes through a pull request, has an owner, and has a changelog. This is the single biggest process upgrade available to a detection engineering team and it is shockingly rare in practice.
3. Backtesting against historical data — before a new rule goes live, it runs against thirty to ninety days of historical telemetry to estimate false-positive rate and true-positive recall against known incidents, rather than being tuned live against production alert queues where every false positive costs an analyst's attention.
4. Staged rollout with shadow mode — new detections run in a non-alerting shadow mode for one to two weeks, logging what they would have fired on, before being promoted to an alerting rule that reaches an analyst queue.
5. Continuous tuning with feedback loop — every analyst disposition (true positive, false positive, benign true positive) feeds back into the detection's performance metrics automatically, rather than requiring a quarterly manual review that nobody has time to run.

The feedback loop is where agentic AI changes the economics meaningfully. Historically, closing that loop required a detection engineer to manually pull disposition data out of the case management system, join it against rule identifiers, and produce a spreadsheet. That is exactly the kind of enrichment and administrative toil described earlier, except it falls on your most senior and hardest-to-replace people rather than Tier 1 analysts. An agent that continuously tracks precision and recall per detection rule, flags rules that have crossed a false-positive threshold, and proposes a tuning diff based on the pattern of false positives it has observed, turns a quarterly manual chore into a standing, always-current dashboard. This is the same principle that underpins AI-driven alert triage: the model does not replace the detection engineer's judgment about whether a tuning change is safe, but it removes the labor of finding the pattern in the first place.

Detection debt and the graveyard of rules

Every SOC accumulates detection debt — rules written by an analyst who has since left, tuned against an environment that has since changed, that nobody has the confidence to delete because nobody remembers why they were written. This debt is invisible until you run a coverage audit and discover that 40% of your active rule set has not fired a true positive in eighteen months, while contributing a steady stream of false positives that consume analyst attention every single day. A quarterly detection debt review, where every rule that has not produced a true positive in the trailing two quarters is either justified, retuned, or retired, is one of the highest-return, lowest-cost interventions a detection engineering team can run. It directly reduces the noise floor that Tier 1 analysts wade through, which is the single largest driver of alert fatigue.

Redesigning roles: from tiers to pods

The classic Tier 1 / Tier 2 / Tier 3 model was designed for a world where alert volume was low enough that a triage funnel made sense: junior analysts filter, escalate the ambiguous cases, and senior analysts and incident responders handle what's left. That model breaks down under modern alert volumes for a structural reason — it concentrates the most repetitive, least rewarding work entirely on the newest, most flight-risk employees, and it creates an implicit promise ("get through Tier 1 and you'll do real analysis") that most organizations cannot deliver on fast enough to retain people who are already fielding recruiter calls after eight months.

An alternative that has worked well in organizations further along the agentic SOC maturity curve replaces tiers with pods: small, cross-functional teams of three to five people that own an end-to-end detection and response scope — for example, a pod that owns identity and access threats, another that owns endpoint and ransomware response, another that owns cloud and SaaS security posture. Each pod includes a mix of experience levels, but critically, every member of the pod does judgment and investigation work because the enrichment and administrative toil has been automated away by the agentic layer rather than delegated to the junior member of the team. Rotation across pods, rather than promotion up a tier ladder, becomes the primary career development mechanism, and it gives analysts breadth across the threat landscape rather than years spent exclusively triaging phishing tickets.

The pod model is not free of trade-offs. It requires a detection engineering function that can operate in a hub-and-spoke pattern — centralized standards and shared infrastructure, with detection authorship embedded in each pod — which is a heavier coordination overhead than a single centralized detection team. It also requires the agentic enrichment layer described earlier to actually work, because without it, pods without a dedicated triage tier will drown in raw alert volume. Organizations that have tried to flatten the tier structure without first automating the enrichment layer have generally regretted it; the sequencing matters. Get the agentic layer live and trusted first, then restructure roles around the capacity it frees up.

Alert triage: the case for agentic AI in the queue

The alert triage function is the highest-volume, highest-toil, lowest-judgment work in most SOCs, which makes it the correct first target for agentic automation — not because it's the most impressive use case, but because it is where the return on automation is most immediate and measurable. A well-architected agentic triage layer does not replace the analyst's decision on ambiguous or high-severity cases; it performs the same first ninety seconds of investigation that a human analyst would perform — checking whether the source IP has a reputation history, whether the destination is an approved SaaS tenant, whether the user account has recently changed its authentication pattern, whether the file hash has been seen elsewhere in the environment — and it does it for every alert, consistently, in under a second, rather than for a sampled subset when a human has time.

The design decision that determines whether this layer earns analyst trust or gets bypassed within a month is transparency of reasoning. An agent that auto-closes an alert with no visible evidence chain will be distrusted the first time it gets one wrong, and analysts will start re-checking everything it does, which erases the toil reduction entirely. An agent that presents its enrichment findings, its confidence score, and the specific evidence it used to reach a disposition — in the same format a senior analyst would use to justify a decision to a peer — earns trust incrementally and gets audited spot-checks rather than blanket re-verification. This is the difference between a black-box classifier and an agentic workflow that mirrors analyst reasoning steps explicitly, and it is why approaches to AI-native alert triage that expose the evidence chain outperform those that only expose a score.

There is a second, less obvious benefit to this architecture: it changes what "escalation" means. In a traditional tiered SOC, escalation means handing off a case with a note, and the receiving analyst frequently redoes a chunk of the investigation because they don't trust the handoff notes or the notes are incomplete. In an agentic model, escalation means handing off a case with the full enrichment and correlation evidence already attached and machine-verifiable, so the senior analyst or incident responder starts from the same evidence base rather than re-deriving it. This alone can cut meaningful time off mean-time-to-respond, because the investigation time saved compounds at every handoff rather than being spent once.

None of this works if the underlying detection and response fabric is fragmented across a dozen point tools with no common data model, which is why organizations building toward this operating model increasingly consolidate around an integrated response architecture like XDR detection and response rather than stitching a SOAR playbook across disconnected consoles. The consolidation is not about vendor simplicity for its own sake — it is a prerequisite for the enrichment agent to actually have the identity, asset and threat context available in a queryable form at triage time, in milliseconds, rather than requiring a live API call to six different systems with six different latency and reliability profiles.

Metrics that matter: beyond MTTD and MTTR

Most SOC metrics programs stop at mean-time-to-detect and mean-time-to-respond, and both are necessary but badly incomplete for understanding whether the operating model is healthy. MTTR in particular is easy to game — an analyst who closes ambiguous alerts as benign without full investigation will post excellent MTTR numbers and terrible actual security outcomes. A more complete metrics framework separates outcome metrics, process health metrics, and people health metrics, and treats none of them as sufficient on its own.

• Outcome metrics: dwell time (time from initial compromise to detection, which requires threat hunting and retrospective analysis to measure honestly, not just alert-based MTTD), containment time (time from detection to the threat being unable to progress further, which is a better operational metric than full remediation time), and escape rate (incidents discovered by a source other than the SOC's own detection stack — a customer report, a third-party notification, a red team exercise — which is the most honest measure of detection coverage gaps).
• Process health metrics: the toil ratio described earlier, detection precision and recall per rule, alert-to-analyst ratio per shift, percentage of alerts closed with a full evidence chain versus closed on gut feel, and time-to-tune for a detection rule identified as noisy.
• People health metrics: analyst-reported cognitive load (a simple weekly pulse survey works better than most people expect), voluntary attrition segmented by tenure band, internal mobility rate (are analysts moving into other roles within the security organization, or only leaving the company entirely), and on-call burden distribution (is the pain concentrated on a few people or spread fairly).

The metric most SOC leaders under-track, and the one most predictive of attrition six months out, is alert-to-analyst ratio measured at the individual shift level rather than as a monthly average. Averages hide the reality that a bad Tuesday night shift with one analyst covering a queue built for three creates the burnout event, even if the monthly average looks reasonable. Instrumenting shift-level ratios and setting a hard ceiling — above which alerts auto-escalate to on-call leadership rather than accumulating in an unattended queue — is a concrete, implementable control that prevents the worst nights from becoming the reason someone quits.

Retention economics: what actually keeps analysts

Compensation matters, but it is not the lever most SOC leaders can move fastest or most credibly, and it is rarely the actual root cause when exit interviews are conducted honestly rather than treated as a formality. The recurring themes in SOC exit interviews across the industry cluster around three things: the job never became more interesting than it was in month two, the on-call burden was unpredictable and unevenly distributed, and there was no visible path to doing threat hunting, detection engineering or incident response work rather than perpetual triage.

Each of these maps directly to an operating model fix rather than a compensation fix:

• Job interest is a direct function of the toil ratio. If enrichment and administrative toil are automated away, the remaining work — judgment calls on ambiguous cases, investigation, containment decisions — is inherently more engaging because it uses actual analytical skill. This is the single biggest lever available and it is entirely within a SOC leader's control, unconstrained by budget cycles that gate compensation changes.
• On-call predictability requires the shift-level alert-to-analyst ratio ceiling described above, combined with a published, fair rotation schedule and genuine backup coverage rather than a backup analyst who is nominally off duty but expected to answer pages anyway.
• Visible career path requires the pod rotation model, or at minimum a formal, time-boxed rotation program that lets a Tier 1 analyst spend a quarter embedded with detection engineering or threat hunting, with a real handback plan rather than a permanent reassignment that leaves the triage queue understaffed.

A practical way to quantify the retention return on operating model investment is to model the fully loaded cost of attrition against the cost of the automation and restructuring effort. If a mid-sized SOC of twenty analysts runs 30% annual attrition at a fully loaded replacement cost of $90,000 per departure (recruiting, onboarding, ramp-time productivity loss, and the detection-tuning knowledge that leaves), that is $540,000 a year in pure churn cost before counting the security risk of a persistently under-experienced team. An agentic triage layer that reduces toil enough to cut attrition to 15% saves roughly $270,000 annually, which typically exceeds the licensing and integration cost of the automation layer within the first year, independent of any argument about faster detection or response. This is the argument that gets budget approved when the security case alone does not move a CFO, and it is worth building the spreadsheet before asking for the investment rather than after.

The agentic SOC reference architecture

Pulling the previous sections together, a reference architecture for an AI-era SOC has four functional planes, and the maturity of an organization's operating model can be assessed by how cleanly these planes are separated versus how tangled they are into a single monolithic SIEM-plus-SOAR stack.

The governance plane deserves particular attention because it is where most agentic SOC initiatives either earn durable trust or collapse after a visible failure. Every automated disposition — every alert an agent closes, escalates, or enriches — needs to be logged with the evidence it used and the confidence it assigned, in a form that a human can audit after the fact without needing to reverse-engineer the model's reasoning from scratch. This is not just a compliance nicety; it is the mechanism that lets a SOC manager answer the question "did the AI miss something" with evidence rather than assurance, and it is the mechanism that lets detection engineers identify systematic blind spots in the agent's reasoning rather than one-off mistakes. Programs that skip this plane tend to discover its absence at the worst possible time — during a post-incident review after a missed detection, when leadership asks what the automated layer saw and nobody can reconstruct it.

This architecture also has to account for environments where connectivity to cloud-hosted threat intelligence or model inference is not guaranteed — regulated industries, critical infrastructure, and government or defense environments that require air-gapped or sovereign deployment. An agentic reasoning plane designed only for a fully connected cloud SIEM will simply not deploy in these environments, and retrofitting it later is materially harder than designing for on-premises and air-gapped operation from the outset. This is a deliberate design constraint in the Algomox platform precisely because a meaningful share of the customer base — defense contractors, utilities, national and regional government agencies — cannot depend on an internet-connected control plane for real-time detection and response, and an architecture like the agentic SOC model needs to run its reasoning plane locally, with model updates and threat intelligence synchronized on a scheduled, auditable basis rather than a live API dependency.

Governance, model risk and sovereign deployment

Introducing agentic decision-making into a SOC's triage path raises a model risk question that most security teams have not had to answer before: what is the change control process when the thing making a disposition decision is a model rather than a rule? A version-controlled detection rule has a diff you can review line by line. A model's behavior shift after a retraining pass or a prompt change is harder to characterize with the same precision, which means the governance plane needs its own discipline, distinct from ordinary detection-as-code review.

A workable governance process for agentic triage includes a held-out evaluation set of historical alerts with known-correct dispositions, re-run against every model or prompt update before it is promoted to production, with a required minimum precision and recall threshold on that eval set. It includes a shadow period, exactly analogous to the detection engineering shadow-mode rollout described earlier, where a new model version runs in parallel with the production version and disagreements are reviewed by a human before the new version takes over. And it includes an explicit, documented escalation threshold — any alert above a defined severity or affecting a defined set of crown-jewel assets never gets auto-closed regardless of model confidence, full stop, because the cost of a false negative on those assets is categorically higher than the toil saved by automating them.

For organizations operating in regulated or sovereign contexts, this governance discipline is not optional polish — it is frequently a regulatory or contractual requirement, and the audit trail described in the governance plane above is what makes an agentic SOC defensible to an examiner or an accreditation body. The same logic extends to identity-centric threats, where the blast radius of a wrong automated decision (disabling the wrong account, or failing to catch a genuine privilege escalation) is high enough that identity-related detections deserve their own tighter governance tier; this is why identity security and privileged access management is typically treated as a distinct, more conservatively governed pod within the broader agentic SOC rather than folded into general-purpose triage automation, and why organizations reassessing their perimeter increasingly pair it with continuous exposure management under a framework like continuous threat exposure management to keep the attack surface the SOC has to reason about from growing unchecked.

A step-by-step migration playbook

Organizations rebuilding their SOC operating model around these principles get better outcomes when they sequence the work rather than attempting a simultaneous overhaul of tooling, roles and metrics. The following sequence reflects what has worked in practice, roughly in twelve-week increments for a mid-sized SOC.

1. Weeks 1–4: Instrument before you automate. Stand up the toil taxonomy tagging in your case management system, baseline the shift-level alert-to-analyst ratio, and run the detection debt audit described earlier. Do not buy or build any automation yet — you need the baseline numbers to prove the intervention worked and to know where the worst toil actually concentrates, which is frequently not where leadership assumes it is.
2. Weeks 5–12: Automate enrichment first, narrowly. Pick the single highest-volume, lowest-judgment alert class — commonly phishing report triage or endpoint alert enrichment — and deploy an agentic enrichment layer against just that class, in shadow mode initially, then live with full evidence-chain logging. Measure the toil ratio shift specifically for that alert class before expanding scope.
3. Weeks 13–20: Expand enrichment and introduce correlation. Once the narrow deployment has earned trust (measured by analyst override rate trending down, not just uptime), expand the agentic layer to additional alert classes and introduce cross-source correlation so that related alerts across different tools are automatically linked into a single case rather than triaged independently.
4. Weeks 21–28: Restructure roles around the freed capacity. Only after the automation has demonstrably reduced toil should you begin piloting the pod structure, starting with a single pod covering one threat domain, before committing to a full reorganization. Restructuring roles before the automation is trusted and stable will simply concentrate the same old toil onto fewer people.
5. Weeks 29–36: Formalize detection-as-code and the governance plane. Move detection logic into version control if it is not already, establish the backtesting and shadow-mode rollout pipeline, and build the model evaluation and audit trail process for the agentic layer before further expanding its scope of authority.
6. Ongoing: Run the full metrics framework monthly. Outcome, process and people health metrics together, reviewed at the leadership level with the same seriousness as a financial close, because a SOC that only reviews MTTR will optimize for MTTR at the expense of the things that actually predict the next incident and the next resignation.

This playbook deliberately delays the most visible, most politically appealing move — reorganizing the team — until after the less visible plumbing work is done, because reorganizing first without the automation in place simply reshuffles the same toil across a new org chart. It is also worth resourcing this migration with realistic expectations about integration effort: consolidating telemetry from a fragmented tool estate into a common schema is usually the single largest time sink in the entire twelve-month program, and organizations that under-budget it are the ones who end up with an agentic layer that works well on the two data sources it was piloted against and poorly everywhere else. Teams evaluating vendors for this work should look specifically at how much of the correlation fabric and normalization work is native to the platform, as documented in the Algomox technical whitepapers, versus how much will require custom integration engineering after purchase, because that gap is where migration timelines usually go off the rails.

Operating across cloud, on-prem and air-gapped environments

A final architectural consideration that shapes every decision above is deployment topology, because a SOC serving a hybrid enterprise — cloud workloads, on-premises data centers, and in some cases fully air-gapped operational technology environments — cannot assume a single, uniform integration pattern across all three. The reasoning plane and governance plane described earlier need to be portable: the same detection logic, the same agentic enrichment behavior, and the same audit trail format should apply whether the deployment is a multi-tenant cloud SaaS instance, a customer-managed on-premises cluster, or a disconnected air-gapped enclave that synchronizes updates during scheduled maintenance windows rather than continuously.

This matters directly for analyst experience because analysts who rotate across business units or who support managed service engagements spanning multiple customer environments need a consistent workbench regardless of where the underlying data lives. A SOC platform architecture that requires an entirely different console, query language, or investigation workflow for the air-gapped enclave versus the cloud tenant reintroduces exactly the context-switching toil that consolidation was supposed to eliminate, just at the environment level instead of the tool level. This is one of the more underappreciated arguments for standardizing on a platform designed from the outset for multi-topology deployment — not because every SOC needs air-gapped capability today, but because the operating model consistency it forces (common schema, common workbench, common governance regardless of where the compute runs) pays off even for organizations that are cloud-only, since it prevents the platform itself from becoming the next source of fragmentation as the environment inevitably grows more heterogeneous over time. Organizations running combined network operations and security operations functions face a related version of this challenge, and the same consolidation logic underpins any converged operating model where availability and security telemetry feed one operating picture instead of two teams working from two disconnected toolsets that happen to be investigating the same underlying event.

Frequently asked questions