AEGIS Architecture: An Autonomous Financial Crime Investigation System with LangGraph, AutoGen, and Reflexion

Fully Autonomous Financial Crime Investigation System Multi-layer, multi-agent architecture with LangGraph + AutoGen + Reflexion

Financial crime investigations are rarely solved reliably with a single model output, a single rule engine, or a single threshold check. A transaction amount may look suspicious, but the amount alone may not be enough to indicate crime. A receiving country may be high-risk, but the transaction context may still be legitimate. A newly opened account may receive a high-volume transfer, but understanding whether this is part of an organized laundering network, a fraud chain, or a normal commercial activity requires broader context.

For this reason, financial crime investigation should not be treated only as a “transaction scoring” problem. It should be treated as a multi-step investigation process.

AEGIS is a multi-layered, multi-agent, and observable financial crime investigation architecture designed around this idea. The system autonomously triages suspicious financial transactions, initiates deeper analysis when needed, coordinates specialized agents, performs regulatory assessment, critiques its own output through a Reflexion-style loop, and produces an explainable final investigation report.

The goal of this architecture is not merely to “detect financial crime with an LLM.” The real goal is to combine LLMs, deterministic rules, graph analysis, specialized agents, state-machine orchestration, and quality-control loops into an auditable investigation workflow.

1. The Problem: Why Financial Crime Investigation Is Not a Single-Decision Problem

Traditional financial crime monitoring systems mostly rely on fixed rules. For example:

• Flag transactions above a specific amount.
• Review transactions close to the 10,000 USD reporting threshold.
• Escalate transfers to high-risk countries.
• Monitor unusual movements from newly opened accounts.
• Treat accounts with high transaction velocity as risky.
• Generate alerts for unusual IP, device, or location changes.

These rules are useful for detecting certain risks. However, financial crime behavior often does not reveal itself through one isolated signal.

For example, in a money laundering scenario, transaction amounts may be deliberately kept below reporting thresholds. Funds may be split across multiple accounts. Temporary intermediary accounts may be used. The receiving account may be newly opened. Transfers may be distributed across different countries, channels, and time windows. In such a case, a single transaction may look harmless, while the broader transaction network may reveal a strong risk pattern.

Similarly, in account takeover cases, looking only at the transaction amount is not enough. The account may have been accessed from an unusual location. High-volume transfers may follow shortly after. Recipient accounts may never have been used before. The user behavior may not match the historical customer profile.

Therefore, reliable financial crime investigation requires multiple dimensions to be evaluated together:

• Transaction amount and transaction type.
• Sender and receiver account profiles.
• Account age and historical behavior.
• Geographic risk and country relationships.
• IP, device, channel, and location information.
• Transaction velocity over time.
• Sender-receiver graph relationships.
• Second- and third-degree account connections.
• Regulatory obligations.
• Explainability and audit trail requirements.

This is where an agentic AI approach becomes valuable. Financial crime investigation is fundamentally a process that requires multiple expert roles to work together.

2. The Core Idea Behind AEGIS

AEGIS treats financial crime investigation not as a single LLM call, but as a controlled investigation team made up of specialized agents.

The core thesis is:

In financial crime cases, isolated signals are often insufficient. Reliable decisions require transaction context, account behavior, counterparty networks, geographic risk, regulatory obligations, and agent-level consensus to be evaluated together.

AEGIS is designed to answer the following questions systematically:

• Is this transaction risky at first glance?
• Why should this transaction be escalated or closed?
• Which fraud or laundering typology does the behavior resemble?
• Is there a suspicious pattern in the account network?
• Does the transaction require SAR, CTR, EDD, or another compliance action?
• Do the agent findings support each other?
• Does the final report include sufficient evidence, scoring, and rationale?
• If quality is insufficient, which agent should re-investigate which finding?

Each of these questions requires a different area of expertise. For that reason, AEGIS is built on three main frameworks:

This separation is intentional. LangGraph is not used to manage agent conversations; it is used to control the investigation flow as a state machine. AutoGen is not used for state orchestration; it is used for specialized agent collaboration. Reflexion is not used for workflow management; it is used for quality evaluation and self-improvement.

3. Architecture Overview

The diagram below summarizes the high-level architecture of AEGIS.

The diagram contains seven main areas:

1. Problem-framework mapping.
2. Core architecture flow.
3. AutoGen collaboration layer.
4. Reflexion self-improvement loop.
5. Data engine.
6. Agent anatomy.
7. Observability and outputs.

