The most dangerous AI agent is not the one that fails in a demonstration. It is the one that works well enough to be trusted inside a badly designed process.

That distinction matters because AI agents do more than produce content or answer questions. Within defined limits, they can interpret a goal, plan several steps, use business systems, make choices and take action. A conventional assistant may draft a supplier email. An agent may identify the supplier, retrieve the contract, decide which issue applies, update the purchasing system, send the message and schedule the next action.

The productivity potential is clear. So is the exposure.

If the workflow contains unclear rules, poor data, informal workarounds or disputed ownership, an agent can reproduce those weaknesses at greater speed and volume. What looked like automation becomes a faster route to exceptions, corrections and senior escalation.

Before approving an agent, leadership teams should test the workflow, not just the technology. The AI Agent Workflow Readiness Test examines six conditions: outcome value, workflow clarity, information readiness, authority design, exception control and operating adoption. Together, they support one of four decisions: stop, repair, pilot or scale.

Start with a workflow, not an AI use case

The phrase "AI use case" can encourage the wrong starting point. Teams often begin with a tool capability and then search for somewhere to apply it. The resulting ideas sound plausible but remain detached from the economics and operating reality of the business.

A better unit of analysis is the end-to-end workflow.

Consider customer onboarding. The work may cross sales, finance, compliance, operations and customer success. It may require information from several systems, judgements about commercial terms, checks against policy, communication with the customer and escalation when evidence is missing. Automating one task within that chain may save minutes while leaving the overall cycle time unchanged.

The leadership team should therefore name the workflow in outcome terms. Not "use an agent for onboarding", but "move an approved customer from signed contract to first value within five working days, with complete checks and no avoidable rework".

That formulation exposes three things immediately:

  • the business outcome;
  • the boundary of the workflow; and
  • the measures that determine whether the change worked.

It also stops the team confusing a technically impressive interaction with a commercially worthwhile operating change.

Test 1: Is the outcome valuable enough?

Agent projects can accumulate small efficiencies that never reach the profit and loss account, customer experience or capacity plan. Saving four minutes on a task is not automatically valuable. The saving must occur often enough, reduce a real constraint and be recoverable in practice.

Define the baseline before discussing vendors or models:

  • How many cases enter the workflow each week or month?
  • How much employee and management time does one case consume?
  • What is the current cycle time, error rate and rework rate?
  • Which delays affect revenue, cash, service or risk?
  • Where is scarce expertise being used for routine handling rather than judgement?
  • If time is released, what will the business do with that capacity?

The last question is frequently missed. A nominal time saving has limited economic value if it is dispersed across many people and cannot be converted into additional output, avoided hiring, faster revenue or better service.

Build the value case around a small number of observable outcomes. Depending on the workflow, these might include reduced handling cost, shorter time to revenue, fewer avoidable contacts, improved first-time-right performance, lower working capital or more cases handled without increasing headcount.

Include the full cost of change. Licence fees and development are only part of it. Data clean-up, integration, process design, testing, employee training, control monitoring, vendor management and exception handling all consume resources.

Leadership test: If the agent performs as intended, which business measure changes, by how much, and where will that value appear?

If the team cannot answer, stop. A weak value case does not become stronger because the technology is new.

Test 2: Is the workflow clear enough to redesign?

An agent needs more than a procedure document. It needs a coherent operating path.

Map how work actually moves from trigger to outcome. Include every handoff, system, decision, queue, approval, exception and customer interaction. Compare the official process with the route used by experienced employees when the official one breaks down.

This often reveals that the apparent workflow is several different workflows sharing a name. A straightforward order may follow six predictable steps. A non-standard order may depend on product knowledge, customer history, credit judgement and a series of private messages. Treating both as one automation target creates false confidence.

For each step, classify the work:

  1. Remove: The step exists because of legacy duplication, unnecessary approval or avoidable rekeying.
  2. Simplify: The purpose is valid, but the rule or handoff is more complex than necessary.
  3. Automate: The step is repeatable, sufficiently defined and supported by reliable information.
  4. Augment: A person should decide, but an agent can gather evidence, propose options or complete administration.
  5. Retain with people: The work depends on negotiation, empathy, material judgement or accountability that should remain human.

Do not encode a poor process simply because it is documented. Remove and simplify first. Otherwise, the business pays to make waste run faster.

A useful readiness indicator is variation. If experienced people handle similar cases in materially different ways, determine whether that reflects legitimate judgement or uncontrolled inconsistency. Legitimate judgement needs explicit decision criteria and an escalation route. Inconsistency needs process repair.

Leadership test: Can the team describe the current workflow, its variants and its failure points without relying on one expert's memory?

