How to Identify Processes
Ready for Agentic
Automation
The process identification question is where most agentic AI programs go wrong first. Not every process that feels like an agent candidate actually is one — and building an agent for the wrong process is the most common cause of the pilot-to-production gap.
Why Most Organizations Start
with the Wrong Process
When asked to identify agentic AI candidates, most teams surface the same type of process: the most painful, most time-consuming, most visible problem in the organization. That is a reasonable starting point — high-pain processes are worth automating. But pain is not a sufficient criterion for agentic automation. A process can be genuinely painful and still be a poor agent candidate because the data is inaccessible, the decisions require judgment the model cannot reliably produce, or the governance requirements exceed what the organization can realistically implement for that process type.
The other common selection failure is anchoring on what seems technically impressive rather than what produces a defensible return. Processes that make compelling demos — document summarization, email drafting, research synthesis — are often selected for early agent builds because the output is visible and easy to evaluate. But their volume may be too low to justify the build cost, their quality requirements may be too high for reliable autonomous operation, or they may already be well-served by a copilot that requires a fraction of the governance investment.
A structured identification process evaluates every candidate process against five criteria before any process is selected for a build investment. The five criteria are not a prioritization framework — they are pass/fail gates. A process that fails any one of them is not a production-ready agent candidate, regardless of how compelling it looks on the other four.
The Tests Every Candidate Process
Must Pass Before Build Investment Is Made
These five criteria map directly to the five failure modes of agent deployments that were built for the wrong process. A process that passes all five is a strong candidate. A process that fails one should be either remediated or deprioritized in favour of a stronger candidate.
Goal Clarity
The process has a clear, definable objective that the agent can evaluate its progress toward. Success is not ambiguous. The output is not "better than before" — it is a specific, verifiable deliverable that can be assessed against defined criteria. Processes where the definition of success depends on stakeholder judgment that varies by instance, changes based on context that cannot be specified in advance, or requires relationship knowledge that is not in any data system are poor candidates for autonomous operation regardless of their other characteristics.
Goal clarity does not mean the process is simple. It means the complexity is bounded — the agent knows when it has completed the task. A contract review agent has goal clarity: it extracts defined clause types, compares against a template, flags defined deviations, and produces a structured exception report. The goal is clear. The process is complex. Both can be true simultaneously.
Process has a documented completion state. "Extract all non-standard indemnity clauses and compare against standard template" has a clear endpoint. "Improve the quality of our customer communications" does not.
Success is evaluated differently by different stakeholders, changes based on relationship context, or requires "knowing what good looks like" without being able to specify what good looks like.
Data Accessibility
The data the agent needs to complete the process is accessible through API, structured query, or document retrieval without specialist access credentials, without manual data extraction, and at the latency the process requires. Data accessibility is the criterion most consistently underestimated during process selection — because the data appears to exist in the organization's systems, which makes it feel accessible. The gap between data existing and data being accessible to an agent is often measured in months of integration work.
Data accessibility assessment covers four dimensions: source system API availability (does the system have an API, is it documented, does it return the required data in a usable format), data quality and completeness against process requirements (is the data that exists actually sufficient for the reasoning the agent needs to do), latency requirements (does the process need real-time data or is batch retrieval acceptable), and sensitivity classification (does the data contain information that creates governance requirements that complicate or preclude automated access).
Data available through a documented API or queryable data store, with sufficient quality and completeness, within the latency the process requires, without data governance obstacles to automated access.
Key data lives in a legacy system without an API, in spreadsheets maintained by individuals, in email threads, or in systems where automated access requires approvals that have not been obtained and may not be grantable.
Decision Complexity
The decisions the process requires are within the reliable capability of current large language models — or can be made reliably with the specific model and tool configuration the agent will use, validated against a representative sample of real process instances. Decision complexity is the criterion that is most often misassessed in both directions: teams assume models cannot handle complex professional judgment in domains where current models are actually quite capable, and they assume models can handle decisions that require lived experience, regulatory authority, or interpersonal judgment that models consistently fail on.
The test for decision complexity is empirical, not theoretical. Before committing to a build, run a representative sample of the process through the intended model with a realistic system prompt and evaluate the output quality against the standard the deployed agent will need to meet in production. If the output quality is sufficient on 90% of the sample, decision complexity is not a blocking issue. If it is sufficient on 60%, it is.
Decisions involve synthesizing multiple data sources, applying consistent criteria, and producing a structured output. Sample testing shows output quality meeting production standard on 85%+ of instances.
Decisions require lived experience in the specific organizational context, regulatory authorization the model does not have, or interpersonal judgment about individuals and relationships that is not captured in any data source.
Volume and Value
The process occurs at sufficient volume and frequency that the agent's time savings, error reduction, or capacity release produces a positive return on the build, governance, and operational investment within a defined period. Volume and value are evaluated together because a high-volume, low-value process and a low-volume, high-value process can produce equivalent returns — but they require different build scopes and different governance investments, and the calculation must reflect the actual cost profile of the specific agent, not a generic estimate.
The volume and value calculation should be conservative, not optimistic. Agent completion rates in production are rarely 100% — a realistic completion rate of 70–85% is typical for complex multi-step processes in the first six months of production operation. The ROI case needs to hold at that completion rate, not at a theoretical 100% completion rate that assumes no escalations, no edge cases, and no model errors.
Process produces 40+ hours per month of manual effort (or equivalent high per-instance value), and positive ROI is demonstrable at a 70–80% agent completion rate against realistic build and operational cost estimates.
ROI case only works at near-100% completion rates, at optimistic build cost estimates, or on the assumption that the agent will handle all instances rather than a realistic subset that excludes frequent edge cases.
Governance Feasibility
The oversight model, audit trail, and escalation mechanisms required for the process can be implemented without making the governance overhead larger than the efficiency gain. Every production enterprise agent requires a human oversight model, a documented escalation path, and an audit trail. Some processes have governance requirements — regulatory classification, liability exposure, or audit trail depth — that make the governance infrastructure for an autonomous agent disproportionate to the task value. Identifying this before build is significantly cheaper than building the agent and then discovering the governance requirements make production deployment impractical.
Governance feasibility is not about whether governance is required — it always is. It is about whether the governance requirements are proportionate to the process and achievable with the organization's current capability. A compliance monitoring agent for a regulated financial product has governance requirements that are intensive but achievable with the right architecture. The same agent built without governance feasibility assessment may reach the deployment gate and discover that the audit trail requirements or the confirmation gate requirements make the agent more cumbersome than the manual process it was replacing.
Agent outputs are reviewable before consequential action. Error consequences are recoverable. Audit trail requirements can be met with standard logging. Organization has named reviewers available for escalation path.
Process requires per-decision regulatory documentation at a depth that exceeds standard logging capability, or requires oversight SLAs the organization cannot meet with available reviewer capacity, or carries liability exposure that makes any autonomous operation legally untenable.
Score Your Candidate Process
Before Committing to a Build
This worksheet applies the five criteria to a single candidate process and produces a composite score that indicates whether the process is deployment-ready, development-ready with defined remediation, or better directed to traditional automation. Score each criterion honestly against your actual current state — not against what you expect to have after investment.
| Criterion | Score 1 — Fails | Score 2 — Partial | Score 3 — Passes |
|---|---|---|---|
| Goal Clarity | Success definition varies by stakeholder or cannot be specified without referencing relationship context the agent cannot access | Success can be defined but depends on a secondary judgment step that a human still needs to make on a significant minority of instances | Clear, verifiable completion state. Agent can evaluate its own progress toward the goal without external input on standard instances |
| Data Accessibility | Key data inaccessible to automated systems — no API, manual extraction required, or governance approvals not obtainable | Data accessible but with gaps — some fields missing, latency above requirement for a subset of use cases, or governance approval pending but not yet obtained | All required data accessible through documented API or query, within required latency, with governance-approved automated access |
| Decision Complexity | Sample testing shows output quality meeting production standard on fewer than 70% of representative instances | Sample testing shows 70–84% pass rate — adequate for deployment with appropriate human review on the failing instances | Sample testing shows 85%+ pass rate against production quality standard on a representative sample of real process instances |
| Volume and Value | Positive ROI only at unrealistic completion rates or optimistic cost estimates; build cost not recoverable within 18 months at realistic assumptions | Positive ROI at realistic completion rates but marginal — requires second-year operation to clear the build and governance investment | Positive ROI within 12 months at a 70–80% realistic completion rate with documented build and operational cost estimates |
| Governance Feasibility | Governance requirements exceed available reviewer capacity, require audit trail infrastructure that does not exist and is not budgeted, or carry liability exposure that makes autonomous operation legally untenable | Governance requirements are achievable but require infrastructure build or process changes beyond the agent build itself; timeline risk | Governance requirements achievable within the agent build scope; named reviewers available; audit trail requirements met by standard platform logging |
| Score Range | 5–8: Direct to traditional automation or defer. 9–11: Development candidate — address gap criteria before committing to build. 12–15: Deployment-ready candidate — proceed to agent design phase. | ||
Not Ready — Redirect or Defer
The process has one or more fundamental barriers to agentic automation that are not addressable within a reasonable timeframe. Direct to traditional automation if volume and structure support it, or defer until the blocking criterion is remediated. Do not commit build investment.
Development Candidate
The process is worth pursuing but has at least one criterion that needs remediation before build investment is committed. Document the specific gap, the remediation action, the owner, and the timeline. Revisit the score after remediation. Do not start the agent build while a failing criterion remains unaddressed.
Deployment-Ready Candidate
The process passes all five criteria at acceptable levels. Proceed to the agent design phase. The score does not guarantee production success — it confirms that no known fundamental barrier exists. The agent design and deployment phases will surface additional requirements that the assessment may not have captured.
What Separates Process Identification
That Produces Deployable Agents from One That Produces Pilots
The organizations that consistently move from process identification to production deployment are the ones that apply structured criteria to selection — and are willing to say no to compelling candidates that do not pass all five. The ones that stay in pilot are the ones that selected on intuition and discovered the blocking criteria after build investment was made.
| Dimension | Intuition-Based Selection | Criteria-Based Selection |
|---|---|---|
| Selection Basis | Process selected because it is painful, visible, or makes an impressive demo; no structured evaluation of whether it is actually suited to agentic automation | Process evaluated against all five criteria before selection; any failing criterion either remediated or used to deprioritize in favour of a stronger candidate |
| Data Assessment | Data assumed accessible because it exists in enterprise systems; integration complexity discovered after build budget is committed | Data accessibility formally assessed before selection — API availability, quality, latency, and governance approvals verified against actual current state |
| Decision Quality | Model capability assumed based on general LLM reputation; no empirical testing against representative sample of real process instances before build commitment | Sample testing completed before selection; model output quality against production standard measured on representative instances; pass rate documented |
| ROI Case | ROI calculated at optimistic completion rates; build cost estimated without governance infrastructure; case only holds in best-case scenario | ROI calculated at conservative completion rates (70–80%); build and governance cost included; case holds under realistic assumptions before selection is confirmed |
| Governance Pre-Assessment | Governance requirements not assessed at selection; blocking governance requirements discovered at deployment gate after significant build investment | Governance feasibility assessed at selection; reviewer capacity confirmed, audit trail requirements mapped to available platform logging, liability exposure evaluated |
| Portfolio Outcome | Agent portfolio contains pilots that cannot reach production because a blocking criterion was never formally assessed; each pilot is a sunk cost | Agent portfolio contains candidates that have cleared all five criteria before build begins; production deployment rate significantly higher; sunk cost risk minimized |
Agentic AI & Automation
View the full practice →Want a Structured Assessment
Rather Than a Worksheet?
ClarityArc process assessments apply these five criteria to your specific candidate processes with engineering depth — surfacing integration requirements, running model quality samples, and producing a scored gap register your team can act on.
Book a Discovery Call