Decision Desk
The human-in-the-loop control point where reviewers approve, deny, or re-route the agent actions a policy paused for judgment.
The Decision Desk (/approvals-inbox) is where people make the calls that machines should not make alone. When the KLA policy engine returns a require_approval decision, the agent's action does not proceed. Execution pauses and KLA opens an Escalation, a manual-intervention object carrying everything a reviewer needs to act. The work item the reviewer ultimately resolves is a Decision Request. The Decision Desk is the queue, the review surface, and the audit record for every one of these moments.
This matters because require_approval is one of KLA's four policy outcomes, in precedence order: allow, warn, require_approval, block. The first two let work continue; block stops it outright. Only require_approval hands the decision to a human, and the Decision Desk is where that human stands.
How an Escalation reaches the desk
flowchart LR
A["Agent action"] --> B{"Policy decision"}
B -->|allow / warn| C["Continue"]
B -->|block| D["Stop"]
B -->|require_approval| E["Open Escalation"]
E --> F["Decision Desk queue"]
F --> G{"Reviewer acts"}
G -->|approve| H["Resume execution"]
G -->|deny| I["Terminate run"]
G -->|re-route| J["Senior reviewer"]
J --> GThe agent's run is held, not failed, while the Escalation waits. The instrumented agent (via the Govern in Place SDK) or the managed proxy (Run through KLA) blocks on the pending decision, so no side effect occurs until a person resolves it.
Working the queue
The inbox is built for triage at volume. Reviewers filter and sort across four dimensions:
| Dimension | What it does |
|---|---|
| Priority | Surfaces critical Escalations ahead of routine warn-adjacent reviews. |
| Team | Routes items to the right queue (claims triage, refund approval, document review) so finance never sees legal's work. |
| Agent | Isolates every pending action from a single agent, useful when one agent is behaving unexpectedly. |
| State | Separates open Decision Requests from resolved history for audit and trend review. |
Routing rules are declared in policy, so an Escalation lands in front of the team that owns that risk by default rather than in a shared pile.
Reviewing a Decision Request
Opening an item gives reviewers the full context behind the paused action, with no switching tools and no guessing:
- Prompt and instructions: the input that drove the action, including
genai.system.instructions, so the reviewer sees what the agent was told to do. - Tool payload: the exact
genai.tool.nameandgenai.tool.parametersthe agent intended to invoke (the refund amount, the record to write, the document to send). - Triggering rule: the specific policy that returned
require_approval, with its reason codes, so the decision is grounded in a named control, not a hunch. - Lineage link: a jump straight into Lineage Explorer to replay the full Lineage Record leading up to this step.
From here the reviewer takes one of three actions:
- Approve: releases the hold; the agent resumes exactly where it paused.
- Deny: terminates the run; the action never executes.
- Re-route / escalate: hands the Decision Request to a more senior reviewer or another team without losing context.
SLA and the audit angle
Every Decision Request carries timing. Reviewers see how long an item has waited, and overdue Escalations surface against their service-level target so nothing rots in the queue. That timing is part of the record, not just an operational nicety.
The result is a defensible answer to the auditor's hardest question, who approved this, on what basis, and when, without anyone reconstructing it after the fact. Human judgment becomes a first-class, tamper-evident part of the governance record.
