GAP-08 · Agent architecture
Human Review and Autonomy Control Simulator
Current decision
All supplied edge cases reach review at L1
- Review load
- 20/20
- Modeled throughput
- 100/hour
- Modeled exposure
- $0k
Same instrument · 3 industries choosing a scenario replaces its inputs; save or share your current changes first
Prefer to read? The two minute case study · problem → approach → metric → outcome
Problem
Too much review can make automation uneconomic, and too little review can allow high risk edge cases to slip through. The right autonomy level depends on risk tier, impact, reversibility, and the organization's control posture.
Approach
The simulator processes a modeled queue across autonomy levels. It shows how throughput, human load, and edge case exposure change as review requirements loosen.
Why this way
This connects autonomy to operating capacity, risk exposure, customer impact, compliance, and workforce design.
The metric
Edge case coverage versus throughput; the recommended (highest zero slip) level.
The trade-off
More autonomy means more throughput and, eventually, an unreviewed high severity error.
Outcome
The autonomy level to run per risk tier, the most speed that still catches every edge.
Policy changes from pinned L1
0 items changed review path. Review load 0; modeled throughput 0/hour; exposure 0 thousand dollars.
Only changed items carry the blue outline below. Select any queue item to inspect its actual rule outcome.
Items processed
Items sent to a human
Unreviewed errors
Cost of the slips
The queue · ● edge case
Item 1 · low risk · Ordinary supplied item
Current path: Human review. No unreviewed error is modeled for this item at the selected level.
Baseline L1: Human review.
L1 clears every edge case
Autonomy by risk tier · bridges EL-05 / Govern
These are illustrative review-policy tiers, not regulatory limits. Set a production policy using its actual impact, controls and applicable obligations.
Read all queue and policy values
| Item | Risk | Edge case | Baseline L1 | Current L1 | Modeled slipped exposure |
|---|---|---|---|---|---|
| 1 | low | No | Review | Review | $0 |
| 2 | med | No | Review | Review | $0 |
| 3 | high | No | Review | Review | $0 |
| 4 | low | No | Review | Review | $0 |
| 5 | med | No | Review | Review | $0 |
| 6 | low | No | Review | Review | $0 |
| 7 | high | Yes | Review | Review | $0 |
| 8 | med | Yes | Review | Review | $0 |
| 9 | low | No | Review | Review | $0 |
| 10 | med | No | Review | Review | $0 |
| 11 | high | No | Review | Review | $0 |
| 12 | low | No | Review | Review | $0 |
| 13 | med | No | Review | Review | $0 |
| 14 | low | No | Review | Review | $0 |
| 15 | high | Yes | Review | Review | $0 |
| 16 | med | Yes | Review | Review | $0 |
| 17 | low | No | Review | Review | $0 |
| 18 | med | No | Review | Review | $0 |
| 19 | high | No | Review | Review | $0 |
| 20 | med | No | Review | Review | $0 |
| Level | Reviewed | Throughput/hour | Slipped edges | Exposure |
|---|---|---|---|---|
| L1: Review all | 20 | 100 | 0 | $0k |
| L2: Review high + med | 13 | 160 | 0 | $0k |
| L3: Review high only | 5 | 220 | 2 | $40k |
| L4: Sample ~20% | 4 | 280 | 3 | $120k |
| L5: Full autonomy | 0 | 340 | 4 | $140k |
If you act on this · the call → expected lift → how you'd measure it
The call
Set autonomy by risk tier and impact, not by automation enthusiasm.
Expected lift · illustrative
Increases throughput while keeping edge case exposure within an acceptable control boundary.
How you'd measure it
Review load, throughput, edge case slip through rate, escalation rate, control exceptions.
Steering committee takeaway: The question is not how much autonomy is possible. The question is how much autonomy is appropriate for the risk tier.
How this is built
Twenty items carry a risk tier and four are edge cases (errors if auto approved). Each level defines a review policy; an edge case slips when it isn't reviewed. Throughput rises with autonomy; exposure = Σ severity of slipped edges. The medium risk edge is engineered to slip exactly one level past the balance point.
Stack: Next.js (static) + shared design system; deterministic client side.
Limitations: this is a simplified queue simulation. Production workflows would require live performance data, risk policy, audit logging, escalation paths, and ongoing exception review.