Agentic Decision Rights: Removing the Human Bottleneck

Agentic decision rights are simply the rules provided to an agent to make decisions that a human would otherwise make, for example, is this correct? if so, proceed to the next step. The key value they provide is the ability to minimise humans in agentic workflows, where humans are often the bottleneck and an unscalable component of the system. In loop engineering they are the layer that decides what an agent settles autonomously versus what it hands back to a person to make a decision.

The bottleneck is a human decision

Humans are often referred to as the bottleneck in agentic workflows. This bottleneck boils down to human decisions, so the question is, can we codify these to be as good as or better than humans?

An agentic workflow looks something like this:

The decision sits with a person© hcd.ai

Scroll to see the full diagram

In loop engineering that check is completed by an agent:

The decision sits with the agent© hcd.ai

Scroll to see the full diagram

This is a simplified and idealistic view, and assumes the agent check is evaluating the required standard correctly, and the agents doing the work can meet that standard.

Where loops break down

Here's where governance, verification and checks break down in a loop:

Stage	Where it breaks	Ask of your loop	Evidence
Before the loop	Nobody defined done	Is done written down precisely, before the loop runs?	Ambig-DS
	Not every answer has a reference	Is this checked against a reference, or only scored?	Su et al.
Designing the check	Nobody owns the threshold	Who owns the number, and when was it last reviewed?
	The checker is not independent	Does the check run in the same context as the work?	Chen et al., Song
Running the loop	One pass is not proof	Has this run more than once on the same input?	Anthropic
	Budgets are not decisions	What is the ceiling, and what happens when it is hit?	BAGEN
Governing the grant	Checkers disagree	What breaks a tie between two checkers?	Zhao et al.
	Grants leak	Can another agent pick up this grant, and would you know?	UK AISI

Understanding where loops break down is the first step in formulating agentic decision rights. Before jumping into solutions though, it's worth looking at the decision landscape.

The decisions landscape

A decision can be looked at from five angles, and each one asks something different about what you can hand to an agent.

Levels of demand

Rasmussen (1983) split human performance into three levels. Skill needs no thought. A Rule matches something familiar. Knowledge means reasoning it out when nothing familiar fits.

What it demands	The decision is	What may settle it
Skill-based	Determined by input. Nobody deliberates	A Reference decides, a person as fallback
Rule-based	A familiar case, with no written reference yet	Estimate and Challenge, a person as the fallback
Knowledge-based	Novel. No rule fits, it's reasoned out	Authority, with Challenge only alongside it

Conditions of the grant

Three questions decide whether an agent settles something alone. Two of them close rather than weigh, the way Mission Command bounds delegated authority and stops there.

What to ask	The decision is	What it decides
What does settling it demand?	Skill-based, rule-based or knowledge-based	Which settlement methods are available
Can it be undone?	Reversible now, or a one-way door	A one-way door always goes to a person
Does it recur?	Common enough to validate a rule, or rare	Rare cases always go to a person

States of knowledge

What you know sets what a score is worth. Knight split risk from uncertainty in 1921 by whether the odds are known. Ellsberg showed in 1961 that people treat unknown odds differently from known ones, and the third row, where the outcomes themselves aren't known, is my own extension.

What you know	The decision is	What a score is worth
Risk	Both the outcomes and their odds are known	A threshold means something real
Uncertainty	The outcomes are known, their odds aren't	A threshold means a decimal-pointed guess
Ambiguity	The full set of outcomes isn't known	A score is theatre, however precise

Stages of automation

A decision isn't one thing to grant or withhold. Parasuraman, Sheridan and Wickens split it into four stages in 2000. Hand over the early ones, keep the last: that's the usual way a loop gets built.

Which stage	The agent handles	What it means for the grant
Acquiring information	Gathering what the decision needs	Safe to hand over, rarely worth keeping
Analysing it	Working out what that information means	Safe wherever it can be checked after
Selecting the action	Picking the action the analysis suggests	The usual, and hardest, line to draw
Carrying it out	Carrying out the action that was selected	Depends on whether it can be undone

Holders of information

Authority belongs with whoever holds the better information, the logic Mission Command runs on and the idea the phrase decision rights comes from: a decision right should sit with whoever holds the specific knowledge, as Jensen and Meckling (1995) put it. The doctrine is just as clear that whoever delegates keeps the responsibility, and that holds here too. Inside a loop the better-informed party is often the agent, since it holds the run history that a person only skimmed.

Who knows more	The decision is	Where it should sit
The agent	It holds the full output and run history	With the agent, on a grant a person owns
The person	They hold the intent and the stakes	With the person, however slow that is
Neither	The information doesn't exist yet	Escalate to gather it, not to decide it