If not, repair the process before building the agent.

Test 3: Is the information reliable and accessible?

Agents act on the information available to them, not on what leaders assume exists.

The workflow may depend on customer records, contracts, policies, inventory, pricing, case histories or emails. If those sources conflict, are incomplete or lack clear ownership, the agent must either guess, stop frequently or produce confident but unreliable actions.

Review information readiness at the field and decision level:

  • What information is required at each step?
  • Which system is authoritative for each item?
  • How complete, current and consistent is it?
  • Can the agent retrieve it with appropriate permissions?
  • Can the source and version used for a decision be recorded?
  • What happens when two sources disagree?
  • Who owns correction of the underlying data?

Do not average away critical weaknesses. A customer-service workflow may have 98 per cent complete contact data and still fail because entitlement status, the field that determines what action is permitted, is unreliable.

Test with real cases, including awkward ones. Use incomplete requests, duplicated records, unusual contracts, historic customers and cases that crossed system boundaries. A clean demonstration data set proves very little about production readiness.

Information access also needs proportionality. An agent should receive the minimum access required to complete its role. Broad permissions make prototyping easier but increase the consequences of an error or compromise. Read access, recommendation rights and transaction rights should be separated wherever practical.

Leadership test: Can the business identify the authoritative information for every material decision and show how errors will be detected and corrected?

If not, repair the data and integration foundations before granting the agent operational authority.

Test 4: Is the agent's authority explicit?

The central governance question is not whether a human is "in the loop". It is what the agent may decide, what it may do and when a person must intervene.

Define authority across four levels:

Most pilots should begin at a lower authority level than the final ambition. This allows the business to compare agent recommendations with human decisions, identify failure patterns and refine the rules before actions become automatic.

For each decision, specify:

  • the goal the agent is optimising;
  • the inputs it may use;
  • the actions it may take;
  • financial, commercial and risk limits;
  • prohibited actions;
  • cases requiring approval;
  • the accountable human owner; and
  • the record that must be retained.

Avoid broad instructions such as "resolve the customer issue" or "optimise the order". They hide competing objectives. A resolution that minimises cost may damage retention. An order that maximises availability may create excessive stock. Leaders must choose the trade-offs rather than leaving them inside a prompt or vendor configuration.

Accountability cannot be delegated to software. A named process owner should remain responsible for the outcome, policy and performance of the workflow. Technology may operate the mechanism, but management owns the consequences.

Leadership test: Could a frontline manager explain, in plain English, the exact boundary between agent authority and human authority?

If not, do not move beyond recommendation mode.

Test 5: Are exceptions and failure modes controlled?

The normal path rarely determines whether an agent is safe to scale. Exceptions do.

List the ways the workflow can depart from plan. Include missing evidence, policy conflicts, system outages, unusual customer behaviour, low-confidence outputs, duplicate actions, suspected fraud, sensitive personal data and outcomes with material financial or reputational consequences.

For each exception, decide:

  • how it will be detected;
  • whether the agent should pause, retry, reverse or escalate;
  • who receives the case;
  • what context that person receives;
  • the required response time;
  • whether the action can be undone; and
  • how the event will improve future controls.

The quality of escalation matters as much as the decision to escalate. An agent that sends a vague alert without evidence may save no time. The human recipient needs the case summary, relevant sources, actions already attempted, the reason for escalation and the decision required.

Set a lower tolerance for irreversible or high-consequence actions. Sending an internal reminder is different from changing a price, releasing a payment, rejecting an applicant or communicating a contractual position. Where the downside is material, design approval, transaction limits, dual control or a human decision into the workflow.

Monitor leading indicators, not just visible failures. These can include falling confidence, rising escalation volume, repeated overrides, growing queues, unusual transaction patterns and differences in outcomes between customer groups.

Leadership test: When the agent is wrong, how quickly will the business know, how much can happen before intervention, and can the action be reversed?

If those answers are uncomfortable, narrow the scope or reduce the level of authority.

Test 6: Is the organisation ready to adopt and improve the new workflow?

A technically capable agent can still fail because the surrounding operating model remains unchanged.

People need to understand what the system does, what remains their responsibility and how their role will change. Managers need measures that reward the new outcome rather than the old activity. Process owners need time and authority to review performance. Technology teams need an operating route for incidents, updates and access changes.

Define the future workflow before training begins:

  • Which tasks disappear, shrink or move?
  • Which judgements remain with people?
  • Who supervises agent performance?
  • Who maintains instructions, rules and integrations?
  • How will employees challenge an output or report a failure?
  • Which measures will confirm adoption and value?
  • What happens to released capacity?