This separation reflects the main architectural decision: the system is not one large agent. It is an event-driven investigation platform with separated responsibilities, shared state, quality-control loops, and observable outputs.

4. Architectural Principles

Three core principles shape the AEGIS design.

4.1 Each Framework Should Be Used Only Where It Is Strongest

One common mistake in multi-agent systems is mixing the responsibilities of different frameworks.

For example:

• Trying to manage every agent conversation in detail with LangGraph.
• Using AutoGen as if it were a state machine.
• Reducing Reflexion to a simple “try again” mechanism.
• Replacing deterministic decision logic with an LLM.
• Giving every agent the same context and producing an uncontrolled discussion.

AEGIS deliberately avoids this confusion.

This approach keeps the system modular, controlled, and auditable.

4.2 The LLM Should Support Decisions, Not Be the Sole Decision-Maker

In high-risk domains such as financial crime, making the LLM the direct decision-maker is not a reliable design choice. LLMs are strong at contextual interpretation, typology explanation, natural-language reporting, and connecting findings. However, they should always be supported by deterministic signals, rules, scores, and auditable calculations.

In AEGIS, each agent is designed to work in two modes.

Deterministic mode

This mode always runs. Example checks include:

• Amount-threshold analysis.
• Structuring detection.
• High-risk jurisdiction checks.
• Account-age checks.
• Velocity analysis.
• IP and location inconsistency.
• Graph degree and hub indicators.
• SAR / CTR / EDD rule checks.

LLM-assisted mode

This mode runs when model access is available. The LLM adds value in areas such as:

• Explaining findings in natural language.
• Interpreting likely financial crime typologies.
• Summarizing relationships between agent findings.
• Making the final report easier to read.
• Detecting weak or missing rationale during Reflexion.
• Producing the Lead Investigator synthesis.

In this design, the LLM strengthens the system, but the system’s basic operability does not depend on the LLM. If LLM access becomes unavailable, AEGIS continues to operate in a more limited but functional deterministic mode.

4.3 Autonomy Must Be Observable

One of the biggest risks of autonomous systems is becoming a black box. In financial crime investigation, this is unacceptable. The result of a decision is not enough; the reasoning path behind the decision is equally important.

For this reason, AEGIS publishes events at each important step:

TRANSACTION_INGESTED
TRIAGE_COMPLETED
ALERT_ESCALATED
FORENSIC_FINDINGS_READY
NETWORK_ANALYSIS_COMPLETED
COMPLIANCE_REVIEW_COMPLETED
AGENT_REFLECTION
REINVESTIGATION_REQUESTED
REPORT_GENERATED

These events can be visualized on a dashboard, logged, and stored as part of an audit trail.

This makes it possible to answer questions such as:

• Why was the transaction escalated?
• Which agent produced which finding?
• Which signals contributed to which score?
• Why did Reflexion request re-investigation?
• Which evidence was used in the final report?
• Which actions require human approval?

5. High-Level System Architecture

The main components of AEGIS can be summarized as follows:

This structure treats the investigation lifecycle as an explicit state machine. Agents are not tightly coupled to each other. Instead, they communicate through a shared InvestigationState.

This separation makes the system easier to maintain:

• If orchestration changes, agent implementations do not necessarily break.
• If a new agent is added, the state schema can be extended in a controlled way.
• The dashboard only listens to events, so it is not dependent on agent internals.
• The Reflexion layer evaluates final findings and quality criteria.
• The reporting layer relies on structured outputs rather than raw agent conversations.

6. InvestigationState: The Shared Memory of the System

One of the most important structures in AEGIS is the InvestigationState object. This state carries all information accumulated throughout the investigation.

A simplified state schema may look like this:

from typing import TypedDict, List, Dict, Optional, Anyclass InvestigationState(TypedDict):
    transaction_id: str
    transaction: Dict[str, Any]
    triage_score: Optional[float]
    triage_flags: List[str]
    escalation_required: bool
    forensic_findings: Dict[str, Any]
    network_findings: Dict[str, Any]
    compliance_findings: Dict[str, Any]
    agent_messages: List[Dict[str, str]]
    risk_scores: Dict[str, float]
    reflection_score: Optional[float]
    reflection_notes: List[str]
    reflection_round: int
    needs_reinvestigation: bool
    final_risk_level: Optional[str]
    recommended_actions: List[str]
    final_report: Optional[Dict[str, Any]]