Each table narrows down which way of settling a decision fits. Pick a method from the wrong row and the loop fails. A worked example comes next, then the five ways a decision gets settled.

A simple example

Take an invoice arriving for payment. Two agents run the loop from the opening section, one doing the work and a separate one checking it, the same split boards make when they separate managing a decision from controlling it, what Fama and Jensen (1983) call decision management and decision control.

One working agent and a separate checker

One working agent and a separate checker© hcd.ai

Scroll to see the full diagram

1. An invoice arrives
2. The working agent matches it to the PO and delivery receipt
3. A separate checking agent validates that match
4. A failure goes back to the same agent to correct
5. A pass sends it for payment

The same loop with a ceiling on the retry

The same loop with a ceiling on the retry© hcd.ai

Scroll to see the full diagram

• A fourth failure stops the loop and hands it to a person (6)
• The person's decision then goes on to payment

Precedent proposes what the retry could not

Precedent proposes what the retry could not© hcd.ai

Scroll to see the full diagram

• Failures over three now go to a third agent, resolve (6)
• Resolve proposes a match from cases already settled
• A proposed match goes back to check (3) to confirm
• Only an unmatched case reaches a person (7)

This is where the loop stops being static. Every mismatch a person resolves becomes another entry in the store, so the case that needed a person last quarter is the case the loop settles alone this quarter. The human does not disappear, they move further from the work each time it runs.

That's the cost, not just the payoff. Bainbridge (1983) called this the irony of automation: automate the routine cases and what's left for the person is only the hard ones, right when they've had the least practice, judged from a summary instead of from doing the work. In this loop the person only ever sees the mismatches the store couldn't explain, so the loop has to keep them in practice, a sample of settled cases to review now and then, or the reasoning shown with each escalation, otherwise the hardest case lands on whoever is least ready for it.

Five ways a decision gets settled

These are the five families, the key ways a decision gets settled, ordered from the one that settles most on its own down to the one that hands the call to a person. Reaching a goal is a state the loop ends in rather than a way of settling anything, and the five below are how you work out that you reached it.

1. Reference

What. A predetermined reference decides, and the agent has no say in the answer. Software testing calls this an oracle.

So what. It is the only settlement that does not rest on the agent's judgement, which makes it the strongest and the most tightly bounded by whatever it was told to check.

Examples:

• A test suite passes, or names the line that failed
• A schema validates the output, or rejects it
• Claims checked one by one against retrieved evidence
• A sandbox run that observes the end state, not the exit code
• A signature or checksum matching what the source published

2. Estimate

What. A score stands in for the truth, so the decision is only as good as that score's calibration.

So what. It scales where a fixed reference cannot reach, and it fails quietly, because a badly calibrated number looks exactly like a well calibrated one.

Examples:

• Semantic entropy, clustering sampled answers by meaning
• Conformal prediction, holding the truth at a set rate
• Agreement across independent runs with no shared blind spot
• A preference model scoring on what it was trained to favour
• A token probability, only meaningful on a constrained answer

3. Challenge

What. A reviewer that had no hand in producing the work looks at it.

So what. What it buys is independence rather than hostility, which is the answer to a model recognising and favouring its own output.

Examples:

• A fresh session reviewing what the first session produced
• A different vendor's model reviewing the first one's work
• Independent reviewers concurring, none of whom did the work
• A reviewer given the output but not the brief behind it
• A reviewer that runs the work rather than reads it

4. Exhaustion

What. The loop stops because carrying on stopped being worth the cost.

So what. It bounds every other family, and on its own it settles nothing about whether the work is right.

Examples:

• A retry cap reached, or a deadline passed
• Output that stopped changing between rounds
• Work dropped because finishing it was never important enough
• The next round costing more than the improvement it buys
• A queue that emptied, with nothing left to work on

5. Authority

What. A person takes the call and keeps it.

So what. Its claim is accountability rather than knowledge, which is why it sits last and is not the weakest.

Examples:

• An irreversible action nobody will be able to undo
• A contested claim someone will answer for in public
• A tie where the checkers turned out to share a blind spot
• A call that law or contract reserves to a named person
• A matter of taste that no rule has ever managed to capture

The agentic decision rights framework

I built this into a Claude Code skill. Point it at a decision and you get a written record, not an opinion someone will forget. Writing a decision down with who authorised it is not new, the DMN standard has done it for business rules since 2015. What it leaves out is the loop, the cap and the escalation. Two rules come before anything else, whatever the table below says: an action nobody can undo goes to a person, and so does a decision too rare to have any history.

