Demotion criteria are part of agent authority design

Most teams are getting better at asking when an AI agent should be allowed to do more.

That is progress.

They ask whether the agent has enough evidence. They review exception logs. They design rollback plans. They create audit packets before changing permissions.

But the other half of authority design is still too often missing:

What would make this agent lose authority?

If an agent can be promoted, it should also be demoted.

Not as punishment.

As operating hygiene.

The team should know, before the next incident, which signals mean the agent should move down a level: from execute to recommend, from recommend to prepare, from prepare to observe, or from live operation back to review-only mode.

An agent without demotion criteria is not really being governed.

It is being trusted until something breaks loudly enough.

What changed

This morning’s scan did not produce a single release that justified a news-led post.

The stronger live signal was broader:

• enterprise-agent discussion keeps moving toward governance, auditability, permissions, and operating control
• platform announcements and commentary keep treating agents as workflow participants, not just chat tools
• coding-agent discussion keeps surfacing the practical pain of supervising multiple capable systems at once
• governance checklists are becoming common, but many still emphasize approval and access more than authority reduction

The best live candidate was:

Enterprise agents are becoming normal workflow participants, but teams are still weaker at removing authority than granting it.

That is a useful signal.

But as a standalone post, it would risk becoming another generic governance summary.

The best backlog candidate was:

How to define demotion criteria or authority rollback after an agent operating review.

That wins today because it produces a more practical Mada angle:

Demotion criteria should be designed at the same time as promotion criteria.

If the team cannot say what would reduce an agent’s authority, it is probably not ready to expand that authority.

Why this matters

Agent authority usually expands through small wins.

The agent drafts useful replies. It handles low-risk cases. It routes work correctly. It saves reviewers time. It completes routine actions without drama. It becomes part of the team’s daily operating rhythm.

Then the team adds a tool. Then removes an approval step. Then widens the eligible case class. Then lets the agent work in larger batches. Then extends the workflow to another team.

Each step can be reasonable.

The problem is not promotion.

The problem is promotion without an equally clear path down.

A human manager usually understands this instinctively. If someone is promoted and then struggles, the organization needs options: coaching, narrower scope, extra review, a different role, or in serious cases removal from the responsibility.

Agents need the same operating logic.

Not because they are people.

Because authority has consequences.

When an agent acts inside a real workflow, poor performance is not just a bad answer. It can create cleanup work, customer confusion, data errors, security exposure, compliance gaps, or hidden human review burden.

If the only response pattern is either “keep going” or “shut it down,” the team has designed a brittle system.

Demotion gives the system intermediate moves.

What people are overreacting to

People are overreacting to whether the agent is generally useful.

Usefulness matters, but it is not enough.

A generally useful agent can still deserve less authority in a specific context.

For example:

• it may be good at normal cases but weak at boundary cases
• it may perform well when volume is low but degrade when the queue grows
• it may handle one customer segment well but fail in another
• it may make strong recommendations but poor final actions
• it may be reliable with one tool but careless after a new tool is added
• it may save time for one team while creating cleanup work for another

The question is not only:

Is this agent valuable?

The sharper question is:

At what authority level is this agent currently valuable without creating unacceptable hidden cost?

That is a different management decision.

It allows the team to say:

The agent is still useful, but it should temporarily move from execution to recommendation in these cases.

That is much better than pretending the only choices are trust or abandonment.

What people are underreacting to

People are underreacting to authority drift.

Authority drift happens when the agent’s real operating role becomes larger than the role the team thinks it approved.

It can happen quietly:

• reviewers stop reviewing closely because the agent is usually right
• users start treating drafts as final decisions
• exceptions get handled in chat but never logged
• prompts change without a matching permission review
• the agent gets a new integration and nobody revisits the risk boundary
• volume increases and human review becomes symbolic
• the agent starts being used for adjacent cases outside the original design

Nobody announces, “We have expanded authority.”

But authority has expanded anyway.

Demotion criteria are one way to fight that drift.

They force the team to name not only the approved boundary, but also the signals that mean the boundary has become unsafe, stale, or too wide.

Without those signals, the agent can keep its authority long after the evidence has changed.

Design demotion criteria before they are needed

A useful demotion rule should be concrete enough to act on, but not so rigid that it creates fake precision.

I would start with five categories.

1. Evidence deterioration

The first demotion trigger is simple: the evidence no longer supports the current authority level.

That might mean:

• exception rates rise
• human overrides become more frequent
• reviewers catch more missing evidence
• recommendations become less stable
• rollback work increases
• customer or stakeholder complaints cluster around the agent’s actions
• human review takes longer than before because trust has weakened

The point is not to panic at one bad case.