This state structure provides several advantages.

6.1 Agents remain loosely coupled

The Forensic agent does not need to know the internal implementation of the Network agent. The Network agent does not need to know the prompt structure of the Compliance agent. Each agent reads the relevant parts of the state and writes its own findings back into it.

6.2 Debugging and audit become easier

After an investigation, the following questions can be answered:

• Which risk flags did Triage produce?
• Which related accounts did the Network analysis identify?
• Why did Compliance recommend filing a SAR?
• Why did Reflexion assign a low quality score?
• Which scores contributed to the final risk level?

The answers can be extracted from the state history.

6.3 Checkpointing becomes possible

When the state is checkpointed, long-running investigations can resume from where they left off. In production, this should be supported by durable storage instead of in-memory persistence.

Examples include:

• PostgreSQL.
• Redis.
• Durable LangGraph checkpointer.
• Object storage.
• Case management database.

7. Data Engine: Synthetic but Meaningful Financial Crime Data

The Data Engine layer in AEGIS does not simply generate random transactions. Its purpose is to simulate financial crime patterns in a controlled way.

This is important because testing agentic systems only with simple examples is misleading. The system must be exposed to different risk scenarios, low-risk transactions, false positive cases, and complex network relationships.

The Data Engine can generate the following entities.

7.1 Transaction objects

Each transaction may contain fields such as:

7.2 Account profiles

Account profiles should contain more than an account ID. The system can use profile attributes such as:

7.3 Synthetic fraud patterns

The Data Engine can be used to generate specific financial crime patterns:

These synthetic patterns can be used to test agent behavior and demonstrate realistic scenarios on the dashboard.

8. LangGraph Orchestration Layer

The LangGraph layer manages the investigation workflow. The goal is not simply to execute functions sequentially. Financial crime investigation is conditional, cyclic, and stateful.

A basic state diagram can be represented as follows:

8.1 Ingest node

The Ingest step receives the transaction data and initializes the state.

This step may perform:

• Transaction schema validation.
• Missing-field checks.
• Data normalization.
• Currency normalization.
• Country-code normalization.
• Account-profile lookup.
• Previous-alert lookup.
• Initial event publishing.

Example output:

{
  "transaction_id": "67ED5F922066",
  "status": "ingested",
  "schema_valid": true,
  "enriched_fields": [
    "sender_profile",
    "receiver_profile",
    "country_risk",
    "historical_velocity"
  ]
}

8.2 Triage node

The Triage step performs fast risk assessment.

The goal is to avoid sending every transaction into a costly, multi-step analysis chain. Low-risk transactions are closed early. Suspicious transactions are routed to deeper investigation.

Triage signals may include:

• Amount threshold.
• 9K–10K band.
• High-risk country.
• New receiver account.
• Unusual location.
• Transaction velocity.
• Account with previous alerts.
• Cross-border transfer.
• Transaction type outside expected profile.

Example triage output:

{
  "triage_score": 0.76,
  "risk_level": "medium_high",
  "flags": [
    "amount_near_reporting_threshold",
    "receiver_high_risk_country",
    "new_receiver_account",
    "cross_border_wire"
  ],
  "escalation_required": true
}

8.3 Conditional routing

One of LangGraph’s most important contributions is conditional routing.

For example:

def route_after_triage(state: InvestigationState) -> str:
    if not state["escalation_required"]:
        return "report"
    return "forensic"

Routing after Reflexion can also depend on the quality score:

def route_after_reflection(state: InvestigationState) -> str:
    if state["reflection_score"] >= 0.80:
        return "report"
    if state["reflection_round"] >= 3:
        return "report"
    return "forensic"

This prevents the system from entering an infinite loop. Reflexion can initiate only a limited number of re-investigation rounds, such as max_reflection_rounds = 3.

9. AutoGen Collaboration Layer

The AutoGen layer enables structured discussion among specialized agents. The goal is not to make agents talk randomly, but to give each agent a clear role, responsibility, and output format.

The core agents in AEGIS are:

9.1 Triage Specialist

This agent performs a fast evaluation. Its job is not to make the final decision, but to decide whether the transaction should move into deeper investigation.

Focus areas include:

• Amount threshold.
• High-risk jurisdiction.
• New account behavior.
• Velocity.
• Unusual channel.
• Mismatch with historical customer profile.

Example output:

