How Stating an Objective Becomes the Primary Way to Operate the Bricklayer Platform

Every new capability added to enterprise software has traditionally meant another menu, another configuration screen, another playbook, or another integration to manage. As platforms became more powerful, they also became more complicated. Users spent as much time learning how to operate the software as they did accomplishing the work itself.

That model made sense when software’s role was to help people perform work. It begins to break down when software can perform meaningful work alongside them.

For the first time, enterprise platforms can reason about an objective instead of simply executing predefined instructions. That creates an opportunity to rethink not just individual features, but how the platform itself is operated.

That’s the idea behind Conversational Platform Management.

Instead of navigating workflows to reach an outcome, analysts define the outcome they want to achieve. The platform determines how to achieve it through a coordinated system of AI agents that share context, reason about the work, adapt as new information emerges, and execute within enterprise governance.

From Predefined Automation to Agent-Driven Operations

Security operations started as manual work. Automation and AI changed that, and it has done so through three distinct stages.

SOAR platforms automated repetitive security operations by defining workflows in advance. Over time, those workflows became easier to build through low-code and no-code playbook designers, but the operating model remained the same. Engineers or analysts still predefined every enrichment, decision point, branch, and response action before automation ever executed. The workflows worked well for the situations they were designed to handle, but every new investigation, data source, or operational process required someone to return to the workflow editor and build again.

The second generation introduced AI assistants and copilots.

Instead of navigating increasingly complex interfaces, analysts could ask questions, summarize investigations, and receive recommendations. These systems made analysts more efficient, but they did not fundamentally change how work happened. The analyst still decided what to investigate, which tools to use, what evidence to collect, and what should happen next.

The interface changed. The operating model did not.

Conversational Platform Management introduces a third model.

The analyst no longer defines the execution. The analyst defines the objective, and the platform takes it from there.

One Investigation, Three Operating Models

The difference becomes clear when you compare how each operating model approaches the same investigation.

With a traditional SOAR platform, someone first builds a workflow.

Enrich the source IP. Query Active Directory. Check endpoint telemetry. Search historical incidents. Assign severity. Create a ticket.

Every step is predefined. If the investigation takes an unexpected turn, someone has to modify the workflow before automation can continue.

With an AI assistant, the workflow is replaced by a series of prompts.

Check this IP. Search historical incidents. Compare the results to last week’s phishing campaign. Recommend next steps.

The AI accelerates each task, but the analyst still coordinates the investigation from beginning to end.

Conversational Platform Management starts from a different place.

Investigate this alert. Determine whether it is related to last week’s phishing campaign, identify any affected users or systems, assess the business impact, and recommend the appropriate response.

The objective is clear. The execution is not prescribed.

The analyst doesn’t choose which integrations to query, which threat intelligence sources to consult, which investigation procedures to invoke, or which AI agent should perform each task. Those decisions become implementation details. A coordinated system of AI agents evaluates the objective, determines what work needs to happen, shares context across the investigation, adapts as new evidence emerges, and executes within the organization’s governance policies.

The difference isn’t conversation.

It’s that the analyst defines the objective while the platform determines the execution.

Conversation as the Operating Interface

Conversation becomes the primary operating interface for the Bricklayer platform. Through the same conversational experience, analysts and administrators can:

  • Define operational objectives and have a coordinated team of agents plan and execute the work
  • Configure AI agents
  • Build reusable investigation procedures
  • Manage integrations
  • Search historical investigations
  • Access organizational knowledge
  • Understand why an agent reached a particular conclusion

This isn’t a chatbot layered onto an existing interface. It’s a different way of operating the platform.

Example: an analyst asks Bricklayer to build a vulnerability response procedure for CVE-2026-7849 – identify affected systems and determine remediation priority. Bricklayer breaks the objective into tasks, coordinates the agents needed to complete them, structures content into insight groups, creates a report template, and makes the entire procedure savable for future use.

Adapting Without Rebuilding

Security operations rarely stands still. New attack techniques emerge, technologies change, priorities shift, and investigative processes evolve.

Historically, adapting meant rebuilding automation.

With Conversational Platform Management, adapting begins by defining a new objective.

Rather than opening a workflow editor to redesign logic, analysts describe the outcome they want to achieve. The platform determines how that objective should be accomplished using the organization’s tools, procedures, policies, and operational context.

The time between identifying a new operational requirement and acting on it is no longer measured by development cycles. It’s measured by how quickly the team can define the objective.

Governance at Execution Time

Greater flexibility only matters if it remains governed.

Every conversational request is evaluated through Bricklayer’s governance architecture. Actions remain permission-aware and limited to what both the requesting user and participating AI agents are authorized to perform. If an objective would require an agent to take an action outside its granted permissions, such as querying a data source it isn’t authorized to access or taking a response action reserved for a human analyst, that step is blocked and logged rather than silently skipped or escalated without record. Every action is fully traceable to the objective that initiated it, creating a complete audit trail of how work was performed and why.

Governance moves closer to execution, not further away.

A New Way to Operate Security

As organizations deploy more AI agents across security operations, directing those agents becomes just as important as building them.

Conversational Platform Management provides a consistent way for analysts, engineers, and administrators to direct that work. They can launch investigations, inspect agent reasoning, configure new capabilities, improve operational procedures, and manage the platform through the same objective-driven experience.

For decades, enterprise software has required users to translate objectives into execution before meaningful work could begin.

Conversational Platform Management reverses that relationship.

The analyst defines the objective.

The platform determines the execution.

Availability

Conversational Platform Management is available immediately as part of the Bricklayer platform.

If you’d like to see what it looks like to operate your security operations by defining objectives instead of human-led navigations, schedule a demo.