Enterprise Buyer's Guide

How to Evaluate an Agentic SOC Provider: An Enterprise Buyer's Guide

Choosing an agentic SOC provider requires evaluating more than the number of AI agents, integrations, or automated actions a vendor offers. Enterprise buyers should examine how agents coordinate security work, preserve context and evidence, operate across the existing security stack, and remain under human governance.

The market for agentic security operations is expanding quickly. Established security vendors are adding agents to their platforms, standalone agentic security companies are emerging, MSSP providers are incorporating agents into their services, and some security teams are building agentic capabilities themselves.

For a CISO, SOC leader, or AI Architect evaluating the market, that creates a difficult buying question.

The products may all use terms such as agents, autonomous security, AI workforce, orchestration, and agentic SOC. Underneath that language, however, they can represent very different technologies and approaches to operating security work.

Before comparing providers, it helps to establish what an agentic SOC actually is.

About this guide: This guide was written by Bricklayer. We have aimed to describe the agentic SOC market and its architectural tradeoffs fairly, including where other approaches may be a better fit.

What Is an Agentic SOC?

An agentic SOC uses AI agents to perform and coordinate security operations work across multiple steps, tools, and areas of expertise, with humans defining objectives, authority, and oversight.

That distinguishes an agentic SOC from an AI assistant that summarizes alerts or a traditional automation platform that executes predefined playbooks.

For enterprise buyers, the distinction is important because an agentic SOC is an operating model, not simply a collection of AI-powered security features.

An individual agent might investigate an endpoint, analyze an identity event, research a threat actor, or assess a vulnerability. An agentic SOC brings those capabilities together so that multiple agents can contribute to a larger security objective.

Consider an investigation that starts with a suspicious authentication event. The investigation may eventually involve identity, endpoint, cloud, vulnerability, and threat intelligence data. A human analyst could coordinate all of that work manually, with or without the help of AI assistants. A conventional automation system could execute a predefined sequence of steps.

An agentic system can instead assign different parts of the investigation to specialized agents, allow them to work simultaneously with the relevant information, combine their findings, and continue the investigation as new evidence changes the direction of the work.

The architectural challenge is considerable. Agents need enough context to understand what has already happened. They need access to enterprise data, security tools, and standardized operating procedures specific to the organization. They need a way to coordinate with other agents. Their actions need to remain within defined authority. Humans need visibility into the work and the ability to intervene. The organization also needs to understand how the system reached its conclusions.

Those are the capabilities an enterprise should evaluate.

The Agentic SOC Provider Landscape

There is no single category called an “agentic SOC provider.” Several approaches are emerging, and they make different architectural tradeoffs.

Approach	Where it tends to be strong	Tradeoffs to examine
Platform-native agents	Tight integration with the telemetry, controls, and workflows of an existing security platform	Platform dependency; breadth may be limited outside that platform
Standalone agentic security platforms	Coordinating agents and security work across multiple platforms, tools, and workflows	Adds another technology layer; depends on access to underlying platforms and enterprise data
AI-augmented MSSP	Combining AI capabilities with managed services including detection, investigation, and response	Less direct customer control; understand visibility, customization, and what technology is exposed to the customer
SOAR with LLMs or agents	Existing automation, integrations, and established operational procedures	Determine how well the system handles adaptive investigation beyond predefined automation
Build-your-own	Maximum control over models, agents, data, tools, and architecture	Engineering effort, governance, testing, maintenance, and ongoing platform development

These categories are not mutually exclusive. A vendor may combine elements of several approaches.

An enterprise’s existing environment also matters. A company heavily standardized on a single security platform may place a high value on deeply integrated agents. An organization with a heterogeneous security environment may care more about an agentic layer that can operate across existing platforms. A security team with limited engineering resources may prefer a managed service, while a large engineering organization may choose to build more of the infrastructure itself.

Understanding the architectural model makes the rest of the evaluation much easier.

What Should an Enterprise Look for in an Agentic SOC?

An enterprise evaluating an agentic SOC should look beyond the number of agents, integrations, or automated actions a provider advertises. The more important question is whether the system can coordinate specialized AI agents to perform meaningful security work while maintaining context, human oversight, and organizational control.

