The Bot Graveyard Still Has Live Permissions

Nora Keepwell does not exist. Or rather, she exists the way a composite sketch exists: assembled from documented experiences, peer-reviewed interviews, audit findings, and the accumulated scar tissue of enterprise automation programs that scaled well past the point where anyone remembered the original business case.

Her title is Senior Director of Automation Operations at a large pharmaceutical company. Her bot fleet peaked at just over two hundred. Her Center of Excellence employs more people than the first three processes she automated ever did.

She agreed to this conversation on the condition that we not call it a success story.

We spoke over video. She had a mug that said "KEEP CALM AND CHECK THE EXCEPTION QUEUE." She did not seem calm.

You scaled from a pilot of about fifteen bots to over two hundred. When did the experience stop feeling like progress?

Nora: Somewhere around bot sixty. Maybe seventy. The first fifteen were genuinely great. You pick the right process, something repetitive and rule-heavy, you automate it, the team gets hours back, everyone's happy. The business case writes itself. So you do it again. And again. Someone in finance hears about it and wants one. Someone in regulatory wants one. And suddenly you're not a pilot anymore, you're a program. Nobody told you that being a program means you need governance. You figure that out when an auditor calls.

What did figuring it out look like, concretely?

Nora: A bot with hardcoded credentials in a config file that an auditor finds during a routine sweep. A vendor updating their UI on a Tuesday night and forty bots going dark by Wednesday morning because a button moved six pixels.¹ A retired bot whose system access nobody revoked for months. I want to say months. Honestly, I don't know if some of them ever got revoked.

The GSA inspector general found that fifty-five out of fifty-six bot custodians hadn't had access removed within the required fourteen-day window after decommissioning.² People read that and think it's negligence. It's the default outcome. Nobody wakes up planning to leave zombie credentials in production. But retiring a bot has no champion, no demo day, no congratulatory Slack thread. So it drifts.

You've said retirement is harder than deployment. That's a strong claim.

Nora: It's accounting. Even when someone files the ticket, you have to trace every system the bot touched, every credential it held, every queue it read from, every exception path that routed to a human who may have since left the company. The bot is dead but its skeleton is wired into everything. And the permissions outlive the process by years.

You eventually shut down your attended automation program entirely. What broke?

Nora: Math. Each attended bot, the ones that work alongside a person at their desktop, brings minimal efficiency individually. So the entire cost of creating, documenting, deploying, and maintaining them has to be incredibly lean, or the overhead eats the savings.³ We ran the numbers. The governance investment required to do it responsibly exceeded what we'd get back. So we killed it.

Which felt like failure at the time. In retrospect it was probably the most rational decision the program ever made. Certainly the least popular.

What did the governance apparatus look like at full scale?

Nora: You want the list? A Center of Excellence managing bot demand, licensing, change management, code review, SLA management with the vendor, disaster recovery documentation, a reusable object library. Then layered on top: identity and access management, multi-stage signoffs from business, technical, and leadership, security assessments, segregation of duties, bot criticality classification, data privacy safeguards, business continuity planning.⁴

One organization I've compared notes with had thirteen hundred unattended bots overseen by a board of division CIOs.⁴ That's a government. With a procurement cycle and everything.

How did you classify bot criticality?

Nora: A bot can be dead simple. Five steps, reads a spreadsheet, writes to a field. And still be posting significant financial transactions. That makes it critical. Bots that write to systems are higher risk than bots that read. Bots that touch cash accounts are highest. So the governance cost per bot isn't uniform, which means you can't just divide your CoE budget by your bot count and get a meaningful number. Some bots cost almost nothing to maintain. Others cost more than the person they replaced, which is a sentence I try not to say in steering committee meetings.

You mentioned exception handling. What's the accounting problem there?

Nora: The exception work doesn't show up where the savings were promised. The business case says: this bot saves 400 hours a year. Great. But the exceptions, the records that don't match, the timeouts, the edge cases the bot kicks back to a human, that labor lands in operations headcount, or maintenance, or QA, or just... someone's afternoon. It's distributed across the org in a way that never appears in the original ROI calculation.

