When you evaluate an agentic security system, you are making a decision about where your organisation’s security knowledge will accumulate, who can use it, and what happens when the technology changes.
Look five years ahead. Your analysts may have moved on. Your models will have changed. Your organisation may have replaced parts of its security stack.
The understanding developed through years of investigations should still belong to the organisation and remain useful to the people and systems protecting it. That knowledge can also make smaller models more useful, reducing dependence on larger models for work that can be handled with the right context.
If your understanding exists only in someone’s head or inside a tool you cannot replace, it becomes a security dependency of its own. Building an agentic SOC should be an opportunity to address that problem.
1. Build a knowledge layer that preserves why decisions were made
An investigation’s outcome tells only part of the story.
A case might have closed because the CISO accepted a risk. A technical limitation might have prevented further investigation. A regulatory obligation might have required additional action. Each outcome carries a different meaning for whoever encounters a similar situation next.
The knowledge layer should preserve that distinction: what was known, what remained uncertain, who made the decision, and the conditions under which it was made.
That context must also be able to evolve.
Suppose an earlier decision reflected the organisation’s security policies at the time. Since then, its commitments or processes under its information security management system may have changed. Reusing the decision requires checking it against those changes.
The same applies to technology. An investigation constrained by an old operating system or limited telemetry might reach a different conclusion today. Better visibility should allow the organisation to revisit its understanding.
I would therefore expect the knowledge layer to retain the evidence and reasoning behind a finding, record corrections, and make clear when a decision needs review. New analysts and agents should be able to understand both the previous conclusion and its limits.
Ownership also needs to extend across the architecture. Where does the knowledge live? Where is it processed? Which models can access it? Does that arrangement fit the organisation’s security controls, risk management approach, and approved use of AI?
For some organisations, those requirements will point towards private cloud, on-premises, or air-gapped deployment. The dependencies need to fit the same boundary.
Treat data location, ownership, access rights, and portability as separate buying questions. A deployment label alone does not answer them.
2. Make accumulated knowledge useful over the long term
The long-term value should come from the organisation becoming better at using what it has already learned.
For a SOC leader, that means giving analysts access to the context behind previous investigations. A new member of the team should be able to understand why a particular exception exists, what has already been tried, and which constraints shaped an earlier decision.
For an architect, it means designing for continuity as components change.
For a CISO, it means understanding how much of the security programme depends on particular people, tools, and suppliers—and whether that dependence is acceptable.
More retained information does not automatically deliver those benefits. The knowledge has to remain accessible, relevant, and open to correction. Otherwise, the organisation risks preserving old assumptions and making them easier to repeat.
This knowledge layer also changes how we should think about model size.
A model needs to understand the organisation it is helping to protect: which systems matter, what previous investigations established, which risks were accepted, and whether those decisions still apply. Increasing the parameter count does not supply that private organisational context.
When the architecture retrieves relevant evidence, current policies, and previous decisions for a clearly defined task, smaller models become a more useful option. An agent comparing a new case against an existing risk acceptance, for example, can receive the original rationale, its conditions, and any subsequent changes. That makes the task more focused and gives the model a stronger basis for its response.
Research supports this direction. Across question-answering benchmarks, Less LLM, More Documents found that smaller and mid-sized models with richer retrieval corpora often rivalled larger models with smaller corpora. That provides a reason to evaluate this approach in security operations, with quality established against the organisation’s own workflows. Read the study.
My argument is that investing in organisational knowledge can reduce how often a larger model is needed. Smaller models can handle workflows where they demonstrate sufficient quality, while more demanding work can use greater model capability.
That creates an opportunity to reduce computing requirements and operating costs, and to make deployment within the organisation’s own infrastructure more practical. Those benefits need to be measured across the complete workflow, including retrieval, review, and escalation.
The design principle is to supply the right context and use the smallest model that meets the task’s quality requirements. Relevant, current evidence matters more than simply filling a larger context window.
Commercial access matters too. I would want to understand who can use the accumulated knowledge, whether new agents can access it, and what happens to the cost as those uses expand. A system should be assessed against the organisation’s future operating model as well as its current budget.
There is a practical trade-off here. A tightly integrated vendor ecosystem can be a sensible choice when budget is constrained or the engineering team is small. Integration and maintenance take effort, and that burden continues after deployment.
The decision should account for both that ongoing effort and the constraints of the chosen ecosystem. The organisation needs to understand what it gains today and what flexibility it may need later.
3. Keep the intelligence usable as agents and tools change
A new agent should be able to connect to the organisation’s knowledge, retrieve relevant context within its permissions, and use it to support the next decision.
Adopting a new tool should also allow the organisation to build on its existing understanding. That requires usable connections and enough context for another system to interpret what it receives.
I would ask vendors to demonstrate this. Show how a separate agent accesses a previous investigation, identifies the evidence behind its conclusion, and recognises that an earlier decision may need review. Show how access is controlled and what happens when a component is replaced.
The same principle should apply when changing models. The organisation should be able to evaluate a smaller model for a particular workflow using its existing knowledge, then retain the option to use a more capable model where the task requires it.
Model availability belongs in that conversation.
On 12 June 2026, Anthropic said an export-control directive required it to suspend access to Claude Fable 5 and Mythos 5 for all users. Its subsequent update confirmed that the controls were lifted on 30 June and access was restored. The interruption was temporary, but it illustrates how access to a chosen model can change outside a customer’s control. Anthropic’s suspension statement, restoration update.
Retaining knowledge separately from a particular model gives the organisation something enduring to work with when evaluating an alternative. Any replacement still needs to be assessed for its capability, behaviour, and fit with the organisation’s controls.
This is why I would look closely at whether a vendor’s architecture primarily serves its own product ecosystem or supports integration across the tools the customer chooses. Both approaches involve trade-offs. The important decision is whether those trade-offs fit the organisation’s risk, resources, and long-term plans.
Before buying an agentic security system, establish a plan for how your organisation will own and use the intelligence it develops. If that plan does not yet exist, the buying process is the time to create it.
Your analysts, agents, models, and suppliers will change. The security knowledge your organisation builds should remain available to help you make the next decision.