{
  "agent": "Triage Specialist",
  "score": 0.74,
  "decision": "escalate",
  "reasoning": [
    "Transaction amount is close to the reporting threshold.",
    "Receiver account is newly created.",
    "Transfer is cross-border and routed to a high-risk jurisdiction."
  ]
}

9.2 Forensic Investigator

The Forensic agent performs behavioral analysis. The core question is:

Which financial crime or fraud typology does this transaction resemble?

Focus areas include:

• Structuring.
• Layering.
• Mule account behavior.
• Account takeover.
• Synthetic identity.
• Rapid fund movement.
• Unusual beneficiary behavior.
• Profile mismatch.

Example output:

{
  "agent": "Forensic Investigator",
  "suspected_typology": "money_laundering_structuring",
  "confidence": 0.68,
  "findings": [
    "Amount is deliberately below the 10K reporting threshold.",
    "Receiver account age is low relative to transaction value.",
    "Transaction channel and destination are inconsistent with historical profile."
  ]
}

9.3 Network Analyst

The Network Analyst examines the transaction not as an isolated event, but as part of a relationship graph between accounts.

Potential graph signals include:

• Node degree.
• In-degree / out-degree.
• Betweenness centrality.
• Hub behavior.
• Bridge account behavior.
• Suspicious paths.
• Circular flows.
• Shared beneficiaries.
• Second-degree counterparties.
• Country-risk clusters.

Example output:

{
  "agent": "Network Analyst",
  "network_risk": 0.81,
  "findings": [
    "Receiver account has unusually high in-degree for its account age.",
    "Second-degree connections include accounts linked to high-risk jurisdictions.",
    "The account behaves as a temporary aggregation node."
  ],
  "recommended_expansion": [
    "Analyze 90-day transaction history.",
    "Expand graph to second-degree counterparties.",
    "Check shared device or IP indicators."
  ]
}

9.4 Compliance Officer

The Compliance agent converts technical risk findings into regulatory actions.

Focus areas include:

• SAR requirements.
• CTR threshold.
• Enhanced Due Diligence.
• Cross-border reporting.
• Sanctions-screening needs.
• Case-hold recommendation.
• Human-review requirement.
• Audit documentation.

Example output:

{
  "agent": "Compliance Officer",
  "actions": [
    "File SAR",
    "Initiate enhanced due diligence",
    "Place temporary hold pending human review",
    "Review related accounts for 90-day lookback"
  ],
  "rationale": [
    "Transaction shows structuring indicators.",
    "Receiver account is linked to high-risk jurisdiction.",
    "Network expansion indicates potential layering behavior."
  ]
}

9.5 Lead Investigator

The Lead Investigator synthesizes all agent outputs. This agent does not invent new evidence. Its role is to combine existing findings, flag contradictions, and produce the final risk assessment.

Example output:

{
  "final_risk": "High",
  "final_score": 0.71,
  "typology": "Money laundering - structuring and international layering",
  "key_evidence": [
    "Amount close to reporting threshold",
    "High-risk destination country",
    "New receiver account",
    "Suspicious second-degree network links"
  ],
  "recommended_actions": [
    "File SAR",
    "Apply temporary account hold",
    "Perform 90-day lookback",
    "Expand investigation to connected accounts"
  ]
}

10. Reflexion Self-Improvement Loop

The Reflexion layer is the quality-control mechanism of AEGIS. The purpose is not to operate with a basic “try again” approach.

Reflexion does three things:

1. Evaluates the generated findings.
2. Detects missing or contradictory points.
3. Produces targeted re-investigation instructions when needed.

The core loop is:

10.1 Reflection quality criteria

Reflexion can evaluate outputs using criteria such as:

10.2 Example Reflection output

{
  "quality_score": 0.64,
  "needs_revision": true,
  "issues": [
    "Network analysis only considered direct counterparties.",
    "Compliance recommendation lacks explicit rationale for account hold.",
    "Final risk score is high but forensic confidence is moderate."
  ],
  "targeted_guidance": [
    {
      "agent": "Network Analyst",
      "instruction": "Expand analysis to second-degree counterparties and identify high-risk jurisdiction links."
    },
    {
      "agent": "Compliance Officer",
      "instruction": "Clarify whether SAR and temporary hold are justified by available evidence."
    }
  ]
}

After this output, the system does not restart the entire investigation blindly. Instead, it sends targeted re-investigation instructions to the relevant agents.

10.3 Why Reflexion matters

