Readable change records that compare old authority with new authority across policy, priority, permissions, and ownership.
A queue changes from quality-first to speed-first, but older work still carries review obligations.
// TRUST DENSITY · GOVERNED AGENT LABOR · June 20, 2026
Trust Density Needs Authority Diffs Before Agents Follow Changed Instructions
An agent should not obey a changed instruction until the system can show what authority changed, who changed it, and what work now becomes unsafe.
Operators cannot trust agent behavior if they only see the current instruction and never see what it replaced.
Agents adapt to new direction without quietly breaking promises, skipping approvals, or inheriting accidental power.
Instructions are not truth. They are versioned authority.
Most agent systems treat the latest instruction as the cleanest instruction. That is dangerous. The newest rule may be valid, but it may also override an unresolved exception, conflict with a customer commitment, or expand a worker's authority beyond what the operator intended.
Human teams catch some of this through memory and politics. Machine workers do not. They need an explicit diff that says: this changed, this authority moved, this permission widened, this prior constraint disappeared, and this downstream work is now exposed.
Trust density rises when every agent can explain not only what rule it followed, but what rule changed before it acted.
Five authority changes that need a diff before execution.
A worker gains write, send, approve, refund, discount, export, or delete rights it did not previously hold.
A task, segment, campaign, or customer state moves to a new accountable role without clearing open decisions.
Scoring, routing, escalation, spend, or qualification thresholds move and alter which work is touched automatically.
A guardrail disappears from the live prompt, config, CRM rule, or playbook and nobody reviews what it protected.
The risk is not that agents follow orders. The risk is that they follow changed orders with no memory.
A changed instruction can be perfectly reasonable in isolation and still unsafe in sequence. A revenue agent told to prioritize expansion may start touching accounts that were excluded from outreach last week. A support agent told to auto-close stale tickets may close cases that were waiting on legal review. A finance agent told to normalize payment terms may overwrite negotiated exceptions.
The problem is not malicious autonomy. It is missing contrast. Without authority diffs, every instruction arrives as if history never existed.
Authority diffs force the system to pause at the exact point where trust usually leaks: the moment new authority meets old commitments.
Changed field
The exact rule, prompt block, permission, threshold, owner, queue, segment, offer, or escalation policy that changed.
Previous authority
The prior instruction and the active work, commitments, or controls that depended on it.
New authority
The updated instruction, who approved it, when it became active, and which workers may use it.
Conflict surface
Open tasks, customer records, campaigns, approvals, and downstream agents that may now behave differently.
Execution gate
The minimum review, sample replay, or operator approval required before live workers follow the changed authority.
Real example: the outbound agent that obeyed a better rule and broke a promise.
A GTM team updates its outbound agent from “do not contact active opportunities” to “contact accounts with no reply in 21 days.” The new rule is useful. It reopens stale accounts and increases coverage. But several active opportunities have no reply because procurement is reviewing terms, and the account executive promised no automated outreach during negotiation.
Without an authority diff, the agent sees only the new instruction and starts sending. The dashboard shows activity. The sales team sees damage.
With an authority diff, the system compares the old exclusion against the new reactivation rule, flags active opportunities as a conflict surface, and requires a sample review before campaign execution. The agent still gets the improved rule, but not at the cost of invisible broken commitments.
The current instruction is not enough. Operators need to see the authority it replaced.
The share of policy, permission, and priority changes that produce an operator-readable authority diff.
How often diffs identify affected tasks, commitments, customers, or queues before execution.
The number of incidents where agents acted under changed authority without recorded contrast.
Install authority diffs where agents receive power.
Treat prompts, playbooks, permissions, thresholds, and queue rules as versioned operating authority, not disposable text.
Generate a structured old-versus-new diff whenever authority changes in a live lane.
List affected customers, tasks, campaigns, approvals, integrations, and downstream workers before execution resumes.
Use sample replay, operator review, or staged permissions before changed authority reaches production volume.
Concrete takeaway
Before agents follow changed instructions, require an authority diff for every meaningful change in policy, priority, ownership, permission, or threshold.
- Show contrast: every worker-facing rule change should expose what was added, removed, widened, narrowed, or reassigned.
- Attach approval: record who changed the authority, when it changed, and which workers are allowed to act on it.
- Find conflicts: scan open commitments, customer state, queue rules, and downstream automations before the new authority executes.
- Stage rollout: replay a small sample under the new authority before production workers receive full volume.
- Measure drift: track diff coverage, conflict catch rate, unauthorized permission growth, and incidents from silent instruction changes.
The blunt rule: if an agent can change behavior because authority changed, the operator deserves a diff before the behavior reaches production.