Modernize the Automation You Already Have

Start with the outcome, then inspect the estate

Choose one important outcome and trace the work from its initiating event to confirmed completion. Include the people who handle exceptions. Their spreadsheets, reconciliations and informal checks often reveal responsibilities missing from the formal inventory.

Agree what counts as an accepted outcome, who can accept it, and the follow-up needed to detect rework. A successful bot run is evidence about a technical step. It does not establish that the employee, customer or receiving team obtained the required result.

This is an application of the existing From Automation to Autonomy perspective to assets already in service. The progression model helps leaders choose an appropriate operating ambition. This review identifies what to preserve and what must change to support it. The Digital Operating Model remains the reference for changes that must happen together across the operation.

Build one evidence record per material capability, linked to the outcome it supports. Use service records, incident history, representative cases, dependency checks and observed human effort. Mark gaps as unknown; an unrecorded failure rate is not evidence of reliability.

Review area	Evidence that should influence the decision
Business value	The accepted outcome, eligible demand, current service level and consequence of failure. Identify whether the automated step is still necessary and where it affects the end-to-end result.
Reliability	Successful outcomes, failed and repeated attempts, silent errors, recovery time and behavior during peak demand or system change. Reconcile execution logs with downstream records.
Exception load	Exception types, frequency, handling effort, queue age and repeat work. Separate legitimate business exceptions from defects created by the automation.
Ownership	A named Outcome owner, Operating owner and Technology owner, with authority, support coverage and funding. Establish knowledge and control responsibilities where relevant.
Dependencies	Upstream data, authoritative records, interfaces, credentials, schedules and downstream consumers. Record shared dependencies, versions and announced support changes.
Controls	Permitted actions, approval conditions, access, traceable decisions, reconciliation and tested intervention. Establish who accepts an unresolved handoff.
Lifecycle cost	Recurring licenses, infrastructure, support, review, correction and recovery; separately, one-time migration, testing, transition and retirement investment. Include credible vendor or platform exit costs.

A low-volume capability may be essential at a critical deadline. A heavily used one may automate work that should disappear. Use the evidence to explain the consequence of each choice; an average score can conceal a dependency or control failure that makes the proposal unacceptable.

Choose the engineering action for the actual weakness

The choices below describe changes to the estate. They can be sequenced: retain a useful business rule, stabilize its execution, then expose a narrower capability through an interface. Record the affected asset and version, the reason, prerequisites, acceptance evidence, accountable owner and review date.

Engineering choice	When it fits	Evidence required before acceptance
Retain	Necessary work, dependable execution and sustainable ownership and cost.	Verified outcome contribution, supported dependencies, funded operation and an explicit next review.
Stabilize	The capability remains useful, but defects, monitoring gaps or unsupported exceptions undermine it.	Reproduced failures addressed; exception routing, alerting, recovery and support tested under representative conditions.
Retire	The work is unnecessary, duplicated, superseded or no longer worth sustaining.	Consumers and obligations checked; replacement or cessation accepted; scheduled jobs, access and spend removed through a verified retirement plan.
Rebuild	A material constraint cannot be economically corrected within the current design.	Alternatives compared; supported replacement tested; dependencies migrated and cutover, reconciliation and recovery rehearsed.
Expose through a controlled agent interface	An agent has a justified need to invoke an existing capability within explicit limits.	Narrow actions, enforceable permissions, valid inputs, duplicate prevention, verified results and staffed recovery; incremental value demonstrated against a simpler alternative.

Sunk build cost does not establish future value. Equally, a new platform's availability does not establish a case for replacement. Compare the future cost and consequences of the credible options, including leaving a reliable capability in place.

Sequence decisions around shared dependencies. If several automations rely on one failing interface, repairing that interface may be the first investment. Retiring an apparently redundant script requires checking whether another team relies on its output as an unofficial control.

Give AI a specific job and test the simpler alternative

Rules-Based Automation remains appropriate when conditions, permitted actions and exceptions can be specified and tested. A fixed workflow may also include AI assistance for a bounded task, such as extracting information from an unstructured request, while keeping the sequence and approval logic explicit.

An agent becomes a candidate when useful work requires selecting among permitted actions in response to changing context. That added discretion must solve a material problem. If a fixed route with a few explicit branches achieves the same outcome at lower operating cost and effort, retain that design.

