Approval intents and safe resume

BailingHub emits approval intents for agent-triggered tool calls. It does not replace an enterprise approval system. The hub pauses and freezes a call; the business system decides who may approve and still performs final authorization on resume.

Approval intent

{
  "kind": "tool_approval_request",
  "approval_id": 123,
  "job_id": "job_...",
  "route": "inventory_ops",
  "provider": "erp",
  "tool": "inventory.adjust",
  "scope": "inventory.write",
  "risk": "high",
  "on_behalf_of": "tenant_1:user_1001",
  "args": { "store_id": 8, "sku_id": 10086, "delta": -20 },
  "args_hash": "sha256:..."
}

Return the decision

POST /approvals/{approval_id}/decision

{
  "kind": "tool_approval_decision",
  "schema_version": "bailing.approval-decision.v1",
  "approval_id": 123,
  "job_id": "job_...",
  "request_id": "req_...",
  "args_hash": "sha256:...",
  "decision_id": "oa:approval:9001",
  "decision": "approved",
  "approver": "user_2002"
}

Only approved and denied are valid. decision_id is the business approval system’s idempotency key; args_hash must match the frozen call.

Conditions that must still hold on resume

The trusted subject is still valid;
route, provider, and exact operation are still allowed;
normalized arguments have not drifted;
approval is unexpired and unconsumed;
final tenant, permission, and state checks still pass in the business system.

A timeout does not prove that the tool failed. Reconcile unknown finality using the same business idempotency key before any retry.