The evaluation should focus on how the system operates, not simply what capabilities appear in its feature catalog.

Look Beyond the Agent Catalog

The number of agents a provider offers is easy to compare, but it tells you relatively little about the capability of the overall system.

A provider might have dozens or hundreds of specialized agents. What matters is whether those agents can work together, share context and evidence, and contribute to a larger investigation or workflow without losing the work performed by other agents.

Enterprises should also examine how much control they have over the agent workforce:

Model selection: Can the organization choose which models agents use? Can different agents use different models based on reasoning requirements, speed, cost, data handling, or compliance?
Agent customization: Can agents be configured for the organization’s environment, procedures, tools, data, and specialized security requirements?
Specialization: Can organizations create or configure agents for security roles that are specific to their operating model?
Coordination: Can specialized agents work together rather than operating as isolated task automations?
Human control: Can analysts inspect, redirect, approve, or intervene in agent activity without losing the context and work already performed?

The number of agents matters less than whether they can be coordinated, configured, and governed as part of meaningful security work. The goal is to establish a security workforce that can be configured to the environment and governed according to the organization’s requirements.

10 Criteria for Evaluating an Agentic SOC Provider

The following criteria provide a framework for evaluating an agentic SOC provider:

Security work
Can the system perform substantive security work from investigation through outcome, rather than simply generate recommendations or execute isolated tasks?
Context
Can agents maintain and access the relevant findings, evidence, history, and uncertainty generated throughout the work?
Coordination
Can multiple specialized agents work together, divide responsibilities, and combine their findings into a coherent result?
Human collaboration
Can security professionals understand what agents are doing, contribute their own expertise, and redirect work when necessary?
Control and governance
Can the organization define what agents are authorized to do, enforce policies and approvals, and maintain an audit trail of their activity?
Enterprise data
Can agents work from persistent enterprise information and maintain relationships between findings, evidence, and source data rather than relying primarily on temporary context?
Enterprise architecture
Can the system support the organizational boundaries, security controls, model requirements, deployment needs, and operational requirements of an enterprise environment?
Harness architecture
Where does the agentic operating layer sit relative to the organization’s existing security stack?
Beyond the SOC
Can the same agentic operating model support additional security workflows where the organization needs it?
Evidence and outcomes
Can the provider demonstrate measurable operational results and show how the system reached its conclusions?

These criteria are interconnected. An agent may have access to the right tools but lack the context needed to use them effectively. Multiple agents may exist without a mechanism for coordinating their work. A system may automate an investigation but provide insufficient controls for an enterprise to govern the resulting actions.

For that reason, the evaluation should examine the system as a whole. The key question is whether its architecture enables those agents to perform coordinated, auditable security work under the organization’s control.

1. Start With the Security Work, Not the Agent Catalog

The easiest agentic SOC demo to produce is a collection of individual capabilities. One agent summarizes an alert. Another enriches an indicator. Another investigates a domain. Another produces a report. Those demonstrations can be useful, but they do not show how the system performs an actual security operation.

The more revealing test is to give the provider a security objective that requires several steps and several sources of information.

For example, start with a suspicious identity event and introduce evidence involving an endpoint, a threat intelligence indicator, and a potentially exposed asset. The investigation might involve extracting relevant indicators and hostnames, enriching and correlating that information with related alerts and asset data, reassessing the severity of the alert, and determining the appropriate escalation and response.

A demo environment can show how the provider’s architecture is intended to handle this kind of work, but it cannot fully demonstrate how the system will perform against an organization’s actual data, tools, configurations, and operating procedures. That distinction matters. A workflow that looks compelling with curated demonstration data may behave differently when it encounters the volume, inconsistencies, access controls, and organizational context present in a production environment.

For that reason, the demo should establish how the system works, while the POC should test how well it works in the customer’s environment. Where possible, use representative or production-derived data and connect the security tools the organization expects the system to operate across.

The objective is not simply to see whether an agent can complete a task. It is to determine whether the system can perform meaningful security work across the customer’s environment, while preserving context, involving the right specialists, and maintaining appropriate human control.

Look at the breadth of security work

The initial use case matters, but so does what sits around it.

Alert triage and incident investigation are natural places to start because they require substantial investigative work across multiple systems. Other security functions have similar characteristics.

