The Brain

An alert names a host. It never says who owns it, what it supports, whether the behaviour is expected, or whether you’ve seen it before. The Brain is where those answers live, built and kept current from the systems you already run. The difference shows up before the evidence does. An agent with the Brain starts on the right entity — this person’s managed device, the service this host supports, the three times this pattern was benign — instead of opening five integrations to find it. The discovery work disappears; the investigation starts at the analysis.

​

Two halves, side by side

Graphs are connections. Memory is learning. Agents need both.

​

What makes it work

​

How the graph is built

Assets are the base layer: one row per real resource, keyed by its native provider id — an AWS ARN, a GitHub repo, a Datadog service, a Vercel project, a managed laptop. Re-syncs update the same row in place, so an asset is durable and anything attached to it survives. Systems are the derived layer. A correlation engine reads each asset’s identifiers and buckets the ones that agree: the same service name, the same EC2 instance, the same repository URL, the same Aurora cluster, the same GitHub topic or org custom property. Any bucket with two or more members becomes a System — which is how a Datadog service, the AWS resources tagged for it, and the repo it is built from become one thing an agent can reason about. Systems are rebuilt from scratch on every sync in an atomic swap. If a rebuild fails, the previous ones stay intact and the next sync tries again. That’s why annotations and knowledge anchor to the durable asset, never to the derived grouping. An asset can belong to several Systems at once — one per correlation rule it matches.

​

Where assets come from

• Integration-discovered — a provider actually saw it. Cloud resources and their per-account posture, repositories with their rulesets, workflows, alert counts and CODEOWNERS, observability services and monitors, hosting projects and deployments, managed devices and their owners.
• Correlation-inferred — synthesized from another asset’s identifiers, so a repository referenced in cloud tags still correlates even with no source-control integration connected.
• Agent-recorded — written during an investigation for things no integration owns: an attacker IP, a vulnerable package, an external domain. These survive correlation rebuilds.

​

Memory and timelines

Signals, rule fires, alerts, issues, remediations, and linked Jira or Linear tickets all point back at assets. Ask for any resource’s history and you get a single merged timeline instead of six queries. Assets are resolved to signals again at rule-fire time, so an asset discovered today still picks up the fires that referenced it last week.

​

Knowledge and business context

On top of the catalog sits curated knowledge — cards describing systems, services, platforms, datastores, and tools — plus workspace-level business context. Knowledge arrives two ways:

• Recurring feeds pull from Jira and Notion on a cadence, each with its own cursor.
• One-time intake parses uploaded documents and URLs, extracts candidate facts, and writes them as proposals.

Both paths bridge back to catalog assets, so a card that describes “the payments platform” can point at the real infrastructure it means.

​

Nothing unreviewed reaches a prompt

This is the load-bearing rule. Workspace-scoped facts are filtered before they enter any agent prompt: a fact reaches the model only if a human authored it or a human confirmed it. An unconfirmed agent proposal is visible in the UI for review and invisible to the prompt. That is deliberate prompt-injection defence. Agents read attacker-influenced material every day — alert payloads, repository files, external pages, vendor responses. Without the confirmation gate, “the Brain remembers what it learns” would mean “an attacker can write into every future investigation’s system prompt.” Locked knowledge elements force every change through the same review. Each proposed fact carries its origin, so a reviewer can see which run produced it and from what.

​

Writing back

During a run, an agent can:

• Annotate an asset or the workspace with a durable, attributed fact.
• Record assets the investigation turned up that no integration owns — every one in a single call.
• Link entities that belong together; those links feed correlation as extra join keys, exactly like discovered identifiers.

Writes are permission-gated and every one is attributed to the agent’s job, so a claim in the Brain always traces to the run that made it. The Knowledge Maintainer agent owns the periodic drain and the editorial policy for what gets kept.

​

What agents actually call

The Brain is exposed to agents as always-on tools, scoped to the workspace and the job: list and read assets, list correlated systems, search knowledge, read business context, search the merged timeline across assets, and the write paths above. There is no configuration step — connect an integration and the tools have something to answer with.