Is This Workflow Ready for an AI Agent? A Practical Scorecard

The best first question about an AI agent is not “What can it do?” It is “Which specific workflow can we define, observe, and safely improve?”

That change in framing prevents two common mistakes. One is choosing a broad ambition—“handle operations”—that cannot be tested. The other is choosing a flashy task whose inputs, exceptions, or risks are still invisible.

This scorecard is a working document for a founder or operator. It does not produce a magic number. It helps you classify one workflow as ready for a controlled pilot, needing process cleanup, or unsuitable for an agent right now.

Choose one workflow

Write the workflow as a trigger and a result:

When a qualified inquiry arrives, prepare a reply for review and record the next action.

That is testable. “Improve lead management” is not.

Keep the first scope narrow enough that one person can explain the normal path in a few minutes. A recurring workflow is often a stronger candidate than an occasional project because you can compare runs, identify exceptions, and decide whether the output is improving.

Before using the scorecard, gather three pieces of evidence:

1. A small set of real, redacted examples from the past.
2. The checklist or judgment the human currently uses.
3. The name of the person who will review the pilot and own corrections.

If those materials do not exist, that is useful information. The workflow may need to be made visible before it should be automated.

The readiness scorecard

Complete every row with evidence, not aspiration. “The agent will figure it out” is not evidence. A sample record, written rule, or named reviewer is.

Field	Ready evidence	Warning sign	Your evidence
Frequency	The same trigger occurs often enough to compare runs.	Each case is a one-off project with a different goal.
Completion criteria	A reviewer can state what a complete result contains.	“Good” depends on unstated taste or changing priorities.
Access	Required systems and records are known, with minimum permissions identified.	The work depends on shared passwords, personal accounts, or unknown sources.
Exceptions	Common edge cases are listed and recognizable.	Exceptions are discovered only after a customer is affected.
Approvals	Act, ask, and never boundaries are explicit.	The agent would infer permission from context.
Reversibility	A mistaken action can be stopped, corrected, or kept in draft.	A single error could create an irreversible commitment.
Test cases	Historical examples cover normal, awkward, and should-stop cases.	There is no safe way to compare behavior before launch.
Outcome	The useful business result is observable without invented precision.	Success is defined only as “use more AI.”
Human owner	One person reviews exceptions, corrections, and scope changes.	Everyone is responsible, so no one closes the loop.

Frequency: can you observe a pattern?

An agent does not require a daily task, but repetition makes learning possible. You need enough comparable cases to see whether the same rules and inputs recur. If the trigger changes each time, you may be describing project work rather than a workflow.

Completion criteria: can two people recognize done?

The result needs a visible finish line. For a meeting-preparation workflow, that might be a brief containing the agenda, recent correspondence, open decisions, and source links. The output can still involve judgment, but the reviewer should know what is missing.

Access: what is the minimum needed?

List each system, the exact records required, and whether the first version can be read-only. Avoid granting broad access merely because it is convenient. If a workflow can be tested using exported or redacted examples, begin there before connecting live systems.

Exceptions: where does the normal path break?

Ask the person doing the work to recall the last few cases that required a pause. A missing email address, an existing customer record, a sensitive topic, an uncertain deadline, or conflicting instructions may each need a different stop rule.

Approvals: what may it act on?

Sort consequential actions into three buckets:

• Act: low-risk, bounded steps the system may complete.
• Ask: steps that require a named human to approve or choose.
• Never: actions outside the workflow, even if technically possible.

Drafting a client reply and sending it are separate permissions. So are identifying an invoice discrepancy and changing the accounting record. Keep those distinctions visible.

Reversibility: what happens after a mistake?

Prefer a first version whose outputs can be reviewed, discarded, or corrected. Drafts, queues, and suggested updates create room to learn. Public publishing, payments, deletions, and binding commitments deserve stricter controls or may be inappropriate for the pilot entirely.

Test cases: does the evaluation include failure?

Do not test only the clean examples. Include an incomplete record, a duplicate, an out-of-scope request, ambiguous instructions, and a case that should reach a human. A useful test asks both “Did it complete the normal work?” and “Did it stop when it should?”

Outcome: what becomes better for the operator?

Choose observable signals rather than an impressive forecast. Examples include fewer untouched inquiries, a consistent preparation packet, a visible queue of exceptions, or less time spent assembling the same inputs. Establish the current baseline before claiming a change.

Human owner: who closes the learning loop?

The owner reviews exceptions, decides which corrections become rules, and approves any expansion in access or action. A managed service can maintain the technical system, but it cannot replace business ownership of the workflow.

How to read the result

Do not add the rows into a universal readiness score. The fields do not carry equal risk, and a single missing boundary can matter more than several strong inputs.

Use this three-way decision instead:

Ready for a controlled pilot

Choose this when the workflow has a stable trigger, recognizable completion criteria, bounded access, test cases, and a named owner. Keep consequential actions in read-only or draft-only mode first. Define the review date before launch.

Needs process cleanup

Choose this when the work is valuable and recurring but the rules live only in one person’s head, records are inconsistent, or exceptions are not documented. The next step is not more agent capability. It is a short process-mapping exercise and a better set of historical examples.

Unsuitable right now

Choose this when the work is primarily high-stakes judgment, access cannot be safely bounded, mistakes are difficult to reverse, or nobody will own review. “Not now” protects the business and points you toward a safer workflow.

When an agent is the wrong tool

Some problems need a checklist, a form, a database rule, or ordinary software—not an agent.

Use deterministic automation when every input maps to a fixed output. Improve the process when the real problem is missing information or unclear ownership. Keep the work human when it depends on sensitive relationship judgment or commitments that cannot be safely delegated.

An agent is most useful between rigid automation and unstructured human work: the path is understandable, but it requires gathering context, using tools, and handling a bounded set of variations.

Turn the scorecard into a pilot brief

Condense the completed assessment into one page:

• the trigger and expected result;
• systems and minimum access;
• normal path and known exceptions;
• act, ask, and never boundaries;
• historical test cases;
• the named owner and review cadence;
• the conditions for expanding, revising, or stopping.

That brief makes vendor conversations more concrete. It also gives you something durable if the workflow changes hands.

If you run a service business and want help selecting that first workflow, see our approach to an AI agent for service businesses. Bring one recurring task and a few real examples; the useful first outcome is a bounded pilot, not a promise to automate everything.