The agent society

Three orders. One color spine.

The agents are not a black box. They are organized into three orders, each with a job, a body of work it owns, and a frame it follows. Attack detects, Defend responds, Scholar records. The color spine carries that mapping across the whole product.

At a glance

The society, on one screen.

Each order owns one part of the Library and reads through one frame. The same colors follow them everywhere in the product.

Detect
Attack Watchers

Read the omens, correlate the signals, and name what is happening. They open and build the inquiry.

Owns
Omens
MITRE
ATT&CK
Respond
Defend Watchers

Cast response spells to contain, evict, and restore, under gated authority. Destructive casts pause at a seal.

Owns
Spells
MITRE
D3FEND
Record
Scholar Watchers

Document the inquiry, collect the seals, and keep your ticketing in sync: Jira, ServiceNow, Resilient.

Owns
Scrolls
Record
& sync
Attack detects Defend responds Scholar records every step
Detect
Attack Watchers

The Attack Watchers read the omens. They watch the detections flowing in from your tools, correlate the ones that share an entity, and name what is actually happening, not a hundred disconnected alerts but one named threat with a story behind it. They open the inquiry and build its case.

They are organized by MITRE ATT&CK, so every detection lands against a known tactic and technique. That structure is what lets them tell coincidence from a kill chain.

JobDetect and name
OwnsOmens
FrameworkMITRE ATT&CK
OutputThe named inquiry
Respond
Defend Watchers

The Defend Watchers cast the response Spells: contain the host, evict the attacker, restore the account. They act under gated authority, never on their own recognizance. A low-risk cast runs; a destructive or high-blast-radius cast pauses at a Seal with its rationale and a reversible plan, and waits for a human.

They are organized by MITRE D3FEND, the defensive counterpart to ATT&CK, so each Spell maps to a recognized countermeasure rather than an ad-hoc script.

JobRespond, gated
OwnsSpells
FrameworkMITRE D3FEND
GateSeal on destructive
Record
Scholar Watchers

The Scholar Watchers write it all down. They document the inquiry as it unfolds, prove the approval chain by recording every Seal and who cleared it, and keep your external ticketing in sync. They own the Scrolls: the durable record an auditor or an incident review can read end to end.

The sync is two-way with Jira, ServiceNow, and Resilient, so the inquiry and your ticket of record never drift apart. Update one and the other follows.

JobRecord and prove
OwnsScrolls
SyncTwo-way tickets
ToolsJira, ServiceNow, Resilient
One inquiry, three orders

They hand the same case down the line.

The orders are not silos. They work one inquiry in sequence, each picking up where the last left off, with the Scholars recording the whole way and the Seal standing between the proposal and any irreversible action.

Attack opens

The threat gets named

Attack Watchers correlate the omens into one named inquiry and lay out what is happening across the affected entities.

Defend proposes

The response gets cast

Defend Watchers propose the Spells to contain and evict. Low-risk casts run; destructive casts wait at a Seal.

Scholar records

The proof gets written

Scholar Watchers keep the Scroll and the external ticket in sync, with every Seal and approver on the record.

The Seal stands between proposal and action
Every order operates under the same charter. A watcher proposes; a human disposes. Any destructive or high-blast-radius cast stops at a Seal with its rationale and a reversible plan.
Human approves
on approve
Response cast
Contained, reversible, logged to the inquiry
See the orders at work

Watch one inquiry, end to end.

A 30-minute walkthrough on your real triage flow. See Attack name it, Defend propose the response, Scholar record the proof, and the Seal hold the line.