One agent. Four capabilities. One loop.
The Familiar is not a roster of bots. It is one AI agent with named capabilities that fire in a loop: a signal starts an investigation, the investigation produces evidence, evidence becomes a reasoned recommendation, and a response casts under the Seal. Below is exactly what each capability does today: what it reads, what it hands back to you, and where the Seal draws the line.
Investigate and Correlate build the evidence. Reasoning and Recommendations are the Familiar's proposal. Respond casts it under the Seal. Document closes the loop with an exportable, replayable receipt.
Turn a signal into a read Investigation.
Turn a raw signal or a plain-English ask into a read Investigation: the timeline, the artifacts, and a verdict, with the evidence still attached.
Inputs
- A signal landing from a connected tool (an alert, a log event, an inbound ticket)
- A plain-English ask from an analyst ("what's happening on host LON-4471 right now?")
- An entity value to pivot on (a hash, an IP, a username, a hostname)
- An existing Investigation id, to read its full thread and artifacts
Outputs
- An Investigation timeline with every message, artifact, and decision in order
- A native multi-engine verdict on each indicator, with the individual engine results kept visible (not averaged into one hidden number)
- A named entity cross-reference: every Investigation and every signal that already touches this value
- A read-only disposition summary: current status, the closure gate's pass/fail state, and the legal next moves
A phishing report at a mid-size logistics company
An analyst pastes a forwarded email into the Familiar and asks it to look at it.
The Familiar opens an Investigation, extracts the sender, the link, and the attachment hash as artifacts, and enriches each one through the org's connected tools.
It reads back a native multi-engine verdict: two engines call the attachment malicious, one calls it suspicious, one calls it clean. The spread itself is surfaced, not collapsed to a single number.
It searches the sender's domain and finds two other open Investigations that already touch it, pulled in by entity cross-reference.
It posts a one-paragraph read of what's happening, with every claim linked back to the artifact or engine result that supports it.
It stops there. Investigate never blocks, disables, or closes anything on its own; it hands the analyst an Investigation worth acting on.
Investigate sits entirely on the read side of the trust boundary. Reading, enriching, and reading disposition state never touch the Seal, because none of it writes to a privileged system or forecloses a decision. The only place Investigate can propose a write is the disposition chip (close, assign, escalate, reopen), and even that chip only fires a mutation when the analyst clicks it: the Familiar never disposes an Investigation on its own.
Match a new signal against what the platform already knows.
So duplicates collapse and related signals land in the same investigation instead of scattered across ten open tabs.
Inputs
- An incoming alert, normalized to its dedup key and its artifact values
- The set of alerts already seen in the recent window, for the same source
- The set of open Investigations and the artifacts already attached to each
Outputs
- One of three routes, decided in order: duplicate of a prior alert (no new Investigation), correlated into an existing open Investigation (shares an artifact value with it), or new Investigation opened when neither match holds
- An entity cross-reference view (the same entity-search capability that powers Investigate): every Investigation and signal sharing a given value, on demand
A repeat login anomaly
A VPN authentication anomaly signal arrives for a user account.
The Familiar checks it against the last few hours of alerts on the same source and dedup key: no exact repeat, so it isn't a duplicate.
It checks the account and source IP against artifacts on currently open Investigations and finds a match: an existing Investigation already has that same IP attached from an earlier signal.
The new signal is correlated into the existing Investigation rather than opening a second, disconnected one; the analyst sees one thread instead of two.
Later, the analyst asks "what else touches this IP" and gets every Investigation and signal that shares the value, in one answer.
Correlation is a routing decision, not an action on a privileged system, so it runs on its own; it decides where a signal lands, never what happens to the underlying host, account, or file. Nothing here can be destructive, so nothing here reaches the Seal.
Turn an approved plan into a real, multi-step response.
Cast across your connected tools, with every consequential step held at the Seal until a human says go.
Inputs
- A response plan the Familiar drafted from prose (a Spell): the steps, the tools it touches, its assumptions
- A specific privileged action to propose (isolate a host, disable an account, block an indicator), with its rationale and the evidence behind it
- An existing Spell, to rehearse or edit before trusting it live
Outputs
- A gate decision on every proposed action: auto-execute (low blast radius, runs), require approval (stops at the Seal with a rationale and a reversible plan), or deny
- A full multi-step run, not one representative action: each step posts to the Investigation as it runs, auto-run steps marked as such, the first write held at the Seal
- A rehearsal result: the same plan walked end to end against a real Investigation, side-effect-free, before you ever trust it live
- An explanation of any decision on demand: which policy version fired, which rule, what blast radius was computed
Containing a confirmed phishing Investigation
The analyst approves the plan the Familiar drafted: quarantine the email, disable the compromised account, isolate the host.
The Familiar casts the Spell. Quarantining the email is low blast radius and reversible; it auto-runs, and the Investigation timeline shows it happened.
Disabling the account is a privileged write. It's proposed to the gate, the gate returns require-approval, and the run halts there with its rationale and a reversible undo path attached.
A Seal appears in the analyst's queue: "Disable account jdoe. Reversible. Waiting on your approval." The analyst clicks approve.
The run resumes from exactly that step; isolating the host follows the same propose-then-Seal path.
Every step, every tool call, and every decision is on one record the analyst can replay later and explain to anyone who asks why the account went dark.
This is the capability the Seal exists for. The Familiar can plan, recommend, and rehearse anything; it can never execute a privileged or irreversible action directly. Every proposal crosses through the same deterministic policy gate, which lives outside the model and decides auto-execute, require-approval, or deny based on blast radius and reversibility, never on what the model "feels confident about." Approving or rejecting a Seal is always a human's client-side click; there is no tool call, for the Familiar or anyone else, that can decide a Seal on its own.
Keep a living, audit-ready record of every Investigation.
As it happens, so closing an Investigation never means starting the writeup from a blank page.
Inputs
- The Investigation's full message thread (agent findings, analyst notes, system events)
- Every artifact attached to the Investigation, and whether each carries a verified chain-of-custody hash
- Every privileged-action decision on the Investigation and its linked approval
Outputs
- A timeline narrative: auto-drafted, chronological, factual, no certification needed because it's a faithful transcription of what happened
- An executive summary, a root-cause note, and lessons-learned items: auto-drafted as a starting point, but explicitly flagged as a draft requiring analyst certification before it's considered final
- A completeness check: whether an assignee is set, whether a closure reason is recorded, whether every artifact is hashed, whether every privileged-action approval has its provenance recorded, and whether a human analyst note exists on the Investigation
- A record that regenerates itself automatically as the Investigation opens, updates, gets an approval decision, and closes, so it's never stale by the time someone reads it
Closing out a contained incident
As the Investigation moves through investigation and response, the record updates itself: every message, every artifact, every gate decision folds into the timeline without anyone asking for it.
When the analyst moves to close the Investigation, the completeness check flags one gap: no human analyst note has been posted yet.
The analyst adds a one-line note. The gap clears.
The draft executive summary reads back the shape of the Investigation: what opened it, what was investigated, what was contained, how many actions needed approval.
The analyst reviews it, edits a sentence, and certifies it. The certification stamp (who, when) is permanent; the draft flag comes off.
The Investigation closes with a complete, audit-ready record already assembled, not a promise to write one later.
An on-demand executive-summary report you can pull up as its own artifact, edit conversationally, and export as PDF or Markdown, is in build and not yet available. Today's Document capability is the always-on case Dossier described above; the exportable report is a planned extension of it, not a shipped feature.
Document never writes to anything outside the Investigation record itself, and its most consequential fields (executive summary, root cause, lessons learned) are never presented as final without a human certifying them first. There's no privileged action here for the Seal to gate; the analogous control is the certification step: an auto-drafted section stays visibly a draft until a human signs it.
Watch the loop run end to end.
A three-minute interactive tour, ungated, follows one Investigation through Investigate, Correlate, Respond, and Document.