Methodology
- 1 Read the alert; pull the customer profile, the flagged transactions, and prior alerts.
- 2 Identify the material subjects: the account holder and the significant counterparties on the flagged flows.
- 3 For each material subject, run sanctions screening (delegating to Cerberus) and an adverse-media check.
- 4 Construct a dated timeline and name the typology, explaining how the facts fit it and noting exculpatory facts.
- 5 List the specific red flags, each grounded in a transaction, a profile mismatch, a screening result, or an adverse-media finding.
- 6 Recommend SAR, continue-monitoring, or no-SAR. Over-filing defensively is itself a failure; reserve SAR for an articulable basis for suspicion.
Sandboxed tools
In-process MCP tools only. Built-in tools disabled, settingSources [], permissionMode bypassPermissions. The only ground truth is the tools.
get_alert read The escalated alert.
get_customer read The customer's KYC profile and expected activity.
get_transactions read The customer's transactions (all, or specific ids).
get_prior_alerts read Other alerts on the same customer.
screen_subject A2A OFAC SDN (via Cerberus) Sanctions-screens a party; on a candidate match it delegates to Cerberus and returns its disposition.
search_adverse_media read Checks a named party against the adverse-media corpus.
compile_packet commit Compiles the final investigation packet. Called exactly once.
Outcome contract
A full investigation packet: subjects with their screening and media results, a timeline, the transactions, red flags, the typology, and a SAR / no-SAR recommendation.
▸ the validated schema (InvestigationPacket)
type InvestigationPacket = {
customer: { id, name, type, riskRating, country, profile }
subjects: { name, role, sanctionsResult?, adverseMedia? }[]
timeline: { date, event }[]
transactions: { id, date, amount, currency, direction, method, counterparty? }[]
redFlags: string[]
typologyAssessment: string
recommendation: "SAR" | "no-SAR" | "continue-monitoring"
recommendationRationale: string
}Grounding
Governance seams
The three trust boundaries a runtime governance layer clamps onto. Shown here ungoverned, so you can see exactly what would be inspected, redacted, or blocked.
The Bloodhound methodology plus the growing case file (alert, customer, transactions, screening results).
governor → Govern how much of the case the orchestrator may hold at once.
Each read's I/O, and the screen_subject call that spins up Cerberus as a real sub-agent and returns its disposition.
governor → See the delegation itself: which agent handed what to which, and govern the A2A boundary.
The compiled packet written to the case journal and handed to Scribe.
governor → Require the packet to meet an evidentiary bar before it can feed a filing.
When Bloodhound screens a party, a real second agent (Cerberus) runs inside the tool call and returns its disposition. The tool plane is where one agent hands work to another, so it is exactly where a governance layer would observe and gate agent-to-agent delegation.
Evals & guardrails
- No-SAR after investigation. Reconciles activity with a documented explanation and declines to file rather than defensively over-filing.
- Sanctions nexus. Surfaces a Cerberus block into the packet's subjects and red flags rather than dropping it.
Orchestration
- ⇢Fed by Sift
- ⇢Delegates screening to Cerberus (A2A)
- ⇢Hands the packet to Scribe