Why two agents behave differently
If one agent can do something and another cannot, start by confirming they are not supposed to differ.
- Abilities & permissions
- 3 min read
The model
Each agent has its own permission matrix. Nothing is shared between agents by default, and granting an Ability to one has no effect on any other — even one connected as the same WordPress user, in the same environment.
Each agent’s history stays separate too, which is what makes the audit trail able to answer “which system did this?”
Diagnosing a difference
When two agents behave differently for what looks like the same request, check in this order:
- Connection user. Different users mean different native ceilings, which is the most common explanation and has nothing to do with policy.
- Environment. Staging and production are different identities with different matrices.
- Agent state. One may be restricted or paused.
- The matrix itself. Compare the specific Ability on both agents.
- Request context. The risk engine reads inputs, so two calls to the same Ability with different inputs can legitimately land differently.
Keeping agents consistent on purpose
If several agents genuinely should share a boundary, apply the same decisions deliberately rather than hoping they drifted together. On the Agency plan, reusable governance standards make that repeatable across sites; on a single site, bulk changes against a filtered selection do the same job.
Abilities & permissions
Keep the boundary while you fix the problem.
A good fix restores intended behaviour without creating a second path around WordPress or the governed request lifecycle.