How Bricklayer Gives Multi-Agent Security Teams a Shared, Governed Way to Work With Alerts, Tables, and Reports

Ask any analyst what a real investigation looks like and you will hear about scale. A threat intelligence lookup that returns pages of data on a single indicator. A CSV export with thousands of rows. An alert payload so large a human couldn’t skim it, let alone triage it.

Ask any AI system what it does with that same content, and the answer is almost always the same. It turns it into text, and it stuffs that text into a prompt.

That approach works, until the content gets big enough. In security operations, it doesn’t take long to get there.

Everything Becomes Text, Until It Can’t

Today’s AI platforms are built around a simple, largely unquestioned assumption: everything eventually becomes prompt text. Documents are converted into text. Structured data is serialized into text. Reports, spreadsheets, alerts, and tool responses all get flattened into the same undifferentiated format before they ever reach a model.

For small, simple interactions, this works fine. But it strips away the structure that makes enterprise information valuable in the first place, and it falls apart at scale. As workflows get more sophisticated and agents hand work off to one another, prompts grow larger with every step, until organizations run into model context limits, rising inference costs, added latency, and reasoning that degrades under the weight of everything it’s being asked to hold at once.

The common workaround is truncation: read as much of an object as fits, and drop the rest. It’s the simplest way to deal with oversized content, and it’s a poor one. The information in what gets dropped doesn’t stop mattering just because it stopped fitting.

This isn’t a prompt engineering problem. It’s an architecture problem, and it needed an architectural fix.

Introducing Typed Content Architecture

Bricklayer’s Typed Content Architecture replaces “everything becomes text” with a different model. Every artifact an agent works with is represented as a typed content object that preserves its native structure throughout execution, rather than being copied and flattened into a prompt.

Reports remain reports. Tables remain tables. JSON remains JSON. Each object carries its own identity, metadata, and relationships, and exposes capabilities appropriate to its type, instead of being reduced to the same generic string as every other piece of content.

Think of it as memory for a procedure run, the way RAM works for any running process on your computer. If you have a dozen browser tabs open, Chrome doesn’t copy every page into your clipboard just in case you need it later. It holds each page in memory and pulls from it the moment you actually need something. Typed Content Architecture gives Bricklayer procedures the same ability. Large objects, like a threat intelligence response, a table, or a full alert payload, live in that memory as intermediate objects that agents can query, search, and retrieve from as needed, instead of being force-fed into every prompt from the start.

Rather than exchanging large payloads, agents exchange references to governed content, and pull only the specific piece they need to do the job in front of them.

Solving AI’s Attention Problem

There’s a second reason this matters, and it goes beyond context window limits.

Large language models have what’s known as an attention problem. Feed a model a very long piece of text, and it won’t weigh every part of it equally. Models tend to anchor on the beginning and the end of what they’re given, and the material in the middle gets less consideration, even when it holds the answer. This is a structural property of how these models process long contexts. Fitting content into a window is not the same thing as reasoning over it well.

The fix isn’t a bigger window. It’s giving the model a way to go find what it needs instead of holding everything in view at once. Typed Content Architecture does this by pairing each content type, whether JSON, CSV, XML, or HTML, with specialized tools that let an agent search within it, retrieve specific elements from it, and aggregate across it. A CSV object exposes tools for filtering and aggregating rows. A JSON object exposes tools for retrieving nested elements. Rather than straining to hold an entire alert in its attention at once, the model uses these tools to find exactly what it needs, when it needs it.

One Source of Truth Per Object

This same model also changes what happens when multiple agents are working the same investigation: they end up reasoning from the same object, not their own copy of it.

In a multi-agent workflow, several agents may need the same piece of content: a table, a JSON payload, a report. If each agent works from its own copy, those copies can drift. One agent might act on a version of the data that’s since been updated, filtered, or corrected by another. In a coordinated investigation, that kind of inconsistency is how agents end up reasoning toward different conclusions from what should have been the same evidence.

Typed Content Architecture prevents that by design. Content exists once and is referenced, not recreated, everywhere it’s needed. Every agent working with a given object, whether it’s tabular data, a JSON response, or something else, is working with the same underlying source, retrieved through tools built for that content type rather than a private copy passed hand to hand. That consistency is what makes multi-agent decision-making trustworthy at scale: agents can collaborate on the same investigation with confidence they’re reasoning from identical, current information, and every decision can be traced back to a single, governed source.

It also keeps every query lean. When content is referenced rather than duplicated into each agent’s prompt, the size of what actually needs to be passed around stays close to what each step requires, instead of growing every time another agent joins the workflow. A five-agent investigation doesn’t mean five copies of the same table competing for context. It means five agents pointing to the same object and pulling only what each one needs.

The Next Evolution of MACE

Typed Content Architecture is the newest layer in Bricklayer’s Multi-Agent Context Engineering (MACE), the discipline for designing enterprise AI systems where context is deliberately engineered, accumulated, and shared across collaborating agents, rather than improvised prompt by prompt.

insights are the individual, structured pieces of information generated by an agent while performing a task. Insight Groups organizes those insights into task-specific, investigative artifacts. Mentions gave analysts direct control over exactly what context flows into the next step. Typed Content Architecture extends that same discipline to the raw enterprise content underneath all of it: the documents, tables, and structured data that insights and insight groups are built from in the first place.

Programming languages evolved beyond raw memory by introducing types. Databases evolved beyond flat files through structured schemas. Enterprise AI is entering a similar transition. As organizations deploy autonomous agents, information can no longer be treated as unstructured text. It needs identity, structure, relationships, and governance. Typed Content Architecture is built to be generic and extensible: new enterprise content types can be introduced without redesigning how the platform executes.

Most conversations about multi-agent AI focus on how agents talk to each other: routing, handoffs, orchestration. Fewer address what those agents are actually talking about. An architecture built around structured, governed content is a different foundation for multi-agent systems than one built around passing prompt text back and forth, and it’s a foundation that holds up as the number of agents, content types, and workflows keeps growing.

What This Enables

With content represented as governed, typed objects instead of flattened text, Bricklayer procedures gain:

  • Consistent handling of documents, tables, JSON, code, and future content types through a single, unified model
  • Efficient access to enterprise-scale content, including full alert payloads, large tool responses, and large datasets, without continually expanding prompt size
  • The ability to merge, aggregate, and reason across multiple content types within a single workflow
  • A clear record of where every object came from, and everywhere it’s been used since
    Runtime governance over how content is accessed, shared, and transformed
  • Reusable execution artifacts that persist beyond a single prompt

None of this changes what an analyst sees on screen today. What changes is how the system performs behind it: whether it holds up when the content is ten pages long instead of ten words, and how quickly it can find the one detail that actually matters inside it.

Built for What Comes Next

Typed Content Architecture is available now as part of the Bricklayer platform, and it’s foundational to where the platform is headed next, including deeper agent memory, expanded runtime governance, and coordinated multi-agent execution across larger and more complex enterprise environments.

Enterprise AI doesn’t get more reliable by making prompts bigger. It gets more reliable by giving agents a real information architecture to work from, one where content keeps its structure, its identity, and its meaning all the way through execution.

If you’re ready to see what that looks like in your environment, schedule a demo.