Irreversibility in IT changes

Some IT changes roll back in seconds. Others cannot be rolled back at all. Flipping a feature flag is undone by flipping it back. Dropping a database column, revoking a signing key or running a data migration that overwrites values is not. An agent allowed to make changes must know which kind each change is before it acts, and the platform must hold the second kind.

Why is "we can always roll back" often untrue?

Change management in most firms assumes a rollback plan. Every change ticket has a field for it. The trouble is that the field is filled in for changes that do not, in practice, have one.

A rollback restores the system's configuration. It does not restore what happened while the change was live. If a change altered data, sent messages, triggered payments or let the wrong people in, rolling back the code leaves all of that in place. The system looks as it did; the world does not.

So the useful question is not "can the change be rolled back?" but "what will still be different after we roll it back?". For many changes, the honest answer is nothing. For some, it is a great deal.

Which changes are reversible and which are not?

Grouping changes by what survives a rollback gives an agent, and its bounds, something to work with.

The difference between rows three and four is a good test for any agent working on infrastructure. Both are schema changes. One is reversible and one is not, and the label "schema change" hides that completely.

Why do agents raise the stakes?

People making changes usually carry a sense of which ones are dangerous, built from experience and the memory of past incidents. An agent does not have that sense unless it is given it, as data, attached to each change type.

Agents also act at speed and at scale. A person might run a migration on one table, check it, and move on. An agent asked to "clean up unused columns across the reporting schema" might drop a dozen in a minute, including one used by a monthly report nobody has run for three weeks. The broader shift from systems that advise to systems that act is set out in EU AI Act and agentic AI: what changes when the system acts.

For EU financial entities, DORA's ICT risk management requirements apply to how changes are controlled, whoever or whatever makes them. This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.

How should an agent's depth follow the change type?

• Depth 1: read configurations, schemas, dependency maps and change history.
• Depth 2: draft change requests, migration scripts and rollback plans, including an honest statement of what would survive a rollback.
• Depth 3: apply toggles, additive changes and configuration changes within agreed bounds, in environments where the change is fully reversible.
• Stays with a person, or depth 4 if earned for that change type: destructive schema changes, in-place data migrations, security changes and anything external-facing.

The same principle applies to business data changes made through IT systems. Payroll changes are a clear case, where a change applied before a pay run produces payments that cannot be pulled back; the approach in how to let an AI agent prepare payroll changes for approval separates preparation from application. Contact detail changes look trivial but can redirect every future letter and code, as covered in how to handle address and contact detail changes with an AI agent.

How can an irreversible change be made safer?

Many irreversible changes can be restructured into a reversible part and a smaller irreversible part, separated by time.

1. Expand, then contract. Add the new structure, run both side by side, and remove the old one only after the new one is proven.
2. Preserve before overwriting. Copy original values before a migration rewrites them, and keep the copy until the change is confirmed.
3. Stage revocations. Issue new credentials and confirm every dependant has moved before revoking the old ones.
4. Dry-run against a copy. Run the change on a recent copy and compare the result before touching production.

Each of these makes the agent's depth 3 work larger and the held step smaller. That is a good trade.

How does this compare with payments and lending?

In payments, the irreversible step is settlement, which is a single, well-understood event. In lending, it is drawdown. IT changes are harder to classify because the same tool, a migration runner or a configuration API, can make both reversible and irreversible changes. The bound has to be on the change type, not on the tool.

Where Pryme fits

In Pryme, capabilities are bounded by what they do, not by which system they touch. An agent can hold depth 3 for additive changes and depth 2 for destructive ones on the same system. The minimum chain checks the change type at the moment of action and holds anything irreversible for a named person. See why autonomy in regulated industries is a question about reversal.