In the previous article, The Lossy Handshake, I followed one identity incident across intelligence, hunting, detection, investigation, and remediation. Every function added value. The system still dropped evidence, assumptions, uncertainty, ownership, or business context at each transfer. Diagnosing that loss is useful. The harder question is what the architecture must preserve so the next person, workflow, or agent does not have to start over.
A system is not intelligent because it can summarize an alert.
It is intelligent when it can preserve what the organization knows, identify what it does not know, and improve the next decision without hiding how it got there.
That is the standard the AI SOC should be held to.
The traditional SOC is mostly stateless. It processes alerts, opens cases, adds notes, closes tickets, and moves on. Evidence is stored, but understanding is scattered. The same entity gets resolved again. The same telemetry gap gets rediscovered. The same false positive gets explained for the fortieth time.
The next SOC must be stateful.
Not because state is a fashionable architecture term. Because you cannot tighten a lossy handshake if every stage forgets what the previous stage learned.
Start With Operational Memory
When people hear “semantic layer,” they often imagine another data platform or a universal schema that will finally normalize everything.
That is too abstract and too ambitious.
The practical requirement is shared operational memory: a durable representation of the environment, the evidence collected, the decisions made, and the constraints around action.
It needs five kinds of state.
1. Environmental State
Which identities, devices, workloads, applications, tenants, and business services exist? How are they related? Who owns them? Which are privileged, exposed, critical, unmanaged, or stale?
This is not a static asset inventory. It changes as accounts move, devices age, cloud resources appear, and ownership shifts.
2. Evidence State
What was observed? Which source produced it? When was it collected? Has it been normalized, enriched, or inferred? Can an analyst get back to the original event?
Evidence without provenance is decoration.
3. Decision State
What is the current hypothesis? What alternatives were considered? Which evidence supports or contradicts it? How confident is the system, and what additional evidence would materially change the conclusion?
A verdict alone is not enough. “True positive” does not explain why.
4. Control State
Which actions are allowed? Which require approval? Who owns the affected system? What maintenance, legal, business, or safety constraints apply? What must be preserved before containment?
Confidence is not authority. A system can be highly confident and still lack permission to act.
5. Learning State
What did the analyst correct? Which detection assumption failed? Did the remediation work? Did the incident reopen? Was the telemetry sufficient? Should this result change a hunt, rule, playbook, or control?
Without learning state, every incident ends as a record rather than becoming an input to the next decision.
Together, these states form the semantic layer. Not a magical knowledge graph. Not a replacement for the SIEM, EDR, identity platform, case system, or asset inventory. A shared model that lets those systems contribute to the same decision without flattening everything into an alert.
Unknown Must Be A First-Class Answer
The biggest risk in an AI-driven SOC is not that the model says something obviously absurd.
It is that the system turns missing evidence into a confident story.
Suppose endpoint telemetry is absent for the finance user from the previous article. A weak system might conclude, “No malicious process activity was observed.”
That sentence sounds responsible. It may be completely misleading.
Was no malicious activity observed because the endpoint was clean? Or because the device was unmanaged, the sensor was unhealthy, the retention window expired, or the data had not arrived?
A stateful SOC must preserve that distinction:
Endpoint behavior could not be validated. The device associated with the session is unmanaged, so process and network telemetry are unavailable. Confidence in endpoint scope is reduced.
That is not a cosmetic wording change. It alters the decision.
The semantic layer should never hide a gap. It should make the gap part of the case, identify which conclusions it limits, and route the deficiency to the owner who can fix it.
Agents Need Jobs, Not Personalities
Once shared operational memory exists, agentic workflows become useful.
The word “agent” has acquired too much theater. A SOC does not need a collection of digital employees with names and avatars. It needs bounded workflows that can read relevant state, perform a defined task, write structured results, and operate under explicit authority.
Different functions have different jobs.
An intelligence workflow can evaluate whether an external threat applies to the local environment. It should connect techniques to exposed technologies, relevant identities, known vulnerabilities, and available telemetry. Its output is not “high priority.” Its output is a relevance judgment with reasons and coverage implications.
A hunting workflow can translate that judgment into testable hypotheses. It should query available evidence, state which populations were covered, identify blind spots, and preserve both positive and negative findings.
A detection workflow can test whether the environment can support reliable logic before a rule is deployed. It should know the required data sources, expected latency, schema dependencies, known exceptions, and evidence needed during investigation.
An investigation workflow can assemble a timeline, resolve entities, compare prior behavior, test competing explanations, and produce a decision package. It should expose supporting evidence, contradictions, confidence, and missing data.
A response workflow can map a decision to available actions, owners, approvals, and operational constraints. It can recommend or execute actions only within policy.
Each workflow reads and writes the same operational memory. That is the fabric. The value does not come from having many agents. It comes from keeping their work connected.
Follow The Decision, Not The Alert
Return to the finance account.
The signal is an unfamiliar sign-in followed by a new forwarding rule and unusual SharePoint downloads.
In a stateless SOC, the analyst gathers the identity, email, cloud, endpoint, and asset context manually. The final ticket says the account is likely compromised and should be disabled.
In a stateful SOC, the investigation begins with what is already known:
- The identity belongs to a finance employee with access to payroll data.
- The sign-in came from infrastructure the user has never used.
- MFA was satisfied, which does not eliminate session theft.
- The external forwarding rule was created shortly after the sign-in.
- SharePoint activity deviated from the user’s normal access pattern.
- The session came from an unmanaged device, so endpoint evidence is unavailable.
- Payroll processing is active, so disabling the account requires coordination.
The investigation workflow tests two hypotheses.
Hypothesis one: the user is traveling or using a legitimate new service. That explains the unfamiliar network but not the forwarding rule or unusual document access.
Hypothesis two: an authenticated session was stolen. That explains the sequence, but endpoint scope remains unknown because the device is unmanaged.
The decision package does not simply say “compromised.” It states that session compromise is the leading hypothesis, lists the evidence, identifies the missing endpoint view, describes the likely blast radius, and separates containment from recovery.
The response workflow then checks authority.
Revoking active sessions, removing the external forwarding rule, and suspending the account may be preapproved for high-confidence identity compromise. The finance owner is notified to move payroll processing to a backup operator. Restoring access requires credential reset, MFA re-registration, validation of a managed device, and review of downstream activity.
The system can execute the approved low-risk actions, route the disruptive decision, and preserve every result.
The important change is not that AI wrote a better summary.
The important change is that the evidence, uncertainty, business constraint, authority, and outcome remained part of the same decision.
Dynamic Remediation Is Constrained Remediation
Static playbooks fail because the world refuses to stay static.
“Disable the user” sounds reasonable until the identity is a service account, break-glass administrator, clinical system, plant operator, or payroll processor.
“Isolate the endpoint” sounds safe until the endpoint is a production server without failover.
“Block the IP” sounds obvious until it belongs to shared cloud infrastructure used by customers.
Dynamic remediation does not mean improvising without control. It means selecting among approved actions based on current entity state, evidence, confidence, and business constraints.
The system should distinguish four modes:
- Observe: Gather or validate more evidence without changing the environment.
- Recommend: Present an action and rationale to an authorized human.
- Approve and execute: Require explicit approval before the system performs the action.
- Preauthorized execution: Act automatically only when policy, confidence, entity type, and blast-radius conditions are satisfied.
The mode is part of the control state. It should be versioned, auditable, and visible to the analyst.
No agent should gain authority merely because its narrative sounds confident.
Feedback Must Be Structured
“Learn from every investigation” is easy to say and dangerous to implement carelessly.
One analyst closing one alert as a false positive should not cause a system to rewrite production detection logic. The analyst may be wrong. The environment may have changed. The case may be an exception.
Learning requires structure.
If an analyst changes the verdict, the system should capture what evidence drove the correction. If the issue was missing context, it should identify the missing source or relationship. If the detection assumption was wrong, it should collect similar cases and propose a change. If a remediation failed, it should record the failure mode and affected entity type.
Then the responsible owner reviews the proposed change.
This is how the feedback loop tightens without becoming self-corruption.
What The System Must Never Do
A credible agentic SOC needs hard boundaries.
It should not:
- Treat unavailable telemetry as proof that nothing happened.
- Hide the original evidence behind a generated narrative.
- Convert confidence into execution authority.
- Rewrite a production detection because of one analyst decision.
- Apply the same remediation to every entity type.
- Learn from outcomes without preserving who made the correction and why.
- Optimize only for closing cases faster.
Fast closure is not the objective. Better, defensible decisions are.
Measure Decision Quality, Not Agent Activity
Do not measure an agentic SOC by how many tasks an agent completed. That is automation theater.
Measure whether the operating model improved:
- Did analysts spend less time rebuilding known context?
- Did investigations expose missing telemetry instead of hiding it?
- Did response owners receive enough evidence to act without restarting the investigation?
- Did detection feedback reach the owner faster?
- Did repeated false positives decline for the reason they were originally closed?
- Were automated actions inside policy, reversible where possible, and fully audited?
- Did the analyst accept, correct, or reject the system’s conclusion, and why?
These measures reveal whether the SOC is learning or merely moving faster.
The Analyst Moves Into The Control Loop
The analyst is not removed from the system. The analyst changes position inside it.
Instead of spending the first half of an investigation assembling identity, endpoint, cloud, email, and network evidence, the analyst starts by challenging a structured case.
Is the hypothesis coherent? Is the evidence sufficient? Did the system miss a competing explanation? Is the proposed action proportionate? What does the business context change? What should the organization learn?
That is higher-value work, but it also demands more from the architecture. The system must be transparent enough to challenge, constrained enough to trust, and persistent enough to improve.
Closing The Loop
Across these three articles, the argument has been straightforward.
First, AI is lowering the cost of attacker iteration. It does not need to produce a novel exploit in every campaign. It only needs to help the attacker research, adapt, troubleshoot, and try again faster than before.
Second, the traditional SOC answers that pressure with a fragmented decision loop. Threat intelligence, hunting, detection engineering, investigation, and remediation may all perform their jobs well while the system loses evidence, assumptions, uncertainty, ownership, and learning between them.
Third, adding agents to that broken loop does not fix it. It gives the same operating model more speed. The architecture has to preserve operational memory first: what the environment looks like, what the evidence proves, what remains unknown, who has authority to act, and what the organization learned from the outcome.
This is not primarily a technology replacement. It is a redesign of how security decisions survive contact with the organization.
SOC leaders do not need to wait for a fully autonomous future to begin. Start with the reconstruction tax. Identify where analysts repeatedly rebuild context. Make telemetry gaps visible in the final decision. Preserve the evidence and reasoning behind a verdict. Define action owners and approval paths before an incident. Make investigation outcomes flow back into hunting, detection, and response.
Then use AI where it earns the right to help: assembling evidence, maintaining state, testing hypotheses, exposing gaps, and coordinating approved action. Keep people where judgment, consequence, and accountability matter.
The future of the SOC will not be defined by how many autonomous actions it can claim. It will be defined by how well it preserves truth, represents uncertainty, turns outcomes into learning, and keeps authority accountable.
The attack loop is getting tighter.
The defensive loop must become continuous, stateful, and capable of learning without surrendering control.
That is the standard: a SOC that remembers enough to learn, moves fast enough to matter, and remains accountable enough to trust.
Frequently Asked Questions
What does a stateful SOC have to remember?
Five kinds of state. Environmental state covers what exists in the environment and who owns it. Evidence state covers what was observed, from which source, and whether an analyst can get back to the original event. Decision state covers the current hypothesis, the alternatives, and the confidence. Control state covers which actions are allowed, who approves them, and what constraints apply. Learning state covers what the analyst corrected and whether the remediation worked.
How should an AI SOC handle missing telemetry?
Unknown has to be a first-class answer. “No malicious process activity was observed” sounds responsible but may be misleading if the device was unmanaged, the sensor was unhealthy, the retention window expired, or the data had not arrived yet. A stateful SOC states that endpoint behavior could not be validated, records which conclusions that limits, and routes the deficiency to the owner who can fix it.
Does an agentic SOC need many AI agents?
No. Agents need jobs, not personalities. A SOC does not need a collection of digital employees with names and avatars, it needs bounded workflows that read relevant state, perform a defined task, write structured results, and operate under explicit authority. The value comes from keeping their work connected through shared operational memory, not from the number of agents.
When should an AI system be allowed to act on its own conclusion?
Only within policy, and confidence alone is never enough. The system should distinguish four modes: observe, recommend, approve and execute, and preauthorized execution, where automatic action happens only when policy, confidence, entity type, and blast-radius conditions are satisfied. The mode belongs to the control state, and it should be versioned, auditable, and visible to the analyst.
How should an agentic SOC be measured?
By decision quality, not agent activity. Counting completed agent tasks is automation theater. Ask whether analysts spent less time rebuilding known context, whether investigations exposed missing telemetry instead of hiding it, whether response owners received enough evidence to act without restarting the investigation, whether detection feedback reached the owner faster, and whether automated actions stayed inside policy, reversible where possible, and fully audited.
About Jonathan Waknin, Director of Solution Architects | CISO, Conifers
Jonathan Waknin is a cybersecurity leader with 15 years of experience building and scaling global SOCs. Before Conifers.ai, he led high-performing security teams and services supporting top enterprise customers in the MDR and MSSP space. Now, as Director of Solutions Architects, he brings that operational expertise to innovation—combining SIEM/EDR integrations with AI-driven automation. Known for a results-driven approach, he focuses on real investigations, measurable outcomes, and customer-first operations. His vision highlights how SOCs can move from noisy alert queues to decision-driven systems where AI amplifies human judgment and restores meaning to the analyst’s role.