Skip to content

PATTERN Cited by 1 source

Supervisor + sub-agent KYC orchestration

Pattern

A regulated-compliance-grade variant of multi-agent orchestration in which:

  1. A Supervisor Agent owns the case but does no compliance work itself; instead it analyses case characteristics (document types, geography, risk indicators, history) and dynamically constructs a parallel-or-sequential execution plan across domain-specialised sub-agents.
  2. N domain sub-agents each carry a narrow, regulated toolset (watchlist / OCR / fraud-similarity / regulatory-corpus / customer-journey) and emit a confidence-scored result.
  3. The Supervisor composes sub-agent confidences into a case-level decision via confidence-tiered routing (auto-approve / additional- verification / human-review with full context).

Canonical instance: IBM + AWS KYC architecture (2026-04-23) — 1 supervisor + 5 sub-agents (Identity Verification, Document Analysis, Fraud Detection, Compliance & Risk, Customer Experience). (Source: sources/2026-04-23-aws-modernizing-kyc-with-aws-serverless-solutions-and-agentic-ai.)

Diagram

                    ┌───────────────────────────────┐
                    │  KYC Orchestration Supervisor │
                    │   (dynamic planner; not a     │
                    │    worker itself)             │
                    └──────────┬────────────────────┘
                               │
    ┌──────────────┬───────────┼──────────────┬──────────────┐
    ▼              ▼           ▼              ▼              ▼
┌────────┐  ┌────────────┐ ┌────────┐  ┌─────────────┐  ┌──────────┐
│Identity│  │  Document  │ │ Fraud  │  │ Compliance  │  │ Customer │
│ Verify │  │  Analysis  │ │ Detect │  │  & Risk     │  │   Exp    │
└────────┘  └────────────┘ └────────┘  └─────────────┘  └──────────┘
     │            │             │             │               │
     └──── all invoke tools via AgentCore Gateway (OpenAPI) ───┘
     └──── all read/write shared session via AgentCore Memory ─┘
     └──── all query RAG corpus via Bedrock Knowledge Bases ───┘

Why this is a distinct pattern, not just

patterns/specialized-agent-decomposition

Plain specialized-agent-decomposition describes the why of breaking agents along domain lines. The supervisor-subagent-KYC orchestration pattern adds three compliance-specific requirements:

  1. Dynamic planning, not fixed workflow. Legacy KYC is rule-based; the Supervisor picks the execution plan per case based on its signal. This is key because EU-jurisdiction passports need a different sub-agent ordering than US-jurisdiction driver's licenses.
  2. Confidence composition, not just aggregation. The Supervisor is responsible for turning five sub-agent confidences into one case-level confidence band, and the composition rule is regulatorily load-bearing.
  3. Regulated tool access via OpenAPI + Identity. Each sub-agent has a narrowly-scoped tool surface enforced at runtime by systems/agentcore-identity + systems/agentcore-gateway — the Document Analysis sub-agent cannot trigger a core-banking account activation even if prompt-injected.

Mechanism

  1. Inbound KYC request arrives on an MSK inbound topic.
  2. Event listener preprocesses — filters onboarding requests, prepares docs for OCR, normalises vendor data formats, correlates transaction signals with customer profiles.
  3. Lambda consumer pulls the event and invokes AgentCore asynchronously (so it doesn't block the consumer).
  4. Supervisor receives the case, inspects metadata, constructs the execution plan (e.g. "run Doc Analysis and Identity Verification in parallel; if either flags, dispatch Fraud Detection; always run Compliance at the end").
  5. Sub-agents execute, each grounded in its own tool surface and in systems/amazon-bedrock-knowledge-bases-mediated context-aware retrieval over the regulatory corpus. They write intermediate state into systems/agentcore-memory.
  6. Supervisor composes confidence:
  7. > 95 % → Supervisor publishes auto-approval to outbound topic; downstream Core Banking consumes.
  8. 75–95 % → Supervisor invokes additional verification sub-agents until confidence clears or drops below 75 %.
  9. < 75 % → Supervisor publishes human-review event with comprehensive context; Case Management consumes.

When to reach for it

  • Regulated multi-step decisioning — KYC, KYB, AML-monitoring, credit underwriting, insurance claims adjudication, benefits eligibility.
  • Each step has a different tool surface and different vendor / on-prem integration points.
  • Latency budget is significant (seconds-to-minutes, not milliseconds) — async orchestration is fine.
  • Explainability is mandatory — regulators need a reasoned decision trace per case.

Do not reach for it when: - The decision is a single-shot classification (use one model). - The sub-tasks share all their tools (just prompt one agent with everything). - The latency budget is tight (supervisor + 5 sub-agent fanout is at best hundreds of milliseconds of overhead).

Anti-patterns

  • Supervisor as silent router. If the Supervisor's only job is to always dispatch all N sub-agents, it's a waste of a layer; drop it. The Supervisor must do case-dependent planning.
  • Fixed confidence bands without calibration. Shipping the

    95 / 75-95 / <75 bands of the KYC post without actually calibrating them against labelled cases is a regulatory liability. Thresholds are product policy.

  • Shared memory without identity gating. Putting all five sub-agents on a shared AgentCore Memory scope without access-controlling which agent can read which keys is a prompt-injection attack surface.

Relation to on-wiki neighbours

Seen in

Last updated · 476 distilled / 1,218 read