Threat intelligence involves research, analysis, correlation, and production of intelligence relevant to the organization.

Vulnerability management involves understanding exposure in the context of assets, vulnerabilities, threats, and business priorities.

Threat hunting requires hypotheses, data analysis, investigation, and iteration.

The buyer should understand whether the platform is fundamentally designed around one or several narrow workflows or whether the underlying architecture can support multiple types of security work.

2. Examine How Context Moves Between Agents

Context is one of the easiest things to gloss over in an agentic SOC. Suppose an agent determines that an account is likely compromised and hands the investigation to another agent. What does the second agent receive?

If it receives only the first agent’s conclusion, it has lost much of the reasoning that produced it. If it receives the conclusion along with supporting evidence, relevant findings, uncertainty, and the information already gathered, it has a much better basis for continuing the investigation.

That distinction becomes important as the number of agents and handoffs increases.

What gets preserved?

Ask a provider to show what happens to:

findings
supporting evidence
decisions
uncertainty
actions already taken
unresolved questions
relevant enterprise information

It is particularly useful to inspect an active investigation rather than have the provider explain the architecture with a diagram.

What can the next agent actually see? Can an analyst see the same information? Can a later task refer back to findings created earlier?

Context should persist beyond a single model interaction

Security investigations often extend across multiple tasks and sometimes multiple sessions.

If important information exists only inside a model’s temporary context, it can disappear when that context ends.

An enterprise should therefore understand how investigative knowledge persists and how other agents can retrieve it later.

There are several ways to implement this. Some platforms maintain structured findings that agents can reference later. Others rely more heavily on case records, databases, or application-specific memory.

The implementation matters less than the capability: information generated during security work should remain available in a form that other agents and analysts can use.

Ask whether evidence and uncertainty survive

A finding can begin as a hypothesis and become increasingly certain as more evidence is collected. If each agent receives only a conclusion from the previous agent, uncertainty can disappear during the handoff.

That creates a risk that a chain of agents gradually turns an inference into something that looks like an established fact.

A provider should be able to show how the system distinguishes observed evidence from conclusions and how uncertainty is represented when information moves between agents.

3. See How Agents Actually Coordinate

Having several agents does not by itself demonstrate that they can work together around a security objective.

A provider may have dedicated agents for endpoint analysis, identity, cloud, threat intelligence, and vulnerability management. The question is how those capabilities come together around a single investigation.

Some systems rely heavily on predefined workflows. Others allow the system to determine dynamically which capabilities are needed. Many will use a combination.

Predefined procedures can be valuable for repeatable security operations. The issue is what happens when an investigation leaves the expected path.

A useful POC should introduce an unexpected finding and see whether the system can adapt.

Can another specialist be brought into the investigation? Can independent work happen concurrently? Can one agent’s findings trigger additional work? Can the system revise its approach without requiring someone to redesign the workflow?

Coordination should reflect the way security investigations unfold

Consider a sequence involving endpoint, identity, cloud, threat intelligence, and vulnerability analysis.

The value does not come from having five agents. It comes from their ability to contribute information to the same investigation.

A threat intelligence agent might identify a relevant campaign. That information could change how an endpoint finding is interpreted. A vulnerability agent might then determine whether an affected asset has a relevant exposure.

The buyer should be able to see those relationships during a demonstration.

Concurrency also matters. If several independent research tasks can happen at the same time, determine whether the architecture supports that directly or simply executes everything sequentially.

4. Look Closely at the Human Experience

“Human in the loop” is not a sufficient description of how an enterprise should evaluate analyst interaction with agents.

A human who only reviews the final answer has limited visibility into the investigation.

A more useful model gives analysts the ability to inspect the work while it is happening, understand what agents have done, review supporting evidence, challenge conclusions, and redirect the investigation.

Can an analyst intervene without starting over?

This is an excellent POC test.

Have an agent reach a preliminary conclusion. Then have an analyst challenge it and introduce another hypothesis.

Can the system investigate the new hypothesis using the context already accumulated? Can the analyst see the resulting work? Or does the investigation have to be stopped and manually reconstructed? Can the analyst question individual agents to understand their reasoning?

