KYB Agentic Review Engine

The KYB agent that reviews KYB cases runs on a multi-role agentic review engine. Rather than a single AI loop that both reasons and acts, the engine separates the work into distinct phases: three analytic roles assess the case, a deterministic (non-AI) guard decides whether the case may be approved, and a tool-constrained actuator carries out exactly one outcome. Every decision is recorded against a versioned policy and written to the audit trail.

This page describes how the engine works and how the KYB Agent Mode you pick on the flow step controls it.

info

You do not configure the review engine directly. It is driven by the KYB Agent Mode on the KYB step (Disabled, Suggest, or Auto-pilot). This page describes what happens behind that setting.

How a review runs

When a KYB case is ready for review, the engine builds a case file from the case and any open clarifications, then runs it through the pipeline below. Each phase has a single responsibility, and the analytic phase cannot mutate any record.

The three analytic roles

The analytic phase runs three roles in sequence: one raises concerns, one answers them, and a third weighs the two. None of them can change the stored record.

Role	Responsibility	Notes
Prosecutor	Produces structured risk findings across the case file.	LLM with structured (schema-constrained) output.
Defender	Produces mitigations that answer the findings.	LLM. Skipped when the Prosecutor returns zero findings.
Judge	Weighs findings against mitigations and issues a verdict with a rationale.	LLM. Its decision is one of Approve, Escalate, or Deny.

Each role uses a provider-agnostic, strict-mode structured-output schema and is driven by a versioned prompt (currently kyb-policy-2026.06.0).

The deterministic guard

The Judge's verdict does not decide approval on its own. It is checked by a deterministic guard, written in Rust and running no LLM, that has the final say on whether the case may be approved. Approval requires all of:

• PEP screening succeeded.
• Every document-backed field cross-check matched.
• No unresolved clarifications remain.

If any condition fails, the guard vetoes the approval. An Approve verdict that coincides with a Deny signal is forced to Escalate. An LLM verdict cannot override the guard.

The actuator

The actuator runs only after the guard, and it can take only one action. Its tool allowlist is the intersection of the Judge's decision and the Agent Mode gate:

• For an Escalate verdict, the approve_kyb_result tool is not in the allowlist and cannot be called.
• An Approve verdict under Suggest mode is recorded but not enacted.
• The mutating tools are idempotent, so a retry re-runs the same stateless evaluation instead of producing a second, independent action.

How Agent Mode controls the engine

The KYB Agent Mode on the flow step determines how far the actuator is allowed to go:

Mode	Engine behavior
Disabled	The pipeline does not run. Fields still receive a match type, but there is no AI reasoning, verdict, or suggested value, reviewers decide everything by hand.
Suggest	The full pipeline runs. Clarification requests and escalations are enacted; an Approve verdict is recorded as a suggestion only, for a reviewer to follow or not.
Auto-pilot	The actuator may also approve. An Approve verdict is enacted only when the deterministic guard passes and the case's decision rules allow it (readiness, exceptions, and the approval matrix); anything else is escalated to a reviewer.

Guarantees

The engine enforces the following, independent of the LLM's output:

• The guard is final. Approval requires PEP success, every document-backed field cross-check matched, and no unresolved clarifications. An LLM verdict cannot override it.
• The allowlist is decision ∩ mode. The actuator for an Escalate verdict cannot call approve_kyb_result, and Approve under Suggest does not run the actuator at all.
• The agent is never the second signature. Where the approval matrix requires two signatures, the agent's approval is only a proposal; a person confirms it.
• The guard runs again server-side. approve_kyb_result re-runs the strict guard when it is called; the engine-side guard passing is not sufficient on its own.
• Retries are safe. All mutating actions are idempotent. A retryable actuator failure re-runs the stateless evaluation, and the audit entry flags it (actuator_will_retry) so a retry reads as another attempt rather than an independent review.
• The engine can be switched off. A hot-reloadable flag, changed from the admin runtime-config endpoint without a redeploy, stops dispatch from claiming candidates and releases in-flight jobs, so cases stay with your reviewers.
• Clarifications round-trip. The guard distinguishes "awaiting the client" (a veto) from "submitted and cross-check matched." Once a clarification is submitted and matches, the actuator reviews the fields, closes the request, and may then approve.

Audit trail

Every run writes a KYB_AGENT_REVIEWED entry to the case's audit trace. The entry records both the model's verdict and the action the system took:

Field	Meaning
Findings count	How many risk findings the Prosecutor raised.
Judge verdict	Approve, Escalate, or Deny with the Judge's rationale.
Guard outcome	Whether the deterministic guard passed or vetoed, and why.
Enacted decision	The action the actuator took (or none, under Suggest).
Policy version	The versioned policy the decision was made under (e.g. kyb-policy-2026.06.0).
Actuator status	Success, or a retryable failure flagged with actuator_will_retry.

Related

• AML Agentic Review Engine, the parallel multi-role engine for sanctions, PEP, and adverse-media moderation