KYB Agentic Review Engine

The KYB agent that moderates business-information results 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 result 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 result is ready for moderation, the engine builds a case file from the KybResult 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 a result 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 — operators moderate everything manually.
Suggest	The full pipeline runs and its verdict, rationale, and suggested values are surfaced to operators, but nothing is enacted. A human confirms or rejects.
Auto-pilot	The actuator may enact the decision automatically. An Approve verdict is enacted only when the deterministic guard also passes; anything the guard vetoes is escalated to the human review queue.

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 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 results fall back to the human review queue.
• 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 KYB audit trail. 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.