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.
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:
Scroll to see the full diagram
In loop engineering that check is completed by an agent:
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.
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.
A decision can be looked at from five angles, and each one asks something different about what you can hand to an agent.
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 |
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 |
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 |
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 |
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.
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.
Scroll to see the full diagram
Scroll to see the full diagram
Scroll to see the full diagram
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.
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.
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:
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:
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:
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:
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:
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
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.
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.
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.
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.
{% faqs faqs %}