The answers reveal how deeply human interaction is integrated into the system.

5. Evaluate What Agents Are Authorized to Do

An agent might be able to isolate an endpoint through an EDR integration. That does not mean the security organization wants it to do so autonomously in every circumstance.

The important question is not simply what an agent can do, but what it is authorized to do, under which conditions, and who remains accountable for the outcome.

The platform should provide mechanisms for defining who or what can access data, invoke tools, execute procedures, and take consequential actions. Those controls should apply to individual agents and to the workflows in which they participate.

Look for:

Role-based access controls: Can permissions vary by user, role, team, organization, or tenant?
Tool and data permissions: Can access to specific systems, tools, and information be restricted?
Defined procedures: Can organizations establish how recurring workflows are performed?
Approval requirements: Can consequential actions require human approval before execution?
Action boundaries: Can organizations specify which actions an agent may take autonomously?
Credential management: How are credentials provided to agents, and can their use be restricted and monitored?
Auditability: Can the organization reconstruct what an agent did, what it accessed, and what actions it took?

This distinction becomes particularly important as agents move from analysis and recommendation into execution. An agent that can investigate an incident is different from one that can modify a firewall rule, disable an account, isolate a host, or make another consequential change.

A mature agentic SOC should therefore make authority explicit. The organization should be able to determine not only what an agent is technically capable of doing, but what it is permitted to do, when it can do it, and when a human must remain in the loop.

6. Evaluate Enterprise Data

Integrations are necessary, but an integrations list does not tell you how agents actually work with enterprise data.

Ask where the information lives, how agents retrieve it, whether it persists, and whether findings can be connected back to their source data.

Consider vulnerability analysis.

One agent identifies a CVE. Another determines which assets are affected. Another assesses reachability. Another considers whether the vulnerability is relevant to a known threat.

If each agent creates a separate representation of the data, the system can accumulate conflicting versions of the same information.

A stronger architecture allows agents to operate against persistent underlying enterprise information while bringing the specific data required for a particular reasoning task into their working context.

That matters at scale. Large enterprises may have millions of security events, extensive asset inventories, vulnerability data, threat intelligence, and years of case history. It is neither practical nor desirable to place entire datasets into an individual model context.

Provenance matters too

Suppose an agent concludes that an asset is exposed to a particular vulnerability and that the vulnerability is relevant to a known threat.

Can the organization identify the asset information, vulnerability data, threat intelligence, and other evidence behind that conclusion?

The more consequential the work becomes, the more important that lineage becomes.

7. Evaluate Enterprise Architecture

An agentic SOC can start with one workflow and one team. Enterprise requirements rarely stop there.

Business units may have different procedures. Subsidiaries may require separate data and administrative boundaries. MSSPs need strict customer isolation. Large security organizations may have different teams operating with different authorities. At the same time, enterprises may have centralized requirements for approved models, security controls, and operational practices.

The platform should accommodate those differences without requiring every environment to become a separate engineering project.

Look for:

Organizational isolation: Can subsidiaries, business units, and MSSP customers operate within separate data and administrative boundaries?
RBAC and custom roles: Can permissions reflect the different responsibilities and authorities of users?
Encryption and key management: Can the organization use its own keys where required?
Deployment and data requirements: Can the platform support private deployment or data-residency policies?
Auditability: Can the organization maintain a complete record of configuration changes and administrative decisions?
Reusable operational capabilities: Can agents, procedures, and integrations be shared across environments?
Controlled distribution: Can central security teams determine what is shared and who can modify it?
Model provider management: Can the organization connect to approved model providers and assign different models to different agents?
Model governance: Can models be evaluated and approved centrally?
Operational independence from models: Can the organization change or upgrade a model without rebuilding the agents, procedures, and governance that depend on it?

The last point is particularly important. Model architecture and operational architecture change at different rates. Models may change frequently, while the agents, procedures, integrations, governance, and institutional knowledge that support security operations represent a longer-term operational investment. An enterprise should understand whether changing the model layer requires changes to the operational layer.

The same principle applies to operational capabilities. If a security team develops a procedure that works well in one business unit, can it be packaged, reviewed, versioned, and made available to other environments without losing their isolation or control? Can improvements flow back to a central team for review rather than being independently rebuilt everywhere?

