Authority Levels for Human and Agent Work: A Table You Can Paste

The table below adapts the five-level delegation model (Full Focus) into two columns, one for a person and one for an agent. The shared control model behind it is well established: responsibility and decision rights get assigned on purpose rather than by default (Human Performance Technology).

Two design choices matter here. First, keep five levels rather than three. Seven-level models such as Jurgen Appelo's add nuance (Tell, Sell, Consult, Agree, Advise, Inquire, Delegate) but tend to stall in practice because teams argue about the difference between level 4 and level 5 instead of shipping (Humanizing Work). Five levels map cleanly onto observable behavior, which is what you need when the delegate is software.

Second, note that the level describes authority over decisions, not the amount of work. A level 1 task can be enormous (analyze a whole codebase and propose an architecture) while a level 5 task can be tiny (rotate a credential on a schedule). Teams that confuse effort with authority end up reviewing everything, which is the failure mode the MIT autonomy framework calls out: a pause button only helps if the person can see what is happening and knows when to press it (MIT Media Lab).

Compare this with older team-role tools. A RACI matrix says who is Responsible, Accountable, Consulted and Informed, but says nothing about how far the responsible party may go before asking (Human Performance Technology). The authority table fills exactly that gap, which is why the two are complementary rather than competing: RACI for who, authority level for how far.

The level belongs in the task itself, not in a separate document nobody opens. There are three practical places to record it, in order of reliability.

The first is a required custom field. Jira, Linear, Asana and most ticket systems allow a single-select field, and making it required at creation is the whole trick. If a task can be created without a level, one will be created without a level by Friday.

The second is a structured block at the top of the task description, for tools without custom fields. Keep it to four lines so people actually fill it in:

AUTHORITY
human_owner: @name  level: 3
agent: @tool        level: 2
stop_condition: post recommendation, wait for approval
escalate_if: spend over $500, external message, schema change

The third is inside the agent's own instructions, which matters when the agent reads the ticket. Agents perform best with explicit, narrow instructions and clearly defined guardrails rather than vague objectives (OpenAI). Anthropic's engineering guidance says the same thing from the architecture side: start with the simplest pattern that works and add autonomy only when the task demands it, because agentic systems trade cost and latency for capability (Anthropic). A level written in the prompt is a cheap way to make that trade explicit per task.

Three rules make the field trustworthy:

1. The level is per task, not per person or per tool. A senior engineer can hold level 5 on a pricing model and level 1 on a legal memo in the same afternoon.
2. Every level 4 and 5 task names a stop condition, even if it is "none, but log everything." A stop condition of "none" is a valid answer only when the owner accepts the consequences.
3. The level is set by the person who owns the outcome, not by the person or agent doing the work. Anyone can request a higher level in the ticket; only the owner can grant it.

Concrete tasks make the table stick. These examples assume a mixed team where some work is done by people and some by agents, sometimes on the same ticket.

The level 3 row is the one that pays for itself fastest. It is where people most often assume they have authority they do not have, and where agents most often take action nobody asked for. Research on agent oversight puts the same problem precisely: even small divergences between the goal given, the plan formed and the execution carried out change how work gets done, and some of those divergences look like success (Data & Society). A level 3 task forces the plan into the open before execution.

If your team runs agents through a single gateway, note that the level can be enforced at the platform layer as well as the prompt layer. Gateway agents, meaning oversight systems that evaluate proposed actions against policy at runtime, escalate when an action crosses a risk, financial or ambiguity threshold (Sweet Security). That is level 3 enforced by infrastructure rather than by good intentions.

Mismatches are the normal case, not the exception. Two rules resolve almost all of them without a meeting.

The lower level wins until the owner raises it. If the human owner holds level 2 and the agent is configured for level 4, the agent operates at level 2. If the human owner holds level 4 and a colleague expects to be consulted, the owner still decides but informs. This rule is asymmetric on purpose: authority moves up only with an explicit change to the field, and the change is logged. It mirrors the pattern in delegation research where the manager retains accountability even after handing over responsibility (HBR).

Any irreversible action escalates one level. Sending an external message, spending money, deleting data, changing production configuration or merging to a main branch all bump the effective level by one at the moment of action. A level 4 agent that was going to deploy becomes a level 3 agent that proposes the deploy. This is the same logic the MIT autonomy framework applies to agent design, where the authority to act is bounded by tools, spend limits, destination restrictions and expiration (MIT Media Lab).

A short mismatch decision table helps in review:

The "default to level 2" rule is the most useful of the five. It means a mismatch never blocks work; it only limits what the work may change. The person who knows the answer can move the level up in seconds, and the record shows who did it.

Copy the block below into a team wiki, a README or the top of a project doc. It is deliberately short enough to be read, which is the only thing that keeps it alive.

AUTHORITY LEVELS (per task)

1 Suggest only ........ propose, change nothing
2 Research and report . gather facts, no recommendation needed
3 Recommend and confirm recommend, act after approval
4 Decide and inform ... act within limits, then report
5 Decide and act ...... full authority, log everything

RECORD IT
- Set both levels in the ticket: human owner and agent.
- The level is required. No level, no start.
- The owner sets the level; workers may request a change.
- Level 4 and 5 tasks name a stop condition.

RESOLVE MISMATCHES
- Lower level wins until the owner raises it.
- Irreversible actions escalate one level, always.
- Unclear case: default to 2 and write down the options.

Keep the escalation list short and absolute. Three or four entries are enough for most teams, and each entry should be something a reviewer can recognize without judgment: money, external parties, deletions, production. Everything else belongs in the stop condition line of the specific task.

Finally, resist the temptation to add levels or modifiers. Every additional option increases the chance that two people read the same task differently, which is the exact failure the table exists to prevent. A table that gets used at five levels beats a perfect framework that gets skipped.