Approvals Workflow

When the policy engine evaluates an intent and determines that human oversight is required, execution is paused and an approval request is created. This doc explains what happens next — from the approver's perspective.

Why Approvals Exist

The policy engine's Risk axis and Semantic axis can produce a deferred verdict rather than an immediate allow or deny. Deferral is how the platform handles situations where the policy says "this needs a human look" — high-stakes actions, first-time capability use, actions above a value threshold, or any capability your organization has pinned to always require review.

Deferral is not a failure. The agent receives an immediate receipt and continues its reasoning loop. The action is held — safely and durably — until a qualified human decides.

Approval Groups and Routing

Every domain in your organization's registry is assigned an approval group — a named team of members who receive approval requests for that domain.

When an intent in the finance domain is deferred, the approval request is routed to whoever your organization has assigned as the finance domain's approval group. The domain owner and group assignment are configured under Domains in the dashboard.

An individual agent can also have a dedicated approval group override, routing its deferrals to a specific team regardless of domain.

Receiving a Deferral Notification

When an intent is deferred, members of the relevant approval group receive a notification in the Approvals section of the dashboard. If you are connected to the dashboard and the agent used the MCP interface, you may also receive a real-time push notification as the deferral arrives.

The notification shows:

Which agent submitted the intent
Which capability was requested (domain.action.entity)
The policy axis that triggered deferral (Risk, Semantic, or a manual HITL pin)
The expiration time — approval requests have a deadline; after it the IEC automatically reaches an EXPIRED terminal state

Reviewing an Approval Request

Open an approval request from Governance → Approvals. Each request shows:

The proposed action

The full capability the agent wanted to invoke, with all parameters exactly as submitted. You see the structured fields — recipient, amount, template, destination — not raw API payloads.

The reasoning trace

The agent's own account of why it wanted this action: the goal it was pursuing, the decisions it made, and alternatives it considered. This is preserved verbatim from the agent's submission. The platform does not modify or interpret it.

The reasoning trace answers: "What was the agent trying to accomplish and why did it choose this action?"

The policy snapshot

The exact set of rules that evaluated this intent and produced the deferral verdict, captured at the moment of evaluation. If rules change after a deferral is created, the approval request still shows the rules that produced it.

The policy snapshot answers: "What governance condition flagged this for review?"

The risk assessment

The composite risk score — reversibility, external visibility, and execution precedent for this agent on this capability — that contributed to the verdict.

Making a Decision

Approve

Approving resumes execution from exactly where it paused. The connector executes the external action, the IEC moves to EXECUTING and then SUCCEEDED or FAILED, and the agent receives the result. The same iecId flows through the entire lifecycle — deferral and resumption are one IEC.

If you are using MCP, the agent receives a notifications/resources/updated push notification when the IEC resolves so it does not need to poll.

Deny

Denying closes the IEC permanently. The agent receives a denied outcome with per-axis reasoning. The denial is recorded in the audit trail as a human decision.

You may add a note when denying — this note is stored in the approval record and is visible in the audit trail.

Expiration

If no decision is made before the approval request's deadline, the IEC moves to EXPIRED. The agent receives an expired outcome. Expiration is a terminal state; the agent would need to resubmit the intent if it still wants the action performed.

Expiration deadlines are configured per domain under domain settings. Defaults vary by subscription tier.

The Audit Record

Every approval decision — approve, deny, or expiration — is written to the immutable audit ledger. The record includes:

The decision and who made it
The timestamp
Any note provided at denial
The policy snapshot at the time of deferral
The agent's reasoning trace

This produces a complete, tamper-proof answer to: "Who reviewed this intent, what did they see when they reviewed it, and what did they decide?"

Query approval history via the Management API:

# All approval requests for the org (paginated)
GET /manage/v1/approvals
 
# The full joint trace for a specific IEC, including the approval decision
GET /manage/v1/iec/:iecId/trace

Two-Person Approval (Enterprise)

On the Enterprise plan, domains can be configured to require two independent approvers before an intent is approved. The first approver's decision is recorded but held; a second eligible member must confirm before execution resumes.

Two-person approval is configured per domain under Domains → Settings → Approval Policy.