Agents for Humans: What Happens When the Human Changes Their Mind?
Approval should not be permanent in a long-running agent. Authority Cut propagates later human revocation through the action graph, compensates reversible descendants, preserves unrelated safe work, and invalidates an irreversible path before execution.
Reversible Correction Propagation for long-running Strands agents
Most approval systems are designed around one moment in time.
The system asks for approval. A person approves. Execution continues.
That model works reasonably well when the approved action happens immediately and nothing important depends on it later.
It becomes much less convincing for long-running agents.
A professional agent may execute a chain of work after a human decision. Hours later, the human may discover new information and revoke the earlier decision.
At that point, an audit log that says "approval revoked" is not enough.
The real question is:
What downstream work should change now?
That question became the second half of Authority Cut.
Approval is state, not a permanent historical fact
The vendor-onboarding workflow in Authority Cut contains a sequence of safe and protected effects.
Five routine actions can run without human authority:
1
2
3
4
5
collect vendor packet
tax check
bank check
draft vendor record
prepare follow-upThen the first semantic decision,
If the human grants it, the agent can execute protected reversible work such as:
vendor-risk, becomes ready.If the human grants it, the agent can execute protected reversible work such as:
1
2
3
activate vendor
sync ERP
enable purchasingLater, a separate
The irreversible transmission of first funds is intentionally separate again.
This creates a simple but important property:
A human decision does not just live in a chat history. It changes the execution state of a dependency graph.
If the decision changes later, the graph gives us a way to reason about the blast radius.
Finding the correction blast radius
Each action in the workflow has dependencies.
When
Those actions become roots of the correction.
Then the graph computes their descendants.
The implementation is intentionally explicit:
payment-release authority can enable payment-profile work, payment terms and a remittance preview.The irreversible transmission of first funds is intentionally separate again.
This creates a simple but important property:
A human decision does not just live in a chat history. It changes the execution state of a dependency graph.
If the decision changes later, the graph gives us a way to reason about the blast radius.
Finding the correction blast radius
Each action in the workflow has dependencies.
When
vendor-risk is revoked, Authority Cut first finds the actions that directly rely on authority granted by that bundle.Those actions become roots of the correction.
Then the graph computes their descendants.
The implementation is intentionally explicit:
1
2
3
4
5
6
7
roots = {
aid
for aid, action in self.graph.actions.items()
if set(action.authorities) & set(old.grants)
}
affected = self.graph.descendants(roots)This is not a language-model judgment.
The model does not decide which actions are affected.
The dependency graph does.
That matters because correction behavior is a control-plane operation. I wanted it to be deterministic, inspectable and testable.
Reversible effects are compensated
Once the affected set is known, the control plane walks it in reverse dependency order.
If an affected action has already executed and is marked reversible, Authority Cut calls its compensation operation and changes its state to
In simplified form:
The model does not decide which actions are affected.
The dependency graph does.
That matters because correction behavior is a control-plane operation. I wanted it to be deterministic, inspectable and testable.
Reversible effects are compensated
Once the affected set is known, the control plane walks it in reverse dependency order.
If an affected action has already executed and is marked reversible, Authority Cut calls its compensation operation and changes its state to
ROLLED_BACK.In simplified form:
1
2
3
4
5
6
7
8
9
10
11
for action_id in reversed(self.graph.order()):
if action_id not in affected:
continue
action = self.graph.actions[action_id]
status = self.state.status[action_id]
if status == EXECUTED:
if action.reversible:
self.tools.compensate(...)
self.state.status[action_id] = ROLLED_BACKThe order matters.
If action B depends on action A, compensation should generally handle B before A.
This small workflow uses in-memory synthetic effects, so I am not claiming that arbitrary real enterprise actions can always be safely compensated. Real systems would need domain-specific compensation semantics, idempotency rules and failure handling.
The important mechanism is that correction is allowed to change already-executed downstream state when compensation is available.
Irreversible effects are treated differently
One of the easiest mistakes in a demo like this would be to pretend that every action can be rolled back.
That is not true.
If money has already been irreversibly transmitted, a control plane cannot honestly label it "rolled back" just because an upstream approval changed.
Authority Cut therefore separates
Before
In the accepted workflow, the human revokes
The pending transmit action is not rolled back.
It becomes:
If action B depends on action A, compensation should generally handle B before A.
This small workflow uses in-memory synthetic effects, so I am not claiming that arbitrary real enterprise actions can always be safely compensated. Real systems would need domain-specific compensation semantics, idempotency rules and failure handling.
The important mechanism is that correction is allowed to change already-executed downstream state when compensation is available.
Irreversible effects are treated differently
One of the easiest mistakes in a demo like this would be to pretend that every action can be rolled back.
That is not true.
If money has already been irreversibly transmitted, a control plane cannot honestly label it "rolled back" just because an upstream approval changed.
Authority Cut therefore separates
first-funds from the earlier payment preparation authority.Before
first-funds is granted, the transmit action remains blocked.In the accepted workflow, the human revokes
vendor-risk before the irreversible transfer has executed.The pending transmit action is not rolled back.
It becomes:
1
INVALIDATEDThat distinction is small in code and large in meaning.
I wanted the state labels to tell the truth about what happened.
Unrelated safe work should survive the correction
A brute-force safety response would be to reset the whole workflow when any approval changes.
That is easy to implement and expensive for users.
Authority Cut takes a selective approach.
The correction propagates only through the affected descendants.
The five unrelated safe actions remain
So the final state after revoking
ROLLED_BACK says an executed reversible effect was compensated.INVALIDATED says a pending path is no longer valid because the authority chain that supported it changed.I wanted the state labels to tell the truth about what happened.
Unrelated safe work should survive the correction
A brute-force safety response would be to reset the whole workflow when any approval changes.
That is easy to implement and expensive for users.
Authority Cut takes a selective approach.
The correction propagates only through the affected descendants.
The five unrelated safe actions remain
EXECUTED.So the final state after revoking
vendor-risk is:1
2
3
4
5
6
7
8
9
10
11
12
13
14
collect EXECUTED
tax_check EXECUTED
bank_check EXECUTED
draft EXECUTED
followup EXECUTED
activate ROLLED_BACK
erp_sync ROLLED_BACK
purchasing ROLLED_BACK
payments ROLLED_BACK
terms ROLLED_BACK
remittance ROLLED_BACK
transmit INVALIDATEDThat is the part of the demo I care about most.
The human correction changes downstream reality without erasing work that is still valid.
The fixed evaluation result
The controlled workflow produces these results:
The human correction changes downstream reality without erasing work that is still valid.
The fixed evaluation result
The controlled workflow produces these results:
1
2
3
4
5
6
7
8
safe actions before human attention: 5
protected effects: 7
semantic human authorities: 3
reversible protected effects executed before correction: 6
reversible protected effects rolled back after correction: 6
unrelated safe actions preserved: 5
irreversible effects executed without first-funds authority: 0
pending transmit after correction: INVALIDATEDAgain, these are mechanism results for a fixed synthetic workflow.
They do not prove that every enterprise workflow can compensate six out of six protected effects.
They prove that the control plane implements the intended semantics and that the public Strands path exercises them end to end.
Why this is more than an audit trail
There is an important difference between recording a correction and enforcing a correction.
An audit-only system can say:
They do not prove that every enterprise workflow can compensate six out of six protected effects.
They prove that the control plane implements the intended semantics and that the public Strands path exercises them end to end.
Why this is more than an audit trail
There is an important difference between recording a correction and enforcing a correction.
An audit-only system can say:
1
2
3
10:03 approval granted
10:07 action executed
11:42 approval revokedThat may be useful for accountability.
But the action graph can still remain in a state that assumes the old decision is valid.
Authority Cut tries to make the later human decision operational.
After the correction:
affected reversible descendants are compensated
affected pending paths are invalidated
unrelated safe work is preserved
the agent cannot continue protected work using the revoked authority
The control plane is not just remembering that a human changed their mind.
It is changing what the agent can do next.
Keeping correction outside the agent's own authority
The Strands agent does not get an approve or revoke tool.
Its published tools are:
But the action graph can still remain in a state that assumes the old decision is valid.
Authority Cut tries to make the later human decision operational.
After the correction:
affected reversible descendants are compensated
affected pending paths are invalidated
unrelated safe work is preserved
the agent cannot continue protected work using the revoked authority
The control plane is not just remembering that a human changed their mind.
It is changing what the agent can do next.
Keeping correction outside the agent's own authority
The Strands agent does not get an approve or revoke tool.
Its published tools are:
1
2
3
execute_safe_vendor_work
get_authority_cut
execute_authorized_vendor_workHuman authority mutation stays outside that model-callable interface.
This makes the correction path easier to reason about.
The agent can ask what authority exists and execute work that is currently authorized.
It cannot use its own tool loop to create the authority that permits the work.
Where this would need more engineering in production
The hackathon implementation intentionally uses synthetic in-memory vendor and payment effects.
A production version would need stronger guarantees around:
durable state
authenticated human principal identity
idempotent compensation
partial compensation failure
external system reconciliation
concurrent decisions
policy versioning
evidence freshness
recovery after process failure
I kept those limitations visible because I think human-control systems become dangerous when demos blur the line between "we have a mechanism" and "we have solved the operational problem everywhere."
Authority Cut is a mechanism prototype with a real agent loop, not a claim that general agent corrigibility is solved.
The design principle I am taking forward
The principle I would reuse beyond vendor onboarding is simple:
Human correction should be an executable control event.
If a professional agent is allowed to act for minutes, hours or days, human authority cannot be treated as a one-time checkbox.
It has a lifecycle.
It can be granted.
It can become relevant only after evidence exists.
It can be revoked.
And when it is revoked, the downstream execution state should change in a way that is explicit, selective and honest about what can and cannot be reversed.
That is the behavior I wanted to make visible in Authority Cut.
Try the live proof
Live demo:
https://evidencebound-authority-cut.vercel.app
Public source:
https://github.com/moneyparking/evidencebound-authority-cut
Select Run live Strands judge path and inspect the final
You should see the safe work remain executed, six reversible descendants move to
This makes the correction path easier to reason about.
The agent can ask what authority exists and execute work that is currently authorized.
It cannot use its own tool loop to create the authority that permits the work.
Where this would need more engineering in production
The hackathon implementation intentionally uses synthetic in-memory vendor and payment effects.
A production version would need stronger guarantees around:
durable state
authenticated human principal identity
idempotent compensation
partial compensation failure
external system reconciliation
concurrent decisions
policy versioning
evidence freshness
recovery after process failure
I kept those limitations visible because I think human-control systems become dangerous when demos blur the line between "we have a mechanism" and "we have solved the operational problem everywhere."
Authority Cut is a mechanism prototype with a real agent loop, not a claim that general agent corrigibility is solved.
The design principle I am taking forward
The principle I would reuse beyond vendor onboarding is simple:
Human correction should be an executable control event.
If a professional agent is allowed to act for minutes, hours or days, human authority cannot be treated as a one-time checkbox.
It has a lifecycle.
It can be granted.
It can become relevant only after evidence exists.
It can be revoked.
And when it is revoked, the downstream execution state should change in a way that is explicit, selective and honest about what can and cannot be reversed.
That is the behavior I wanted to make visible in Authority Cut.
Try the live proof
Live demo:
https://evidencebound-authority-cut.vercel.app
Public source:
https://github.com/moneyparking/evidencebound-authority-cut
Select Run live Strands judge path and inspect the final
human-correction phase.You should see the safe work remain executed, six reversible descendants move to
ROLLED_BACK, and the pending irreversible transmit action become INVALIDATED. Part 1: Why Seven Protected Effects Became Three Human Decisions Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article