The systematic review of eighty-three peer-reviewed RPA studies found the evidence base is still predominantly qualitative and case-based, with large-scale multi-industry performance studies basically absent.⁵ So I can tell you what it cost us. I cannot tell you what it costs on average. Nobody actually knows. We're all just comparing scars at conferences.

Now everyone's talking about AI agents replacing RPA. Does agent adaptability change the maintenance curve?

Nora: [long pause]

I want to believe it does. I really do. The structural argument is real. Agents can handle UI changes without breaking. They can process unstructured documents. They're not locked to pixel coordinates. The primary RPA failure modes, brittle selectors, variable document formats, high exception rates, agents address those architecturally.

But here's what keeps me up at night. RPA failures are classifiable. Selector moved. Credential expired. Field absent. They repeat. You fix one, you prevent a hundred recurrences. You can amortize the pain.

Agent failures might be fundamentally different. Less repetitive. Harder to amortize. The exception queue doesn't get shorter, it gets weirder. I've started calling it exception entropy: the failures become more varied and less predictable even as they become less frequent.⁶ You can't build a playbook for failures that never repeat.

And the governance side?

Nora: It doesn't shrink. It might grow. Credential management for agents is potentially more complex. NIST just published on the confused-deputy problem, where an agent runtime holds multiple users' credentials and chooses among them based on context.⁷ Think about that from an audit perspective. Decommissioning gets harder when the agent can plan around failures, because now you're not just revoking access, you're unwinding learned behaviors. Audit logs record the machine's journey but may not assemble a defensible case for who's responsible.

So your position is that agents are just RPA with better marketing?

Nora: No. My position is that better inference doesn't eliminate the knowledge engineering. It moves the work. Into policies, constraints, evaluation cases, prompt maintenance, connector schemas, the boundary between autonomous action and escalation.⁸ That's real work. It's different work. And it might even be better work, more interesting, closer to the actual problem.

But the vendor slide that shows maintenance costs dropping by forty percent? I've seen that slide before. I saw it in 2018. About RPA.

What would convince you?

Nora: Three years of production data from an enterprise that transitioned from RPA to agents, with honest accounting of exception handling labor, governance overhead, and decommissioning costs. Not a pilot. Not a case study from the vendor's website. A program that scaled past the point where it stopped being fun and kept going anyway.

Has anyone shown you that data?

Nora: No. I'll let you know.

Footnotes

1. Industry analyses document cases where application UI updates caused immediate, widespread bot failure across enterprise deployments. Gartner's 2025 automation research estimated 30–40% of maintenance hours address breakage-related repairs. (Cited via Shogo AI; treat as secondary source for the Gartner figure.) ↩

2. GSA Office of Inspector General, "GSA Should Strengthen the Security of Its Robotic Process Automation Program," August 6, 2024. https://www.gsaig.gov/content/gsa-should-strengthen-security-its-robotic-process-automation-program ↩

3. Kokina, Julia, Christian Langmann, and Michael Weiser, "Navigating the RPA Governance Landscape: Evidence from the Field," International Journal of Accounting Information Systems 57 (December 2026): 100784. Participant 9-P-9 described shutting down attended automation after concluding governance costs exceeded efficiency gains. ↩

4. Kokina et al. (2026). The study documented governance structures across 16 large organizations, including one with 1,350 unattended bots overseen by a board of division CIOs. ↩ ↩²

5. Khantong and Sriboonlue, "Systematic review of 83 peer-reviewed RPA and business-process studies," Technologies 14(4):225, 2026. https://doi.org/10.3390/technologies14040225 ↩

6. The concept of "exception entropy," agent failures becoming more varied and less predictable even as they decrease in frequency, is drawn from panel discussion synthesis in TinyFish internal research. ↩

7. NIST, "Back to the Future: Why Agentic AI Needs a Strong Identity Foundation," August 27, 2026. https://www.nist.gov/blogs/cybersecurity-insights/back-future-why-agentic-ai-needs-strong-identity-foundation ↩

8. This framing draws on analysis of XCON's maintenance trajectory at Digital Equipment Corporation, where expert-system rule maintenance grew to consume the system's operational value. See Soloway, Bachant, and Jensen, "Assessing the Maintainability of XCON-in-RIME," AAAI, 1987. ↩