Anthropic's Building effective agents distinguishes predefined workflows from agents that dynamically direct their processes and tool use, and recommends starting with simpler solutions. This is engineering guidance from a model provider, not evidence of a return for your operation.

My recommendation is to compare three candidates against the same cases: improved conventional automation, AI assistance with a person deciding, and bounded agent action. Measure accepted outcomes, service performance, exception effort and recurring cost. Do not attribute the benefit of repairing the underlying operation to an agent introduced at the same time.

Keep information access separate from permission to act. Within the workflow, specify Recommend where a person decides; Act for named actions while their conditions hold; Escalate where the affected action is withheld and routed to a person; and Never Delegate for decisions reserved to people. These are authority arrangements, not steps every capability should climb.

Make the surrounding operation ready for an agent

A controlled agent interface is a narrow, supported connection through which an agent can request defined actions. Putting an interface in front of a bot does not establish that the resulting operation is controlled. The service behind it must be able to reject an unauthorized request and explain what actually happened.

Before granting action authority, require the Technology owner and Operating owner to demonstrate the following:

• Authoritative state. Identify the system of record—the source treated as authoritative for the transaction—and the current policy and case information required before action. The Knowledge owner must maintain the sources used for interpretation.
• Enforced boundaries. Expose named actions with defined inputs, eligibility checks and permissions. Enforce limits in the service and identity controls, outside the model's instructions. Reading a request or document must not confer permission to obey instructions embedded in it.
• Known execution results. Give requests identifiers, check inputs and distinguish accepted, in progress, completed, failed and unknown outcomes. Verify completion in the authoritative record. Where retries are possible, use idempotent operations: repeating the same request must not repeat its business effect.
• Manageable demand. Bound concurrent work, retry attempts, elapsed time and consumption. Demonstrate that exception volume fits the receiving team's capacity, including peak periods and staff absence.
• Usable intervention. Log requests, decisions and results with the context needed to investigate them. Test how people pause the affected route, resolve uncertain outcomes and restore service. Use rollback where effects can be reversed, or an approved corrective action where they cannot.

AWS's guidance on idempotent APIs explains why request identifiers and consistent handling of repeated requests matter when a caller cannot tell whether an action completed. For this review, the practical implication is that a timeout must not trigger an unchecked repeat of a consequential action.

Test the combined operation, including the people receiving exceptions. NIST's Generative Artificial Intelligence Profile, particularly MP-3.4-005 and MP-3.4-006, addresses human–AI performance and testing with operators and end users. It is voluntary risk guidance; a checklist against it is not certification that a service is ready.

Unclear ownership, poor records or an unstaffed exception queue are reasons to fund operating repairs before delegating more work. The Bounded Autonomy framework provides the fuller treatment of authority boundaries; this estate review asks whether the existing capability and its support can enforce them.

A worked example: employee onboarding

Hypothetical illustration. The organization, operating conditions and choices below are assumptions for explanation, not reported experience or measured results.

Suppose onboarding spans HR, IT and facilities. An approval workflow starts the process, an RPA bot enters details in a legacy application, an integration creates service requests, and a reconciliation script produces a daily exception spreadsheet. The sponsor wants to add an agent to coordinate the work.

First define the outcome. In this scenario, a standard onboarding case is accepted when the authoritative employment record is valid, required approvals are recorded, the agreed equipment and standard access are available by the start date, and the designated receiving lead confirms readiness after the agreed follow-up. Restricted cases follow a separate route. This is a local acceptance definition, not a universal onboarding policy.

Reviewing the cases suggests five different actions:

• Retain the approval workflow. Its routing and decision records are dependable. Replacing it would not address the observed delays.
• Stabilize the RPA bot. An application change causes intermittent failures. Add monitored recovery and clear exception ownership before increasing demand on it.
• Retire the reconciliation script. Assume its necessary checks have been transferred to a supported service and validated with the receiving team. Confirm that no downstream consumer depends on the old spreadsheet before removing it.
• Rebuild the fragile request interface. Replace ambiguous responses with a supported interface that exposes request status and prevents duplicate requests. Validate cutover and reconciliation.
• Test a controlled agent connection. Let a candidate agent inspect approved case status, recommend a next step and, only for eligible cases, create a standard service request through that interface.

