New architecture gives AI agents persistent, governed access to process enterprise-scale data
As we build increasingly sophisticated AI agents at Bricklayer, we keep running into the same limitation: Enterprise information is being treated as temporary input to individual agents instead of persistent, governed infrastructure shared across the AI workforce.
Most agent architectures retrieve information, convert it into text or JSON, and place it whole inside a model’s context. Each agent creates its own copy, summary, or interpretation of the underlying data. As information moves between agents, it is repeatedly retrieved, compressed, and passed through messages.
This approach works for small isolated tasks, but it begins to break down when agents must work with millions of security events, large vulnerability datasets, threat intelligence, case histories, reports, and other enterprise-scale information—or when multiple specialized agents need to collaborate around the same evidence.
The result is duplicated and potentially stale data, lost detail and provenance, inconsistent governance, and findings that disappear when the session ends.

Message-passing also prevents agents’ findings from becoming durable organizational knowledge.

Enterprise information should belong to the organization, not to an individual agent or session. Agents should receive governed access to shared data and bring only the evidence needed for a particular reasoning step into context.
Introducing Bricklayer’s Agent-Native Data Plane
Today, we’re introducing Bricklayer’s Agent-Native Data Plane: a governed, persistent data layer through which agents can operate on shared enterprise information without loading entire datasets into model context.

1. Persistent, Typed Data
The foundation of the architecture is Bricklayer’s Typed Content Architecture.
Enterprise data isn’t all the same shape. A table of security events is a different kind of object than a threat intelligence report. A vulnerability dataset behaves differently than an incident timeline. Rather than flattening everything into generic text or generic files, Bricklayer represents this information as persistent, typed content, objects with defined structure, metadata, and relationships appropriate to what they actually are.
That gives an agent a way to understand not just what’s inside an object, but what kind of object it is and what can be done with it.
It also changes what happens to information once it’s created. Typed content can persist across reasoning steps, agent runs, and entire investigations. Agents reference the same object rather than copying it into their individual contexts. This keeps the context window focused on reasoning rather than storage.
That persistence has to live somewhere Bricklayer can govern directly. The data plane therefore stores typed content outside individual model contexts, without modifying customers’ production systems or requiring write access to every connected source.
2. Operating on Data at Scale
Storing the data is not enough. Agents need to be able to operate on it. They can query, filter, aggregate, correlate, and transform it in place, then return only the relevant results to the model. That might mean grouping events by user, isolating a time window, or correlating activity across systems.
3. Built for Teams of Agents
This shared architecture becomes especially valuable when multiple agents collaborate: each agent can work from the underlying evidence rather than another agent’s summary.
In a security investigation, one agent might flag suspicious activity, another correlate endpoint telemetry, a third check threat intelligence, and a fourth build a timeline. Each writes persistent content that subsequent agents can inspect directly.
4. Shared Evidence with Traceable Lineage
There’s a related benefit that grows more important as the number of agents grows: consistency.
Because every finding remains linked to its supporting evidence, Bricklayer preserves lineage throughout the workflow, from the assessment to the evidence behind it and back to the originating data.
5. Governed by Design
Bricklayer has been built around the principle that agent autonomy operates within organizational boundaries, and the Agent-Native Data Plane follows the same model. Access to typed content, and access to the operations an agent can perform against it, is governed based on the agent, the data involved, the operation requested, and the policies that apply. It’s useful autonomy within boundaries a security leader sets and can verify.
An Example: The Vulnerability Exposure Spot Check
One example of this architecture at work is the vulnerability spot check, a task most large security organizations recognize immediately.
Consider a large, multi-entity organization running vulnerability management across a global function and dozens of independently operated business units, each with its own tooling. A new vulnerability becomes urgent, and someone needs to know quickly whether it actually affects anything in the environment, where, and how badly, without waiting for the next scan cycle. Done manually, that means pulling exports from half a dozen tools and reconciling them by hand across several thousand assets.
Bricklayer runs this as an agentic workflow built from two connected procedures, using persistent, typed data to hold and consolidate everything each procedure touches.
The first procedure runs daily and handles discovery: pulling from known-exploited and high-severity vulnerability sources, threat intelligence feeds, and national vulnerability databases, filtering down to the CVEs that warrant a closer look that day.
The second is the spot check itself, run once per CVE. It queries an attack surface management tool, a vulnerability scanner, a cloud asset inventory, and an XDR platform, each with its own format. The results are normalized into a single unified asset table, with duplicates resolved and each asset categorized by severity, exploitation status, and whether it’s internet-reachable. The resulting table includes vulnerability or asset-vulnerability findings used for prioritization.
The output is two artifacts drawn from that same table. The global function gets a summary report broken out by business unit. Each business unit gets the asset table underneath it, ready to act on. Both are built from the same underlying data.
From Enterprise Data to Organizational Intelligence
The Agent-Native Data Plane gives agents persistent, governed access to operational data and the findings derived from it. But data alone is not enough. Agents also need Organizational Intelligence: the organization’s accumulated memory, skills, rules, policies, procedures, and institutional knowledge.
Real enterprise security work requires agents to combine persistent data and shared evidence with this broader organizational intelligence without losing consistency or provenance. Bricklayer’s Agent-Native Data Plane provides the governed data layer for that work, enabling agents to use current evidence alongside the organizational knowledge needed to interpret it and act appropriately.
Building Infrastructure for the Agentic Enterprise
Real enterprise security operations work requires persistent data that’s shared across an AI workforce, not treated as temporary input. The work has to span many agents, many procedures, and an entire environment, without losing consistency along the way.
That’s what Bricklayer’s Agent-Native Data Plane is for. The data stays in place as shared, persistent evidence. Agents work against it directly, again and again, instead of each one collecting and re-deriving on its own. That’s the direction we believe enterprise agent architecture is headed, and it’s what we’ve built at Bricklayer.