The point is to notice when the operating record has changed.

A good rule might look like:

If exception patterns increase for two review periods, the agent moves from automatic execution back to approval-required execution for that case class until the cause is understood.

That is not bureaucracy.

It is a circuit breaker for trust.

2. Boundary confusion

The second trigger is boundary confusion.

Demote the agent when people cannot clearly tell whether a case belongs inside its authority.

This matters because ambiguous boundaries create two kinds of failure.

Sometimes the agent acts where it should not. Sometimes humans overuse the agent because it is convenient.

Both are management problems.

Signals include:

• repeated debate over whether the agent should handle a case
• users routing edge cases to the agent because it is faster
• reviewers approving work they do not fully understand
• the agent taking action after weak or ambiguous instructions
• inconsistent handling across similar cases

The demotion move here is often not full shutdown.

It is narrower scope.

Move the agent back to well-defined cases. Require human approval for ambiguous ones. Redraw the authority map. Then test expansion again later.

3. Reversibility weakness

The third trigger is weak rollback.

If the team cannot reliably undo, trace, or repair the agent’s actions, the agent should not keep high execution authority.

This is especially important when agents write to systems, send external messages, change records, trigger workflows, or coordinate work across tools.

Ask:

• Can we identify what the agent changed?
• Can we reverse it without guesswork?
• Can we notify affected people if needed?
• Can we separate agent-caused work from human-caused work?
• Can we repair state within an acceptable time window?

If the answer is no, demotion is appropriate even if the agent’s average performance looks good.

A high-performing agent with poor reversibility is still risky.

The right move may be:

Keep recommendation authority, pause autonomous execution, and rebuild the rollback path before restoring execution rights.

4. Human burden increase

The fourth trigger is rising human burden.

An agent can look successful on its own dashboard while quietly making people work harder around it.

Watch for:

• reviewers spending more time checking than before
• downstream teams cleaning up ambiguous outputs
• managers resolving conflicts created by agent actions
• users needing to rewrite agent work frequently
• support teams fielding confusion caused by automated messages
• engineers maintaining brittle prompts and patches just to keep the workflow stable

This is where teams fool themselves.

They count agent throughput but ignore surrounding coordination cost.

If human burden rises, the agent may need less authority, not more optimization.

Sometimes the right demotion is temporary:

The agent continues drafting, but final action returns to humans until the support burden and correction loop are reduced.

That preserves value while reducing operating drag.

5. Accountability mismatch

The fifth trigger is accountability mismatch.

Demote the agent when the authority it exercises is larger than the accountability structure around it.

This can show up when:

• nobody owns exceptions
• nobody reviews audit packets
• nobody maintains prompts or tools
• nobody is accountable for customer impact
• nobody can explain why a permission was granted
• nobody knows who can pause or narrow the agent

The problem is not the agent’s intelligence.

The problem is organizational design.

If nobody owns the boundary, the boundary should shrink.

A practical rule:

No agent should retain execution authority in a workflow where ownership, review cadence, rollback responsibility, and escalation paths are unclear.

That sounds strict.

It should be.

Authority without ownership is how small automation errors become organizational messes.

Make demotion ordinary

The healthiest teams will make demotion feel normal.

Not dramatic. Not embarrassing. Not a failure of the AI strategy.

Just part of operating the system.

An agent can move up when evidence improves. It can move down when evidence weakens. It can hold steady when the current boundary is working. It can be narrowed in one case class while expanding in another.

That is much more realistic than treating agent deployment as a one-way march toward more autonomy.

The management language should change from:

Should we trust the agent?

To:

What authority level has the agent currently earned, and what would cause that level to change?

That one shift makes the system safer and more useful.

What a manager or builder should do differently

If you manage or build AI agents, add a demotion section to the next operating review.

Keep it small.

For each meaningful authority level, define:

1. what the agent is currently allowed to do
2. what evidence supports that authority
3. what signals would reduce authority
4. what the lower authority state would be
5. who can trigger the demotion
6. how the team will know when authority can be restored

The important part is not the document.

The important part is having the move available before stress arrives.

When something goes wrong, teams are usually bad at calmly inventing governance from scratch.

They either defend the system too long because they invested in it, or they overcorrect and shut down useful automation because trust was damaged.

Demotion criteria create a better middle path.

They let the team reduce authority without losing the whole capability.

The test

Before expanding an agent’s permissions, ask this:

If this agent starts to struggle, what exactly happens before we call it a failure?

If the answer is vague, pause the expansion.

Define the demotion criteria first.

Because the real sign of mature agent management is not that every agent keeps gaining authority.

It is that authority can move in both directions based on evidence.