AI assistance could help interpret an ambiguous manager request, with a person confirming the interpretation. Agent action earns a separate trial only if responding to different case states adds value beyond fixed routing. In this scenario, policy exceptions and privileged-access decisions remain with people under Never Delegate. Missing approval or conflicting employment data triggers Escalate before the affected request is submitted.

Consider a timeout after a service request is sent. The operator checks the request identifier against the authoritative service record before allowing a retry. If the result remains unknown, the route pauses and an authorized person resolves it. A second ticket is not evidence of recovery.

The test compares onboarding readiness, late or incomplete cases, repeat requests and total human effort. It also tests peak intake and the absence of a usual support person. Better completion logs alone cannot justify expanding the agent's authority.

Sequence the work through evidence gates

Start with a coherent outcome and a manageable set of dependencies. Set thresholds from service commitments, consequences and the observed workload before testing. A phase ends when its evidence supports the next commitment; a calendar deadline cannot substitute for that evidence.

Phase	Acceptance evidence and review	Pause or stop condition
Establish the baseline	The Outcome owner accepts the outcome definition, scope and representative baseline. The Operating owner confirms exception effort and ownership; the Technology owner maps dependencies.	Do not commit to expansion while a material dependency, acceptance criterion or accountable owner remains unknown.
Stabilize and retire selectively	The Operating and Technology owners verify repairs, supported operation and safe removal of obsolete work. The Outcome owner confirms that service and necessary controls are preserved.	Pause the affected change if reconciliation fails, a necessary consumer is unaccounted for or service falls outside agreed limits.
Test alternatives	Compare conventional automation, assistance and any agent candidate on representative cases. The Control lead coordinates evidence of limits and intervention; the Outcome owner reviews value and risk within their mandate.	Withhold action authority if prohibited actions, duplicate effects, uncertain outcomes or unmanageable exceptions remain unresolved.
Run a limited operation	Approve eligible cases, volume, actions, support coverage, budget and review date. Reconcile outcomes and costs through the follow-up period; rehearse recovery with the receiving team.	Pause the affected route on unauthorized action, unknown transaction state or exception demand beyond available capacity. Invoke the agreed recovery plan.
Review the next commitment	The Outcome owner brings results, costs and control evidence to the authorized decision makers. Record the decision, affected scope, rationale and next review trigger.	Do not expand on insufficient or unrepresentative evidence. Escalate commitments beyond the team's mandate to the Sponsor.

At the review, use the canonical decisions precisely: Expand a specified scope or authority; Continue within the approved boundary; Narrow that scope or authority; Redesign the work; or Stop the named capability or route. Record what changes. An engineering decision to rebuild an interface might support Redesign of the work, while retaining its existing approval workflow.

A pause, repair or rollback is an operational response. It does not automatically mean Stop at the investment review. Conversely, restoring technical service does not automatically justify resuming an agent's previous authority. Require explicit evidence and authorization for that resumption.

Make the economics comparable

Use Cost per accepted outcome consistently: recurring in-scope operating cost divided by outcomes meeting owner-approved acceptance criteria for the same defined scope or cohort and accounting window, after the agreed follow-up. Include failed and repeated attempts, review, correction, support and recovery in the numerator. Keep denominator units and case complexity comparable. With zero accepted outcomes, the measure is not calculable.

For the hypothetical onboarding example, suppose a defined monthly cohort incurs $12,000 of recurring operating cost and produces 80 accepted standard onboarding outcomes after follow-up. Cost per accepted outcome is $150. The $12,000 includes work on cases in that scope that fail acceptance. A separate $30,000 implementation investment stays outside this recurring measure and remains in the investment appraisal. All figures are illustrative assumptions.

If a trial serves only straightforward cases, compare it with the equivalent baseline cohort and retain a view of the whole operation. Otherwise, a better unit result may simply reflect difficult work being left elsewhere. Allocate shared operating costs consistently and count them once in the portfolio total.

Assess recurring economics alongside one-time investment, transition risk, benefits and their timing. Time released becomes usable capacity only when the operation can deploy it; cash savings require an actual reduction in expenditure. The business-case playbook develops that investment logic. For the wider dependency question, use the Enterprise integration topic.