Using multiple agents does not automatically improve quality. If poorly controlled, it can even reduce quality. Agents may repeat each other, make unsupported assumptions, or produce overly confident statements.

Reflexion acts as a quality brake for the system.

11. Risk Scoring Approach

In AEGIS, the risk score is not a single monolithic value. Multiple signals and agent outputs are combined.

Example signals:

A simplified scoring formula may look like this:

programmatic_score =
    structuring_score * 0.30 +
    jurisdiction_score * 0.25 +
    location_score * 0.20 +
    velocity_score * 0.15 +
    network_score * 0.10

If LLM-assisted evaluation is available, the system may treat it as a separate score:

final_score = programmatic_score * 0.40 + llm_reasoning_score * 0.60

However, the important point is this: the LLM score should not directly replace the decision. The final decision must always be supported by explainable signals, rules, and agent findings.

11.1 Risk-level mapping

Example thresholds:

In production, these thresholds should not be hardcoded. They should be configuration-driven and adjustable by country, product, customer segment, and regulatory context.

12. Example Investigation Flow

The following sequence diagram shows how the system works for a transaction:

13. Example Case: 9,948 USD Wire Transfer

Let’s examine the system through an example transaction.

13.1 Transaction details

AttributeValueTransaction ID67ED5F922066Amount$9,948.06TypeWire transferChannelOnlineSenderACCT-hI134936 / USReceiverACCT-Jk718227 / RUReceiver account age45 daysTransaction typeCross-borderInitial risk indicatorAmount close to the 10,000 USD threshold

13.2 Triage finding

The Triage Specialist produces the following flags:

{
  "flags": [
    "amount_below_reporting_threshold",
    "cross_border_wire",
    "receiver_high_risk_country",
    "new_receiver_account"
  ],
  "triage_score": 0.78,
  "escalation_required": true
}

Because the transaction is just below the 10,000 USD threshold, it creates structuring suspicion. The receiver’s high-risk country connection and new account status strengthen this suspicion.

13.3 Forensic finding

The Forensic Investigator evaluates the behavioral pattern.

Possible interpretation:

The transaction shows cross-border wire transfer behavior positioned just below the reporting threshold. The receiver account is new, and the transfer was made through the online channel, increasing the risk of structuring and early-stage layering.

Generated typology:

{
  "suspected_typology": "money_laundering_structuring_layering",
  "confidence": 0.72
}

13.4 Network finding

The Network Analyst examines the receiver account within the graph.

Example findings:

• The receiver account has high connectivity relative to its short account age.
• Second-degree connections include offshore jurisdictions such as Panama and Cyprus.
• The fund movement indicates more than a single isolated transfer.
• The receiver account may be behaving as a temporary hub.

Example output:

{
  "network_score": 0.83,
  "findings": [
    "Receiver account has high in-degree relative to account age.",
    "Second-degree counterparties include offshore jurisdictions.",
    "Transaction pattern suggests potential layering."
  ]
}

13.5 Compliance finding

The Compliance Officer converts technical findings into actions.

Recommendations:

• Prepare SAR.
• Initiate Enhanced Due Diligence.
• Perform a 90-day lookback on the receiver account and related accounts.
• Evaluate temporary account hold with human approval.
• Check cross-border reporting requirements.

13.6 Reflexion result

If the first round of Network analysis only considered direct connections, Reflexion may assign a low quality score.

Example:

{
  "quality_score": 0.67,
  "needs_revision": true,
  "reflection_notes": [
    "Network analysis should include second-degree counterparties.",
    "Compliance rationale should explicitly connect SAR recommendation to structuring indicators.",
    "Final report requires clearer evidence hierarchy."
  ]
}

In the second round, the network analysis is expanded. The quality score rises above the threshold.

{
  "quality_score": 0.86,
  "needs_revision": false
}

13.7 Final Result

14. Agent Anatomy: How Each Agent Works

Each agent in AEGIS has three parts:

1. Programmatic heuristics.
2. LLM reasoning.
3. Blended output.

This can be summarized as:

Programmatic Heuristics + LLM Reasoning -> Blended Output

14.1 Programmatic heuristics

Each agent first calculates deterministic signals.

For example, the Triage agent:

def calculate_structuring_score(amount: float) -> float:
    if 9000 <= amount < 10000:
        return 1.0
    if 8000 <= amount < 9000:
        return 0.6
    return 0.0

The Network agent:

def calculate_network_risk(account_age_days: int, degree: int) -> float:
    if account_age_days < 60 and degree > 10:
        return 0.9
    if account_age_days < 90 and degree > 5:
        return 0.6
    return 0.2

The Compliance agent:

def requires_sar(risk_score: float, flags: list[str]) -> bool:
    sar_flags = {
        "structuring",
        "high_risk_jurisdiction",
        "suspicious_network",
        "account_takeover"
    }
    return risk_score >= 0.7 and bool(sar_flags.intersection(flags))

14.2 LLM reasoning

The LLM supports deterministic scores with contextual reasoning.

Example prompt:

Given the transaction features, agent findings and risk flags, explain whether this transaction is consistent with known money laundering typologies. Do not invent evidence. Use only the provided structured findings.

One important prompt-design rule is:

The LLM should only interpret the provided structured findings. It should not invent new evidence.

14.3 Blended output

The final output contains both deterministic and LLM-assisted components.

{
  "programmatic_score": 0.74,
  "llm_score": 0.69,
  "final_score": 0.71,
  "explanation": "The transaction is consistent with structuring and early-stage layering indicators.",
  "evidence": [
    "Amount below reporting threshold",
    "High-risk destination",
    "New receiver account",
    "Suspicious graph expansion"
  ]
}

15. Observability and Outputs

In AEGIS, observability is designed as a separate layer. The dashboard does not only show the result; it also makes the process visible.

15.1 Streamlit dashboard panels

The dashboard may include the following panels:

15.2 Event Bus

Agents and the orchestration layer publish events through the event bus.

Example event:

{
  "event_type": "ALERT_ESCALATED",
  "transaction_id": "67ED5F922066",
  "risk_score": 0.78,
  "source_agent": "Triage Specialist",
  "timestamp": "2026-01-01T10:15:30Z"
}

Another example:

{
  "event_type": "AGENT_REFLECTION",
  "transaction_id": "67ED5F922066",
  "quality_score": 0.67,
  "needs_revision": true,
  "target_agent": "Network Analyst"
}

15.3 Final system outputs

AEGIS can produce the following outputs:

16. Production Requirements

At prototype level, AEGIS can run with Streamlit, synthetic data, and in-memory state. In production, stronger components are required.

16.1 Human-in-the-loop

In financial crime systems, full automation is not always the right target. Human approval is required especially in cases involving:

• Account hold.
• SAR filing.
• Customer restriction.
• High-risk customer segment.
• Sensitive regulatory jurisdiction.
• High-risk recommendation with low confidence.
• Contradictory findings between agents.

For this reason, AEGIS should be positioned less as an automatic decision engine and more as a powerful investigation copilot and orchestration layer.

17. Security, Compliance, and Governance

In a system like AEGIS, governance is as important as technical architecture.

17.1 PII masking

Data sent to model calls should be masked.

Example:

Original:
John Smith sent $9,948.06 from ACCT-123 to ACCT-456.
Masked:
Customer_001 sent $9,948.06 from Sender_Account_001 to Receiver_Account_001.

17.2 Audit log

Every decision should be recorded:

• Which agent ran?
• Which input was used?
• Which score was generated?
• Which prompt version was used?
• Which model was called?
• Which action was recommended?
• Was human approval given?

17.3 Prompt and model governance

Prompts should be versioned. Model changes should be measured. Before a new model version is deployed, regression testing should be performed.

Useful metrics include:

• False positive rate.
• False negative rate.
• SAR recommendation precision.
• Escalation rate.
• Average investigation time.
• Reflection revision rate.
• Human override rate.
• Model disagreement rate.

17.4 Regulatory rules should not be hardcoded

Compliance rules should be configuration-driven.

Example:

reporting_thresholds:
  USD:
    ctr_threshold: 10000
    structuring_band_min: 9000
    structuring_band_max: 9999.99
high_risk_jurisdictions:
  - RU
  - IR
  - KP
sar_rules:
  require_sar_if:
    min_risk_score: 0.70
    required_flags:
      - structuring
      - high_risk_jurisdiction

This approach enables regulatory updates without code deployment.

18. Extensibility

The AEGIS architecture is suitable for adding new agents.

Potential future agents include:

Recommended standard for adding a new agent:

1. Define the agent’s responsibility in one sentence.
2. Define the input and output schema.
3. Implement deterministic fallback.
4. Constrain the LLM prompt with role, context, and output format.
5. Publish findings through the event bus.
6. Define quality criteria for the agent in the Reflexion layer.
7. Add unit and scenario tests.
8. Make the agent output visible on the dashboard.

19. Suggested Repository Structure

aegis/
├── app/
│   ├── dashboard.py
│   └── components/
│       ├── live_monitor.py
│       ├── investigation_board.py
│       ├── network_graph.py
│       ├── reports.py
│       └── system_health.py
│
├── agents/
│   ├── base.py
│   ├── triage.py
│   ├── forensic.py
│   ├── network.py
│   ├── compliance.py
│   ├── lead_investigator.py
│   └── report.py
│
├── orchestration/
│   ├── graph.py
│   ├── state.py
│   ├── routes.py
│   ├── checkpoints.py
│   └── fallback.py
│
├── reflexion/
│   ├── evaluator.py
│   ├── prompts.py
│   ├── quality_rules.py
│   └── revision_policy.py
│
├── data/
│   ├── synthetic_generator.py
│   ├── schemas.py
│   ├── account_profiles.py
│   ├── typologies.py
│   └── country_risk.py
│
├── scoring/
│   ├── risk_score.py
│   ├── network_score.py
│   ├── compliance_score.py
│   └── thresholds.py
│
├── events/
│   ├── bus.py
│   ├── schemas.py
│   └── handlers.py
│
├── config/
│   ├── settings.py
│   ├── thresholds.yaml
│   ├── jurisdictions.yaml
│   └── model_routing.yaml
│
├── tests/
│   ├── test_risk_scoring.py
│   ├── test_graph_routes.py
│   ├── test_reflexion_loop.py
│   ├── test_compliance_rules.py
│   └── test_synthetic_patterns.py
│
├── notebooks/
│   └── scenario_analysis.ipynb
│
├── docs/
│   ├── architecture.md
│   ├── agents.md
│   ├── governance.md
│   └── deployment.md
│
└── README.md

This structure separates the responsibilities of the system. Agent logic, orchestration, scoring, configuration, event handling, and dashboard components can be developed independently.

20. Acceptance Criteria

AEGIS should meet the following criteria before a production pilot:

• Low-risk transactions are closed without unnecessary agent loops.
• Medium- and high-risk transactions pass through triage, forensic, network, compliance, and Reflexion steps.
• If the Reflexion quality score is below the threshold, re-investigation is triggered.
• Re-investigation is targeted; the entire process is not repeated blindly.
• Deterministic fallback works when LLM access is unavailable.
• Every final report includes risk score, risk level, evidence, and recommended actions.
• The dashboard shows agent activities and decision history.
• State transitions and decisions are stored as audit logs.
• Regulatory rules are configuration-driven.
• Critical actions include human-in-the-loop approval.
• Test scenarios cover money laundering, account takeover, synthetic identity, and low-risk transactions.

21. Summary of Design Decisions

The architectural value of AEGIS is concentrated in several key decisions.

21.1 Controlled autonomy

The system acts autonomously, but the flow, thresholds, state transitions, and quality criteria are explicit. This prevents uncontrolled agent behavior.

21.2 Explainable decisions

The final decision is not merely a label such as “High Risk.” It is produced with agent findings, scores, typology, evidence, and recommended actions.

21.3 Resilience

If LLM access is unavailable, the system does not stop completely. It continues to operate in a limited but functional mode through deterministic heuristics and fallback mechanisms.

21.4 Extensibility

New agents, typologies, compliance rules, and data sources can be added to the architecture.

21.5 Observability

The event bus, dashboard, and audit logs make the system’s decision process visible.

22. Conclusion

AEGIS does not treat agentic AI as simply “making multiple agents talk to each other.” It designs financial crime investigation as an end-to-end investigation workflow.

In this architecture, LangGraph is used for state-machine orchestration and conditional routing. AutoGen manages expert-agent collaboration. Reflexion enables the system to critique its own output and trigger targeted re-investigation when quality falls below the threshold. The Data Engine produces realistic financial crime patterns. The Event Bus and dashboard make the entire process observable.

This approach highlights an important point for designing agentic AI systems in high-risk domains such as financial crime:

The future is not only about larger models. It is about better-orchestrated, better-governed, more explainable, and more resilient agentic systems.

AEGIS presents a reference design that combines LLM-assisted financial crime investigation with controlled autonomy, explainable decision-making, and production-oriented architecture principles.