Enterprise scale is therefore about more than volume. It is about maintaining isolation, governance, and control while allowing operational capabilities and approved models to be reused at scale.

The buyer should test what happens as the number of users, workflows, agents, organizations, and model providers increases. The goal is to determine whether the platform becomes easier to manage as the program matures, or whether scale creates another layer of administrative and engineering work.

8. Understand Where the Agentic Harness Lives

The agentic harness is the layer that surrounds the agents and provides access to context, tools, enterprise data, coordination, policy, and human interaction. In practical terms, it is the operating layer between the AI agents and the systems, data, procedures, and people they need to perform security work.

Where that layer sits in the security architecture is a significant buying consideration.

A platform-native agent embedded in an EDR may have direct access to that platform’s telemetry, controls, and workflows. A standalone agentic platform can potentially access the same capabilities through MCP, APIs, or other integrations, while also coordinating work across multiple security systems.

The important question is therefore not simply who has access to the data or tools. It is how that access is provided, what the agentic system can do with it, and where the controls governing that activity reside.

The buyer should understand:

Which security platforms and data sources the agents can access
Whether access is through native capabilities, APIs, MCP, or other integrations
What actions agents can invoke through those connections
How permissions and credentials are managed
Whether context and findings can be carried across different systems
What happens when an underlying platform, integration, or API changes
How much of the agentic capability is dependent on a particular security platform

The architectural tradeoff is less about whether one approach can access a particular tool. It is about where the agentic operating layer lives and how broadly it can operate.

A platform-native approach may provide a tightly integrated experience within its own ecosystem. A standalone approach may provide a layer for coordinating work across multiple security platforms. The relevant question is whether the architecture matches the organization’s existing environment, operating model, and requirements for control and portability.

9. Look Beyond the SOC

The SOC is an obvious starting point for agentic security operations, but the same operating model can apply to other security workflows. Threat intelligence, vulnerability management, threat hunting, incident response, and identity and access management all involve multi-step work across enterprise data and tools, specialized expertise, defined procedures, coordination, and human oversight.

Suppose an enterprise starts with alert investigation and later wants to apply the same agentic technology to threat intelligence, vulnerability management, threat hunting, or IAM. Can it reuse existing agents, procedures, data access, governance, and context mechanisms? Can the same architecture support additional security work without creating a separate AI operating model for every function?

The objective is not to force every security function onto one platform. It is to determine whether the architecture provides a reusable foundation for coordinated agentic work while allowing each function to maintain its own data, procedures, permissions, and human accountability.

10. Demand Evidence of What Happened

An agentic system can generate enormous amounts of activity.

The buyer still needs to understand what actually happened.

For a significant investigation, the organization should be able to see the agents involved, the relevant context, material findings, supporting evidence, actions taken, human interventions, and final conclusions.

This is especially important when one agent’s output becomes another agent’s input.

If a final conclusion cannot be traced back through the work that produced it, the organization has limited ability to evaluate the reliability of that conclusion.

Measure operational impact

Providers will naturally show task counts, automation rates, response times, and other activity metrics.
Those can be useful, but they should be paired with measures of what changed for the security team.

During a POC, establish a baseline for a representative workflow:

How long does the investigation take today?
How much analyst effort does it require?
How much of the work is repetitive?
Where do analysts spend time gathering information?
How often does a human need to intervene?
What evidence is produced today?

Then compare the agentic workflow against that baseline.

Customer productivity claims should also be examined carefully. Ask how the measurement was calculated, what baseline was used, and whether the methodology maps to the work your organization is actually trying to change.

How to Test an Agentic SOC in a POC

A POC should test the architecture under realistic conditions, not simply showcase the provider’s preferred workflow.

Give every provider the same representative investigation:

A suspicious identity event involves an endpoint, a threat intelligence indicator, and a potentially exposed asset. Determine what happened, assess the risk, identify supporting evidence, and recommend the appropriate response.

Then introduce an unexpected finding. Ask an analyst to challenge one of the conclusions. Have the provider show the evidence behind the final assessment.

Use the exercise to test the criteria in the framework:

Test	What to look for
Security work	Can the system carry the investigation through multiple steps and specialties?
Context	What does each agent know about the work already performed? Are findings, evidence, and uncertainty preserved?
Coordination	How are specialists selected, and how are their findings combined? Can independent work happen concurrently?
Human oversight	Can an analyst inspect and redirect the work without starting over?
Governance	What actions can agents take, and which require approval? How are policies enforced?
Data	Can agents work from persistent enterprise information rather than isolated snapshots or temporary context?
Harness	Can the system operate across the existing security stack? What happens if an underlying platform changes?
Reusability	Can the same architecture support another security workflow without rebuilding the system?
Evidence	Can the organization reconstruct how the result was reached and trace conclusions back to supporting evidence?
Outcome	What changed compared with the existing process? Measure time, analyst effort, quality, and human intervention against a baseline.

The POC should also test what happens when the investigation does not follow the expected path. Introduce conflicting evidence, require a different specialist, or have the analyst change the investigative hypothesis. These scenarios reveal whether the platform can adapt its approach while preserving the work already performed.

A POC structured this way makes architectural differences visible that a polished product demonstration can easily hide.

Questions to Ask Every Agentic SOC Provider

What security work can the system perform end to end? Can you demonstrate a multi-step investigation involving multiple data sources, tools, and security specialties rather than a collection of individual agent tasks?
How do agents maintain and share context? How do agents access findings, evidence, decisions, and work performed by other agents? How is context preserved across agents, tools, and sessions?
How do agents coordinate their work? How does the system determine which agents or specialties should participate? Can multiple agents work concurrently and combine their findings into a coherent outcome?
How do humans collaborate with agents? Can analysts inspect, redirect, challenge, or contribute to agent work without forcing the workflow to restart? How is human input incorporated into the final outcome?
What are agents authorized to do? How are permissions, tool access, approval requirements, and action boundaries defined? Can the organization require human approval before consequential actions?
How is agent activity governed and audited? Can the organization define policies and procedures for agent behavior? Is there a complete record of agent actions, decisions, approvals, and changes?
How do agents work with enterprise data? What enterprise data can agents access, and how is that access governed? Is information generated during agentic work persisted and available to other agents and future workflows?
How does the architecture support enterprise environments? How does the platform support multiple business units, subsidiaries, or customers while maintaining data and administrative isolation? How are RBAC, encryption, key management, deployment, and audit requirements handled?
How does the agentic harness work with the existing security stack? Where does the agentic operating layer sit relative to existing security platforms? How do agents access tools and data through native integrations, APIs, MCP, or other mechanisms? What happens when an underlying platform or integration changes?
How reusable is the underlying agentic operating model? Can agents, procedures, integrations, context, and governance mechanisms be reused across different security workflows? What would be required to extend the system from an initial SOC use case into threat intelligence, vulnerability management, threat hunting, IAM, or other workflows?
What evidence and outcomes can you demonstrate? What measurable operational results have customers achieved, and how were those results measured against the existing process? Can you show the evidence and actions behind an outcome and reconstruct what happened for audit or investigation purposes?
What happens when the system encounters something it was not explicitly designed or configured to handle? How does it respond to unexpected findings, conflicting evidence, a change in investigative direction, or a need for a different specialist? Can it adapt while preserving context, maintaining governance, and involving a human when appropriate?

How Bricklayer Approaches These Criteria

Bricklayer takes a standalone agentic security platform approach. The platform coordinates specialized AI agents across security workflows with shared context, enterprise data, security tools, and defined procedures. Human teams remain responsible for setting objectives, establishing authority, governing outcomes, and reviewing agent work.

Coordinated security work

Bricklayer is designed for investigations that require multiple steps, sources of information, and areas of expertise. Different agents can handle different parts of an investigation while the system maintains the relationship between their findings and makes that work available to the agents that need it.

Shared context across the investigation

Bricklayer is designed to preserve findings, evidence, decisions, and other relevant information generated during agentic work so subsequent agents can build on what has already been established. This also helps maintain the connection between an assessment and the information that supports it.

Working with enterprise data and tools

Bricklayer is designed to operate across the existing security environment rather than requiring an organization to replace its existing tools. Agents can work with information from multiple enterprise sources and invoke available tools through integrations, MCP, APIs, and other mechanisms.