Frontline involvement is essential. Employees often know where cases break, which data cannot be trusted and which informal actions keep customers moving. Involve them in mapping, testing and exception design. This is not simply a change-management courtesy. It improves the quality of the operating design.

Be candid about role impact. If the business intends to avoid hiring, redistribute work or reduce positions, leaders should address it directly. Vague assurances damage trust and encourage quiet resistance. Clear choices, transition support and meaningful involvement create a stronger basis for adoption.

The workflow also needs an improvement cadence. Agent performance will change as volumes, customer behaviour, policies, source systems and models change. Treat go-live as the start of operational management, not the end of a technology project.

Leadership test: Is there a named owner, a trained user group, an operating support route and an agreed plan for the capacity released?

If not, the pilot may run, but the change will not stick.

Score the workflow before committing to build

Score each test from 1 to 5.

Do not rely on the total alone. Any score of 1 in authority design or exception control should block an autonomous pilot. Any score below 3 in outcome value should trigger a stop or fundamental rethink, regardless of the technology's capability.

As a broad interpretation:

  • 6 to 11: Stop. The case is not ready and may not be worth pursuing.
  • 12 to 17: Repair. Fix the workflow, data, controls or ownership before building.
  • 18 to 23: Pilot. Run a bounded test with limited authority and explicit success criteria.
  • 24 to 30: Prepare to scale. Confirm production controls, adoption and economics through live evidence before expanding.

Treat disagreement as useful information. If operations scores workflow clarity at 4 and frontline users score it at 2, investigate the gap rather than averaging it away.

Design a pilot that can answer a decision

A pilot should not merely prove that the agent can complete a task. It should provide evidence for a management decision.

Choose a boundary that is commercially meaningful but operationally contained. One customer segment, product line, transaction type or internal team may be appropriate. Avoid a pilot so clean that it excludes every real source of difficulty.

Set measures in five groups:

  1. Value: handling cost, capacity released, time to revenue or avoided external spend.
  2. Service: cycle time, response time, first-time-right rate and customer outcome.
  3. Quality: accuracy, completeness, rework and human override rate.
  4. Control: prohibited actions, policy breaches, access incidents and audit completeness.
  5. Adoption: appropriate usage, workarounds, user confidence and escalation quality.

Establish the baseline using the current workflow. Then define the decision thresholds before the pilot starts. For example, scale only if cycle time falls by at least 30 per cent, first-time-right performance remains above the agreed level, no critical control failure occurs, and the fully loaded cost per completed case improves.

Review exceptions weekly. Examine not only how many occurred, but why. A high escalation rate may indicate prudent control during early testing. It may also show that the chosen workflow is too variable or that the agent lacks the information required to act.

Keep a manual fallback. The business should be able to pause the agent, recover open cases and continue critical work if a system or control fails.

Five warning signs that the project is moving too quickly

Pause if any of these statements sound familiar:

  1. "The vendor will show us the best process." A vendor can bring patterns and technical expertise, but leadership must define the outcome, trade-offs and accountability.
  2. "We will clean the data after the pilot." Real workflow performance cannot be assessed using information conditions that will not exist in production.
  3. "A person can step in if anything goes wrong." Unless triggers, owners and response times are explicit, this is reassurance rather than control.
  4. "We do not need to change roles because the agent only helps people." If tasks, decisions or capacity change, the operating model changes too.
  5. "We will work out the return once adoption grows." Without a baseline and value path, scale can increase usage while economics remain invisible.

These warnings do not mean the opportunity should be abandoned. They mean the next investment should be in clarity rather than code.

The leadership questions that matter

Before approving an AI agent for a live workflow, ask:

  1. What end-to-end outcome are we improving?
  2. Which steps should be removed or simplified before automation?
  3. Which information source is authoritative for each material decision?
  4. What may the agent decide and do without approval?
  5. Which exceptions must stop or redirect the workflow?
  6. Who remains accountable for the result?
  7. What evidence will support the decision to stop, repair, pilot or scale?

If the answers are specific, testable and owned, the business has the basis for a serious pilot. If they remain broad, investment in the agent is premature.

Readiness is a business design question

The leadership choice is not between moving quickly and being responsible. A well-designed readiness review supports both.

It prevents time being spent on workflows with weak economics. It exposes process and data problems before they become expensive rework. It allows authority to expand in proportion to evidence. It gives employees a credible role in designing how work will change.

Most importantly, it keeps the business outcome ahead of the technology.

Allington Advisors helps leadership teams identify high-value AI opportunities, redesign the work around them and establish the controls, measures and ownership required for implementation. A focused AI Agent Workflow Review can test one critical process and provide a clear recommendation to stop, repair, pilot or scale.