A dot means that family can settle a decision of that kind on its own, while a ring means it can only contribute, with another family making the final call. A dash means there's nothing on offer there. Authority is a dot everywhere because a person can always take the call, and Exhaustion is a ring everywhere because a budget can end any loop without saying whether the work was right, which is why neither row tells you which family to build.

Settlement	What it demands			What you can know
	Skill	Rule	Knowledge	Risk	Uncertainty	Ambiguity
Reference	Available	Available, but not on its own	Available, but not on its own	Available	Available	Available, but not on its own
Estimate	Not available	Available	Not available	Available	Available, but not on its own	Not available
Challenge	Available, but not on its own	Available	Available, but not on its own	Available	Available	Available, but not on its own
Exhaustion	Available, but not on its own	Available, but not on its own	Available, but not on its own	Available, but not on its own	Available, but not on its own	Available, but not on its own
Authority	Available	Available	Available	Available	Available	Available

Available Available, but not on its own Not available

Example usage

Take the invoice check from the loop above. It's asking whether the bill matches what was ordered and what arrived. Two questions decide where it lands.

1. What does settling it demand? The order already decided what's correct, so the check just reads the answer instead of working it out. That's Skill.
2. What can you know when you decide? The numbers match or they don't, and a trusted purchase order tells you which, so nothing is left to chance. That's Risk.

Look down the Skill and Risk columns for a family with a dot in both. Reference and Authority both qualify, and the matrix lands where the check already was. Reference is the stronger of the two, so it decides. Authority is the person the loop hands to once the ceiling is hit, the way the second and third builds of the loop showed it, and Exhaustion's ring is the budget that sets that ceiling. The two rules above the table still hold regardless. Build three adds a second decision, Resolve proposing a match from precedent. Matching a known situation is Rule-based, and a similarity score has no known odds behind it, so that is Uncertainty. Read down those two columns and Challenge qualifies outright, a second checker the third build does not add, while Estimate only holds a ring under Uncertainty, so it can propose but not settle, which is why the proposal goes back to the check, where the original Skill by Risk decision runs again on the proposed match.

SKILL.md

The following skill turns those two rules and the five families into a written record, whether you're checking a piece of shipped work or a running loop.

Where to next

Agentic Decision Rights provide a starting framework to work from to remove the human bottleneck. Mapping the decision space provides a means to systematically evaluate and iterate ever more complex decisions. It also helps define where a human is still needed.

We can then start to look at closing the gap when it comes to Knowledge and Ambiguity to ultimately grant those decisions too.

Frequently Asked Questions

What are agentic decision rights?

Agentic decision rights are the rules provided to an agent to make decisions that a human would otherwise make. Every loop hands over one of these rights, written down or not. This picks up where the human bottleneck comes down to one decision: is it correct, and good enough to move on.

How do you decide when an AI agent should stop?

Pick the state you want the loop to land in: finish the job, run out of budget, or hand the call to a person. The five families of exit condition run from Reference through Estimate, Challenge and Exhaustion, down to Authority, which always goes to a person. The order matters: the common failure is running a weaker family and reporting its result as if it came from a stronger one.

What is a loop exit condition?

It's the test an agent loop runs each time round, to decide whether to stop or go again. Often, it's just a counter, for example CrewAI's max_iter, and a counter doesn't test the work itself. A useful one also says whether the loop finished, ran out of budget, or handed the call to a person.

Why shouldn't an AI agent check its own work?

A model checking its own work has the same blind spots it started with. Huang et al. (2023) found language models can't reliably fix their own reasoning without outside feedback, and Song (2026) found a fresh session catches more, an F1 of 28.6% against 24.6%, a real gain but not a big one. At minimum, give the reviewer a new session and a clean context window. Putting a different model in the seat is my own risk-reduction rule.

What should an AI agent do when it cannot finish a task?

It should stop and hand the job to a person, and that handover has to be visible in the result. A run that hits its cap and reports as finished is the failure nobody downstream can see. Claude Code's auto mode handles this well, pausing after its classifier blocks an action 3 times in a row, or 20 times in total.

How many iterations should an agent loop run?

The number itself is the wrong thing to argue about. A cap is a budget, not a test of whether the work is done, so the defaults scatter widely: CrewAI sets max_iter to 20, Inngest allows 4 retries, and LangGraph sets recursion_limit to 1000 since version 1.0.6. Set whatever your budget can afford. Then ask the question that matters: when the cap runs out, does the loop say so, and does whoever called it find out?

Who should decide when an AI agent escalates?

At the start, a person decides on every case the loop isn't sure about. You don't write the rule up front, you build it from what the person decided: log what they chose and why, then turn the answers that hold up into the rule itself. Learning to defer is the formal version of this idea. The harder part is ownership, because a threshold nobody's name is on is a decision nobody signed for.