How many of your production agents still have a spreadsheet, a shared inbox, or a ServiceNow queue running quietly beside them? If you have shipped more than a couple of agent workflows, the honest answer is probably at least one.
That parallel path usually starts as a sensible safeguard during shadow mode. However, six months later it is still taking writes, still drawing on-call attention, and still splitting the source of truth in two.
Running both has a cost you can put a number on. For example, a triage team that spends approximately 10 hours a week reconciling the agent's Zendesk output against the old tracker is spending close to $40,000 a year in loaded labor, before anyone counts the drift incidents.
This piece covers the three decisions that let infrastructure leaders retire the legacy path cleanly: the cutover criteria the agent has to clear, an ownership handoff that names who carries the pager, and sunset communications that keep the affected teams on side. Each one is a separate decision, and skipping any of them is how a decommission turns into a second rollout.
Decommissioning means formally retiring the manual workflow an agent replaced by freezing writes, archiving records, and removing access. Until then, two systems hold the truth and the team fully trusts neither.
Why Does The Old Process Keep Running?
Before setting criteria, it helps to understand why legacy paths survive. In practice, nobody decides to keep them — they survive because nobody decides to end them.
- No exit criteria were written. The rollout plan defined shadow mode and go-live, but never set the day the old queue stops accepting work. Without a date, temporary becomes permanent.
- Exception paths live in people's heads. The spreadsheet has a column for edge cases the agent was never trained on. Staff keep it open because it is the only place those cases get handled.
- Ownership is ambiguous. The platform team believes the business unit owns the retirement, and the business unit believes the platform team does. As a result, nobody files the change request.
- Trust was never earned in public. The agent may well be outperforming the manual process, but the people who ran that process have not seen the numbers. Naturally, they hold on to their safety net.
All of these are organizational gaps, which is why the fix starts with a written cutover standard that everyone can read before any access is revoked. If you have already worked through the broader AI change management playbook, decommissioning is its final and often-skipped step.
What Cutover Criteria Should The Agent Clear First?
Cutover criteria are the evidence that the agent can carry the full load without the manual path behind it. Keep in mind that they should be written and agreed on before shadow mode ends, so nobody is negotiating thresholds after the fact.
Set four gates: SLOs met for a full business cycle, legacy volume near zero for about 30 days, every exception mapped to an owner, and a rehearsed rollback. If any gate is open, the cutover waits.
- Performance against SLOs. The agent has met its agent SLOs for accuracy, P95 latency, and escalation rate for at least one full business cycle. For a finance close process that means a month-end, while a ticket triage flow may need two to four weeks.
- Legacy volume. The old path has handled near-zero new work for roughly 30 consecutive days, measured from logs and not from anecdote. If the spreadsheet is still taking around 15% of cases, the agent has not replaced it yet.
- Exception coverage. Every exception the manual process handled is mapped to an agent tool, a human escalation route, or an explicit decision to stop doing it. Unmapped exceptions are how shadow processes come back.
- Rollback rehearsal. The team has run the degraded-mode runbook at least once in staging or during a scheduled change window. Until someone has actually run a rollback plan, it is a hypothesis.
The comparison below shows how each gate maps to the evidence you should be able to produce on the day you request the change.
| Gate | Evidence to produce | Typical threshold | Signs off |
|---|---|---|---|
| SLO attainment | Dashboard export of accuracy, P95 latency, and escalation rate | One full business cycle at target | Outcome owner |
| Legacy volume | Write logs from the old system | Near zero for approximately 30 days | Platform team |
| Exception coverage | Exception catalog with a route for each case | Every case mapped | Exception steward |
| Rollback rehearsal | Runbook execution record | At least one successful drill | On-call lead |
What's more, the agent's autonomy level should match the gate. If the agent still needs human approval on every action, it is not ready to stand alone, and moving it through graduated levels of supervised autonomy (approve every action, then approve by exception, then audit after the fact) gives the cutover review the evidence trail it needs.
Overall, the criteria turn the decommission decision into a reading of evidence instead of a debate. If the gates are met, the conversation is short, and if they are not, you know exactly what is missing.
How Do You Hand Off Ownership Of The Workflow?
The manual process had an owner, even if nobody wrote it down. Usually that person was the team lead who knew which rows in the spreadsheet mattered and who to call when the queue backed up.
Once the agent carries the work, that knowledge has to land somewhere specific. We split ownership into three named roles and write each name into the runbook before cutover.
The business owner stays accountable for the outcome, and the platform team owns the agent's runtime, tools, and on-call. Both names go into the runbook before cutover, not after the first incident.
- Outcome owner (business). Accountable for whether the work gets done correctly, whether that means a claim adjudicated, a ticket routed, or an invoice matched. This person approves SLO changes and decides which exceptions the business will stop handling.
- Runtime owner (platform). Accountable for the agent's availability, model-version pinning, tool registry, and on-call rotation. This team carries the pager when the agent fails and runs the agent incident response process.
- Exception steward. Often a former operator of the manual process, now handling the escalations the agent routes out. This role keeps institutional knowledge in the building and feeds new edge cases back into the evaluation set.
In addition, the handoff should transfer artifacts along with titles. The exception catalog, the escalation tree, and the historical error log move into the platform team's repository, where they become regression cases for agent evaluation.
For the runtime patterns that govern how work moves between agents and humans, see our guide to agent handoff patterns. The ownership handoff described here is the organizational counterpart, and it should match the roles already defined in your agent operating model.
Sunset Communications That Keep Your Team's Trust
The people who ran the manual process are watching how you retire it. If the old queue disappears overnight after a one-line email, they will reasonably expect the next change to arrive the same way.
That said, good sunset communications come down mostly to sequence and specificity. We use a three-notice cadence, with every notice sent by the business outcome owner and not by the platform team.
Send three notices from the business owner: at announcement, at read-only, and before deletion. Each one names the date, the reason, the new escalation path, and a person to contact.
- Notice one: the announcement. Sent roughly 30 days before writes stop. It explains why the process is retiring, shows the agent's performance against the old baseline, and names the new escalation path.
- Notice two: read-only. Sent on the day the legacy system stops accepting writes. It confirms that history is still viewable, repeats the escalation contact, and states the archive date.
- Notice three: deletion. Sent about two weeks before access is removed. It confirms what has been archived, where it lives, and who can retrieve it for an audit.
Remember that the performance numbers in notice one carry the most weight. Operators are far more likely to trust a before-and-after chart of error rates and cycle times than a general assurance that the agent is performing well.
Moreover, the notice should say plainly what happens to the people who ran the old process. If their role is shifting to exception handling or evaluation review, name that role, and our piece on agent manager enablement covers how to prepare team leads for that conversation.
A decommission notice that leads with cost savings and buries the role change will be read as a layoff notice. Lead with the evidence, then the new roles, then the dates.
Staging The Shutdown: Read-Only, Archive, Delete
Decommissioning should happen in stages, and every stage should be reversible except the last. This gives auditors, operators, and the platform team time to catch anything the cutover review missed.
Shut down in three stages: freeze writes, archive to governed storage, then delete after the retention period. Every stage except the last can be reversed, so problems surface while recovery is still cheap.
- Freeze writes. Revoke write permissions on the spreadsheet, disable the inbox's inbound rule, or close the ServiceNow assignment group to new tickets. Keep read access open so operators can still look up history.
- Archive. Export records to governed storage, such as an S3 bucket with Object Lock and KMS encryption or a Snowflake table with access history enabled. Record row counts and checksums for the export so you can prove the archive is complete.
- Delete. Remove the source system only after legal and records management confirm the retention schedule, which often runs 90 days or longer in regulated environments. Then remove the IAM roles, service accounts, and integration credentials the old process used.
Note that the final stage includes identity cleanup. Service accounts and API keys left behind by a retired workflow are an unnecessary attack surface, and our guidance on agent identity and access covers how to inventory them.
Additionally, align the archive with your agent data retention policy so the old process's records and the agent's logs follow the same schedule. Two retention rules for the same business record will eventually produce an audit finding.
Finally, schedule each stage inside a normal agent change window. A decommission is a production change, and it deserves the same review, notification, and rollback planning as any release under your agent release management process.
Keeping A Degraded Mode Without Keeping The Old Process
Retiring the manual path still requires a plan for the day the agent cannot run. The answer is a documented degraded mode that switches on only during an outage, in place of a parallel process that runs all the time.
A degraded mode is a documented fallback that activates only when the agent fails. Work routes to a holding queue, and trained staff process it by hand until the agent recovers.
- A dead-letter queue humans can drain. When the agent fails, work lands in an SQS dead-letter queue or a holding table with a simple review interface. Operators process it by hand until the agent recovers.
- A circuit breaker with a clear trigger. For instance, three consecutive failed tool calls or a P95 latency breach lasting 10 minutes routes new work to the holding queue automatically. Because the trigger lives in code, nobody has to make that call at 2 a.m.
- A rehearsed runbook. The exception steward and the on-call engineer run the degraded mode once per quarter. Without that rehearsal, the skill of processing work by hand fades within a few months of the decommission.
The retries, circuit breakers, and incident paths behind a degraded mode follow the patterns of reliability engineering for regulated AI. This is why the degraded mode becomes the safety net the team can trust once the spreadsheet is gone.
How Do You Know The Decommission Worked?
Decommissioning is complete when the old path is gone and the organization has stopped missing it. You can measure both halves.
- Legacy-path writes. The target is zero. Every write attempt against the frozen system is logged as a permissions denial and points to a workflow someone still depends on.
- Exception steward volume. If escalations hold steady or fall, the agent is handling its scope. If they rise, the exception catalog was incomplete.
- Shadow tooling. Watch for new spreadsheets, personal trackers, or unsanctioned chatbot use around the same workflow. Our piece on shadow AI covers how to find them without turning the search into surveillance.
- Reconciliation hours saved. This is the labor the parallel process was consuming, now redirected. The business owner will want this number for the next agent business case.
All of these belong on the same dashboard as the agent's own telemetry. If you have already built agent observability and agent adoption metrics, the decommission measures are a small extension of both.
Frequently Asked Questions
These are the questions we hear from infrastructure and operations leaders while a cutover is being scoped.
What happens to the people who ran the manual process?
Most move into exception handling, agent review, or evaluation work, where their edge-case knowledge is most valuable. Name the new role in the first sunset notice so the change reads as a reassignment.
How long should the legacy system stay read-only before deletion?
Keep it read-only for at least one audit or retention cycle, often 90 days or longer, so investigators can reconcile historical records. Delete it only after legal and records management confirm the schedule.
What if staff keep using the old spreadsheet after cutover?
Treat it as a signal about the agent first. Continued use usually means an edge case or exception path is unmapped, so interview the users, log the case, and close the gap before tightening permissions further.
Should decommissioning wait until the agent handles every edge case?
No. Wait until every edge case has an owner: an agent tool, a human escalation route, or a documented decision to stop handling it. Routing coverage is the bar for cutover, and automation can expand afterward.
How do you measure whether the decommission succeeded?
Track legacy-path writes (target zero), escalation volume to the exception steward, agent SLO attainment, and reconciliation hours saved. Review them at 30 and 90 days, then fold them into normal reporting.
Planning A Decommission?
Retiring the manual process is the step that turns an agent pilot into a real operating change. It also decides whether your teams will trust the next rollout.
If you're scoping the cutover for an agent that has run beside a legacy queue for months, the team at iSimplifyMe builds and operates production agent systems across CRM, ticketing, and data warehouse environments every week. Reach out for a working session: we'll audit your cutover gates, draft the ownership map and sunset notices, and leave you with a staged decommission plan your change board can approve.