Unowned automation: what orphaned rules cost before and after AI
Nobody owning an automation rule costs more than building it did. The rule keeps firing after the process changed, fails without telling anyone, and blocks every later change because no one dares touch it. Adding AI on top multiplies the problem, since an agent trusts whatever the rules do.
Key takeaways
- A rule without an owner is a decision nobody can revisit.
- The failures are quiet: a ticket not assigned, a field not set, a notification not sent.
- Before an agent goes near a site, each rule it may trigger needs a name beside it.
How rules become orphans
An admin writes a rule to solve a problem on a Tuesday. It works, so nobody documents it. The admin changes teams, the rule’s actor is still their account, and a year later the rule is one of forty with names like "Copy of assign v2". No single step was careless.
Three costs you can observe
- Silent failure. The rule errors after a field is renamed. Work stops flowing to a team, and the first report comes from a customer.
- Frozen configuration. Admins refuse to change a workflow because they cannot tell which rules depend on it. Small requests wait for months.
- Contradiction. Two rules written a year apart set the same field to different values, and the result depends on which fires last.
What changes when an agent arrives
A person who sees an odd assignment asks a colleague. An agent does not. It reads the current state as intended, plans on top of it, and can trigger the orphaned rules with its own changes. The agent’s plan may be correct and the outcome still wrong, because a rule nobody remembered ran afterwards.
Reading the automation before proposing a change is the first principle of Supervised AI Delivery for exactly that reason.
Finding the orphans and assigning them
- Export the rule list with owner, actor, last run and last failure.
- Mark every rule whose owner has left or whose actor is a personal account.
- Disable rules that have not run in six months, and wait a fortnight for complaints.
- For each survivor, write one line of purpose and put a current name on it.
- Send failure notifications to that person, not to a shared inbox.
On a mid-sized Jira site the whole exercise is a few days, and it is a typical short automation project.
Frequently asked questions
How many rules is too many?
Should the owner be an admin or someone from the business?
If you suspect half your rules are orphans, a short Systems project sorts them before any AI work begins.