Govern an Agent End-to-End

This guide walks you through the full control-plane loop on a single, generic example: a claims-triage agent that reads inbound claims and can issue refunds. By the end you will have registered the agent, written a policy that pauses any refund over a threshold, run an execution that trips that gate, approved it as a human, replayed the run, and exported a tamper-evident record for an auditor.

The principle throughout is governed autonomy: the agent recommends an action, but policy keeps authority over whether it runs. The agent stays fast on low-risk work and pauses for a human exactly where the stakes justify it. KLA Control Plane is a govern-in-place layer: you instrument your existing agent rather than re-platforming it, so this loop wraps code you already have.

Everything below uses the live API host https://api.kla.digital with two headers: a bearer token and your tenant ID. Export them once:

export KLA_TOKEN="<paste access_token>"
export KLA_TENANT="acme-claims"

sequenceDiagram
  participant Dev as Developer
  participant Agent as Claims agent
  participant KLA as KLA Control Plane
  participant Desk as Decision Desk
  participant Room as Evidence Room
  Dev->>KLA: 1. Register agent
  Agent->>KLA: 3. Run execution (refund $1,250)
  KLA->>KLA: 2. Evaluate policy
  KLA->>Desk: require_approval -> Escalation
  Desk->>KLA: 4. Reviewer approves
  KLA->>Agent: Resume execution
  Dev->>KLA: 5. Replay in Lineage Explorer
  KLA->>Room: 6. Export Sealed Evidence Bundle

Step 1: Register the agent

Registering an agent declares it to the Control Plane and gives it a stable identity that every later step references. The manifest names the agent, lists the tools it is allowed to call, and assigns an owner. The process_refund tool is the one we will govern.

curl -X POST https://api.kla.digital/v1/agents \
  -H "Authorization: Bearer $KLA_TOKEN" \
  -H "x-tenant-id: $KLA_TENANT" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "claims-triage",
    "description": "Triages inbound claims and issues refunds",
    "owner": "claims-ops",
    "tools": ["lookup_claim", "process_refund"]
  }'

The response returns an agentId (for example agt_9f81a7). The agent now appears in the Agent Registry, the inventory of every governed agent, its owner, and its current release state.

Step 2: Author a policy that requires approval

Policy is declarative, evaluated by the KLA Policy Engine at the application layer. We write two rules for execute_refund: small refunds proceed, and refunds over the threshold pause for a human. KLA resolves policy to four outcomes in precedence order: allow, warn, require_approval, block. Here the high-value rule resolves to require_approval (a pause for a reviewer) rather than block (a hard stop).

# claims-triage policy (illustrative): refunds over $100 pause for review
- rule: low-value-refund
  when:
    tool: execute_refund
    amount: "<= 100.00"
  then:
    decision: allow
    reasonCode: REFUND_WITHIN_THRESHOLD

- rule: high-value-refund
  when:
    tool: execute_refund
    amount: "> 100.00"
  then:
    decision: require_approval
    reasonCode: REFUND_OVER_THRESHOLD
    route: Decision Desk

Author this in the Policy Builder, run a Simulation to confirm a $1,250 test request resolves to require_approval, then publish. On publish it compiles into a signed policy pack so live evaluation is fast and tamper-proof.

💡 Tip

Always simulate before publishing. A Simulation replays representative requests against the draft so you confirm each one resolves to the outcome you expect, with no effect on running agents.

Step 3: Run a governed execution that trips the gate

Now run the agent against a claim that needs a large refund. Your instrumented agent submits a Decision Request (the action plus its business context) before it calls process_refund. Because the amount exceeds the threshold, policy returns require_approval and opens an Escalation instead of letting the refund through.

curl -X POST https://api.kla.digital/v1/decisions.evaluate \
  -H "Authorization: Bearer $KLA_TOKEN" \
  -H "x-tenant-id: $KLA_TENANT" \
  -H "Content-Type: application/json" \
  -d '{
    "agent": "claims-triage",
    "action": "execute_refund",
    "attributes": { "amount": 1250.00, "claim_id": "clm_9921" }
  }'

{
  "outcome": "require_approval",
  "reasonCodes": ["REFUND_OVER_THRESHOLD"],
  "remediation": "Refunds above $100 require a reviewer. Routed to the Decision Desk.",
  "escalationId": "esc_01HZ8K"
}

The execution is paused, not failed. Treat require_approval as an asynchronous wait and surface the pending state to the end user.

Step 4: Approve on the Decision Desk

The Escalation now waits in the Decision Desk, where an authorized reviewer sees the action, its amount, the reason codes, and the remediation guidance. Approving resumes the original execution exactly where it paused; rejecting stops it. A reviewer can act in the UI or over the API.

curl -X POST https://api.kla.digital/v1/escalations/esc_01HZ8K/approve \
  -H "Authorization: Bearer $KLA_TOKEN" \
  -H "x-tenant-id: $KLA_TENANT" \
  -H "Content-Type: application/json" \
  -d '{ "note": "Verified claim documentation; refund authorized." }'

The refund now executes. The human held authority over the consequential action while the agent did everything else autonomously.

Step 5: Replay the run in Lineage Explorer

Every governed run becomes a Lineage Record: the ordered tree of steps from the triggering prompt through each tool call to the final output. Open it in the Lineage Explorer to replay exactly what happened: the policy outcome inline, the GenAI attributes (genai.tool.name, genai.tool.parameters, genai.cost.usd, genai.token.usage), and the approval. Verifying a record walks its Merkle proof up to the anchored ledger root.

curl https://api.kla.digital/v1/lineage/lr_8f21/verify \
  -H "Authorization: Bearer $KLA_TOKEN" \
  -H "x-tenant-id: $KLA_TENANT"

A match confirms the record is byte-for-byte what was sealed at execution time. Verification is independent of the application that produced it, which is what makes the record evidence rather than a log.

Step 6: Export a Sealed Evidence Bundle

Finally, forward the record (or a filtered window) to the Evidence Room and package it as a Sealed Evidence Bundle: signed records, full lineage, the policy state that applied, and the verification logs.

curl -X POST https://api.kla.digital/v1/evidence/bundles \
  -H "Authorization: Bearer $KLA_TOKEN" \
  -H "x-tenant-id: $KLA_TENANT" \
  -H "Content-Type: application/json" \
  -d '{ "lineageRecords": ["lr_8f21"], "format": "pdf" }'

ℹ️ Note

A Sealed Evidence Bundle is portable proof. Hand it to an auditor or attach it to a **Control Pack** (a compliance export that maps your governed actions to specific framework controls) and they can verify integrity without any access to your systems.

You have now run the complete loop: register, govern, gate, approve, replay, prove. The same six steps apply to any consequential agent action, whether a document sent for review, a record updated, or an external API called, wherever you want the agent to move fast and policy to keep authority.