# Agent Exception Queue Template

Use this when an AI agent hits ambiguity, low confidence, conflicting sources, a tool failure, or a high-risk action. The goal is not to make the agent perfect. The goal is to make safe failure inspectable.

## 1. Queue purpose

- **Workflow:** `[workflow name]`
- **Agent / skill:** `[agent name and version]`
- **Human owner:** `[review team or person]`
- **What enters the queue:** `[low confidence, high-stakes action, source conflict, missing fields, tool failure, out-of-policy request]`
- **What must never enter the queue:** `[secrets, credentials, private data not needed for review]`

## 2. Exception record

```json
{
  "exception_id": "exc_YYYYMMDD_001",
  "created_at": "2026-07-10T20:30:00Z",
  "workflow": "crm_enrichment",
  "agent_id": "agent_name@version",
  "run_id": "run_123",
  "exception_type": "source_conflict",
  "priority": "normal",
  "status": "pending_review",
  "confidence": { "score": 62, "threshold": 80, "reason": "company domain conflicts across two sources" },
  "input_summary": "What the agent was asked to do, with secrets removed.",
  "sources_checked": [
    { "source": "CRM", "timestamp": "2026-07-10T20:20:00Z", "fact": "example.com" },
    { "source": "Company website", "timestamp": "2026-07-10T20:22:00Z", "fact": "example.ai" }
  ],
  "proposed_action": "Do not update CRM domain until source owner confirms.",
  "risk_if_wrong": "Bad CRM enrichment could route future outreach to the wrong domain.",
  "rollback_plan": "No external change has been made. If approved later, update field with note receipt.",
  "routing": { "reviewer": "data_owner", "sla_hours": 24, "escalate_after_hours": 48 },
  "resolution": { "decision": null, "rationale": null, "resolved_by": null, "resolved_at": null }
}
```

## 3. Exception types and routing

| Type | Trigger | Priority | Reviewer | SLA |
|---|---|---:|---|---:|
| Low confidence | `confidence < threshold` | Normal | Workflow owner | 4h |
| Ambiguous input | Missing required fields or multiple intents | Low | Request clarification | 24h |
| Conflicting sources | Two canonical sources disagree | High | Data/source owner | 4h |
| High-stakes action | External, irreversible, financial, legal, security, or customer-facing action | Critical | Explicit human approval | 1h |
| Out-of-policy request | Violates scope, permission, memory, or tool policy | High | Reject + notify owner | 4h |
| Tool failure | API/browser/file/SaaS/auth/rate-limit failure after retries | Normal | Ops owner | 24h |

## 4. Human review actions

Every reviewed exception should end in one of these states:

- **Approved:** agent may continue exactly as proposed.
- **Rejected:** agent must not continue; tell the user or owner why.
- **Modified:** agent may continue with reviewer-specified changes.
- **Needs more info:** agent asks for a missing field or waits for a source owner.
- **Policy update:** update contract, source map, memory policy, or evals before future runs.

Resolution note required:

```text
Decision:
Rationale:
Approved/modified action:
Should this change future behavior? yes/no
Memory or policy update needed? yes/no
Reviewer:
Resolved at:
```

## 5. Operating metrics

Track weekly:

- exceptions per 100 runs
- median time to resolution
- percent approved / rejected / modified
- top recurring exception type
- stale exceptions older than SLA
- policy updates created from exceptions

A healthy pilot usually has some exceptions. Zero exceptions can mean the thresholds are too loose. Too many exceptions means the workflow boundary is too broad or the inputs are too weak.

## 6. Pilot launch rule

Before expanding agent authority, review 10–20 resolved exceptions and answer:

- Did the queue catch the right failures?
- Did reviewers have enough context?
- Did any exception require rollback?
- Which policy or memory updates came from resolutions?
- Which exception type should be automated next?