Human oversight and authority

Bricklayer treats human involvement as part of the operating model. Security professionals can review agent work, provide information, redirect an investigation, and intervene when judgment or approval is required. Organizations can establish different levels of authority for users and agents, control access to data and tools, define procedures, and require approval for consequential actions.

Enterprise architecture and reuse

Bricklayer is designed to support multiple business units, subsidiaries, teams, and managed security customers while maintaining appropriate separation of data and administration. Organizations can reuse approved agents, procedures, integrations, and other operational capabilities where appropriate. They can also manage approved model providers and assign different models for different agents.

Separating the operational architecture from the underlying models means that changing a model does not have to require rebuilding security procedures, integrations, governance, and accumulated operational knowledge.

Extending beyond the initial SOC use case

Bricklayer is designed so the same underlying approach can support more than one security workflow. The requirements involved in coordinated alert investigation also appear in threat intelligence, vulnerability management, threat hunting, incident response, and other security operations. For an organization starting with one SOC workflow, the question is whether the same architecture can support additional security work without creating a separate AI operating model for every function.

Where Bricklayer may not be the right fit

Bricklayer’s approach is not necessarily the right fit for every organization. An organization deeply embedded in a single security platform may prefer that platform’s native agent capabilities. An organization outsourcing security operations may prefer an AI-augmented MSSP. A team with substantial engineering resources and highly specialized requirements may choose to build its own agentic architecture.

The relevant question is whether Bricklayer’s approach fits the organization’s requirements for coordinated security work, enterprise data, human control, governance, integration, and reuse.

Conclusion

Evaluating an agentic SOC is different from evaluating another security automation product.

The number of agents, integrations, automated actions, or AI capabilities a provider advertises does not tell you whether those capabilities can operate together as a coherent security system.

The more useful questions are architectural.

Can agents maintain context across an investigation? Can specialized agents coordinate their work rather than operating as isolated task automations? Can they work with the organization’s existing data and security stack? Can security professionals inspect, challenge, redirect, and govern their work? Can the organization define what agents are authorized to do? Can the architecture support multiple teams, business units, models, and workflows without creating a collection of disconnected deployments? And can the system provide enough evidence to understand and audit how an outcome was reached?

Those questions reveal an important distinction between individual agent capabilities and an agentic operating model. Individual agents can automate specific tasks. An agentic operating model has to coordinate those tasks, preserve the work agents perform, maintain relationships to enterprise data and evidence, and keep humans in control of objectives, authority, and consequential decisions.

A strong POC should therefore go beyond a polished demonstration. Give the provider a meaningful security objective, connect it to representative enterprise data and tools, introduce unexpected findings or conflicting evidence, involve a human analyst, and examine the resulting evidence and actions. The goal is to understand not only what the agents can do, but how the system behaves when real security work becomes collaborative, uncertain, and cross-functional.

Ultimately, an enterprise should evaluate an agentic SOC as an operating model for security work. The right architecture depends on the security organization, its existing environment, and the work it expects to take on over time. The evaluation should therefore come back to fit: how well does the provider’s architecture support the organization’s requirements today, and how well can it support the security work it expects to take on in the future?

Frequently Asked Questions

What security work can an agentic SOC perform end to end?

A credible agentic SOC should carry a multi-step investigation involving multiple data sources, tools, and security specialties through to an outcome — not simply generate recommendations or execute isolated tasks.

How do agents maintain and share context across an investigation?

Context should persist beyond a single model interaction: findings, evidence, decisions, and uncertainty generated during the work should remain available to other agents and to analysts, not disappear once a task ends.

What evidence should a provider be able to show?

A provider should be able to show the agents involved in a significant investigation, the relevant context, material findings, supporting evidence, actions taken, human interventions, and final conclusions — and let the organization reconstruct how the result was reached.

Neil Cohen

Neil is a 4X marketing leader with 20+ years of go-to-market, product, and general management experience across cybersecurity and B2B technology, driving growth and product strategy.

Last Updated: October 9th, 2026

Build an Agentic SOC Without Sacrificing Control

Your team stays in control. Your threats get handled at scale. See it live in 30 minutes.

Book a Demo →