The Autonomy Dial
When an AI agent can release a wire, clear a sanctions alert, or route an order, someone has to decide which actions it takes alone and which wait for a human reviewer. I designed the workspace where an operations lead sets that line and sees both costs at once: an error the agent cannot take back, and a review queue the team cannot clear.
- Human-in-the-loop
- AI governance
- Capital markets
- Decision geometry
- Risk visualization
- D3.js
The 2 ways oversight fails
01 · Failure contextUnchecked agents can commit an error that cannot be recalled. Escalating every uncertain action can overwhelm the people expected to catch it. The operator needs to see both risks in the same decision.
In payments, screening, and execution workflows, the consequence depends on the action. A staged schema change has a recovery path. A settled payment may not. Treating those actions as the same confidence threshold hides the cost of being wrong.
Adding human approval is not a complete answer. The threshold also determines how much work reaches the desk. An approval policy that demands more reviews than the team can complete moves risk into the queue.
I designed autonomy as an operating boundary that can be inspected and changed. Loss and capacity stay visible together, so a reassuring minimum-loss label cannot conceal an overloaded review team.
- Role
- Product designer. I designed the autonomy boundary, linked loss and capacity views, policy rehearsal, and retained decision record.
- Workflow
- Agent supervision: choose an automation policy that balances irreversible error, delayed action, and available review capacity.
- Data coverage
- 5 scenarios: wire release, sanctions clearance, order routing, schema rollback, and review overload. Each sets a threshold, irreversibility, severity, and reviewer count. Capacity is 25 cases per reviewer-hour; loss is in thousands of dollars per 6-hour shift.
- Verification
- Model checks cover optimization, capacity arithmetic, and fixed policy payloads. The rehearsal tests the decision within those assumptions.
- Related products
- Stripe Radar routes selected payments into human review with context and assignments. This workspace explores how a review policy changes workload and modeled loss across automation scenarios.
3 questions before an agent acts alone
02 · ScopeSurface. What does this operating coordinate cost, and where does the minimum-loss boundary sit?
Sensitivity. Is the excess loss coming from unchecked errors or from additional review?
Capacity. Can this team handle the escalations, and what accumulates if it cannot?
Locate the policy · explain the loss · check the desk · capture the conditions.
A policy has to fit the review desk
Read the decision flow
- Choose the action context and irreversibility
- Policy changes modeled loss and review arrivals
- Staffing defines hourly capacity
- Compare the modeled minimum with capacity
- Rehearse and retain a feasible policy
3 views, 1 operating boundary
03 · The prototypeThe contour surface gives the operator the field, the sensitivity curve explains the selected setting, and the capacity forecast tests whether the desk can carry it. Threshold, irreversibility, and staffing are shared across all 3.
The starting wire-release scenario is deliberately away from the modeled minimum. Move the threshold, inspect the 2 loss components, then change the team size. The boundary moves because reviewer capacity is part of the policy’s operating conditions.
The autonomy calibration workspace
From 62% to a policy the desk can carry
04 · A worked traceThe minimum-loss boundary is computed from the same objective as the surface. Commission loss falls as the threshold rises; review friction and overload add omission loss. The sensitivity curve exposes the sum instead of asking the operator to trust a highlighted target.
For the starting wire-release scenario, the modeled threshold moves from 62% to 70%. Compound loss falls from $88.8k to $84.2k, while review arrivals rise from 43.3 to 49.5 cases per hour. 2 reviewers provide 50 cases per hour of assumed capacity. That minimum runs the desk at 99% of capacity, which a deterministic model calls clear and a real queue with uneven arrivals would not. 63% stays within 5% of the minimum loss ($88.0k) at 88% utilization, and that is the setting I would retain.
The policy in the loss field
The overload scenario exposes the limit of optimization alone. With 1 reviewer, its minimum-loss threshold is 49%, but it still produces 33.9 escalations per hour against 25 of capacity. The best point in the loss model is still an operational deficit.
The 2 frames below hold that policy fixed and change only staffing. The hourly bars and capacity line share the left axis. Accumulated backlog has its own labeled right axis, so a rate is never drawn as if it were a total.
1 reviewer: capacity deficit
2 reviewers: room to review
The 25-cases-per-hour capacity per reviewer is an explicit scenario assumption. Arrivals are held constant, so the forecast is a deterministic capacity projection.
Then the rehearsal, and the record that keeps it.
The rehearsal asks the operator to tune a threshold before showing the result. It checks 2 conditions: stay within 5% of the modeled minimum loss and keep review arrivals at or below team capacity. Both must pass.
The checks use the workspace’s own model. A low-loss policy that exceeds capacity fails; a comfortable queue with excessive commission loss also fails. Changing the scenario or threshold invalidates the previous result.
2 checks, 1 calibration task
A policy record has to explain what the operator retained. Capture preserves the scenario, threshold, irreversibility, team size, model version, loss components, and assumptions together. Changing the controls later leaves that snapshot intact.
The record receives a SHA-256 digest of its JSON payload. Downloading it retains the parameters and integrity metadata for later inspection. The digest checks whether the payload changed; it does not establish institutional approval or regulatory compliance.
The captured policy record
- Conditions
- Scenario, threshold, action irreversibility, reviewer count, and capacity assumption.
- Reasoning
- Commission loss, review friction, overload loss, combined loss, and modeled minimum.
- Provenance
- Model version, capture timestamp, complete assumptions, and payload digest.
- Retention
- Snapshots remain in the browser session. A JSON download keeps the record beyond it.
Keep the reasoning with the decision
Read the decision flow
- Capture scenario, threshold and staffing
- Retain model version and complete assumptions
- Freeze the payload
- Export the payload and integrity digest
- The digest checks changed bytes, not external authorization
The model behind every number
05 · SourceThe charts, the rehearsal, and the captured record all read 1 model, stamped ADIAL-2.0 on every record. These are its equations, with t as the threshold and i as irreversibility, both as fractions.
- Commission loss
- 120 × e−2.6t × (0.6 + 2.4 i1.1) × scenario severity. Falls as the threshold rises; rises with irreversibility.
- Review friction
- 110 × (e2.8t − 1) / (e2.8 − 1) × (0.7 + 0.3(1 − i)). The cost of holding actions for review.
- Arrivals
- 10 + 65 × t1.4 escalations per hour.
- Capacity and overload
- 25 cases per reviewer-hour. Arrivals above capacity accumulate for 6 hours, and each waiting case costs $320.
- Minimum
- An exhaustive search over whole-number thresholds from 0 to 100 for each scenario and team size.
What the model establishes
Each scenario’s exposure labels the action; the loss model does not scale with it, so compare thresholds within a scenario, not losses across scenarios. The queue is a deterministic fluid backlog starting at zero, not an M/M/c waiting-time estimate. Capacity, arrival rates, service times, and mandatory review assumptions determine whether work clears. The prototype exposes the assumptions so a reviewer can test a feasible autonomy level.
Who sets the dial
06 · Audience- Head of payments or treasury operations
- Which actions an agent may release alone, and the staffing that policy needs.
- Model risk manager
- The loss trade-off behind a threshold, and the conditions under which it was approved.
- Review desk lead
- Whether the escalations a policy creates fit the shift.
- Financial crime compliance officer
- Which sanctions and payment actions always go to a person.
- Internal audit
- Whether a retained policy can be reconstructed from its record.
Where this transfers
07 · Same shape, other fieldsAny automated decision where a confidence threshold decides what a person must check, and the people are a fixed budget, has the same 2 costs to balance.
- Fraud and chargeback review
- Score thresholds that send transactions to analysts.
- Trade surveillance
- Alert thresholds against a fixed compliance team.
- KYC onboarding
- Automatic approval against manual document review.
- Insurance claims
- Straight-through payment against adjuster review.
3 decisions
08 · Trade-offs- A marked minimum, judged apart from capacity
- The optimizer marks the lowest-loss threshold, but capacity is shown as its own pass or fail. The overload scenario stays in the prototype because it is where the 2 disagree.
- A deterministic queue, not a stochastic one
- A fluid backlog is easy to read and to check by hand, and it understates waiting near full capacity. That is why the trace retains 63%, not the 99%-utilization minimum.
- A record with a digest, not an approval
- The SHA-256 digest shows whether the payload changed. Sign-off belongs to the institution’s own workflow, and the record does not stand in for it.
Where I expect to be wrong. Operators may trust the green minimum line more than the capacity status. If fewer than 6 of 8 study participants catch the overload deficit before capturing a policy, capacity becomes a gate on the capture button.
What I would measure
09 · The study this needsThe workspace makes an argument. It does not yet have evidence from operators. This is the study I would run before calling it better, with the pass line set before any session.
- Participants
- 5 to 8 people who set or review automation thresholds: payments and treasury operations leads, model risk managers, and fraud or sanctions review leads.
- Task
- Set and retain a policy for 3 scenarios, including review overload, once in this workspace and once with a loss table and a separate staffing sheet, order counterbalanced. A second participant then reconstructs each policy from its record.
- Measures
- The loss component named as driving a threshold change, whether a capacity deficit is caught before capture, the utilization of each retained policy, and whether the second participant reconstructs the conditions without asking.
- Pass line
- The overload deficit caught before capture by at least 6 of 8 participants, more than with the table and sheet; the driving component named correctly in at least 2 of 3 scenarios; every record reconstructed without asking the author.
How it is built
10 · Stack and craft- Working instrument: D3.js contours and SVG charts, native controls, and a shared decision model without a framework runtime.
- Loss boundaries are calculated from the same objective as chart values, rehearsal results, and captured policy metrics.
- Local assets support direct-file and HTTP previews. Keyboard controls, visible focus, reduced motion, and mobile layouts are supported.
- Role: product design and prototype engineering, including the loss geometry, capacity interaction, scenario comparison, and policy artifact.
- Diagram sources: editable Excalidraw files with SVG and PNG exports.