The hard part of putting AI into a business is not building the agent. It is picking the right work, and writing down what a correct result looks like before you start: the inputs, the outputs, and the contract an acceptable output has to satisfy. Across multiple deployments, we find that to be the single biggest predictor of whether a workflow is ready for AI.
The gate
The biggest predictor of whether a workflow is ready for AI is whether the team can describe what a correct result looks like in concrete terms: the inputs that go in, the outputs that come out, and the contract an acceptable output has to satisfy. The description has to be specific enough that a junior analyst could read it and grade an actual output against it. If nobody can write that down, the workflow is not ready, regardless of how obviously broken the manual process is.
Most "AI is unreliable" complaints are actually "we never specified what reliable meant". The model produced an output, the operator looked at it, something felt off, and there was no specification to compare against. The model could have been right. There was no way to tell.
What a workflow specification contains
A workflow ready for automation has four things on paper:
- Inputs. What goes in, in what shape, from which systems.
- Outputs. What comes out, in what shape, with which fields populated.
- Contract. The rules an output must satisfy: formatting, source citations, escalation thresholds, banned values. This is what makes one output correct and another not.
- A correct example. At least one finished output the team agrees is good. Three is better.
In practice the specification is short. Three examples from different corners of a business:
PO-to-invoice matching (finance). Input is a purchase order and a vendor invoice; output is a matched-or-not flag plus the list of mismatched line items with PO value and invoice value side by side; contract require every mismatch to cite the source line on both documents and any variance below the customer's tolerance to be auto-approved; correct example is whatever the AP team would have produced by hand on five past invoices.
Tender qualification (sales). Input is a tender document and the firm's bid-eligibility checklist; output is a go or no-go recommendation plus the list of mandatory requirements, each with a fit-rating against the firm's capabilities; contract require every requirement to cite the clause it came from and any no-fit item to be escalated to the bid manager; correct example is the last three tenders the senior bid manager qualified, with their reasoning recorded.
Customer support email triage (operations). Input is an inbound customer email and the team's queue and knowledge-base index; output is a category tag, a routing decision to one of the existing queues, and a suggested first response with cited knowledge-base articles; contract require every category to come from the existing taxonomy and every cited article to be a real link; correct example is twenty past tickets the team agrees were handled well.
Half a page of structured text is usually enough. Most teams find writing it down harder than expected; the structure exposes vague assumptions that nobody had named.
Why this is harder than it sounds
The reason most teams cannot produce this on demand is that the contract (the rules an output has to satisfy) lives in senior staff's heads. Nobody has ever needed to write it down, because the work was always done by people who already knew. The rules are real and they are consistent, but they have never been articulated in a form a non-expert could apply.
Half the value of a SmartVantage audit is forcing the team to extract that tacit contract onto paper, regardless of whether anything gets automated afterward. A workflow that cannot pass the gate needs structuring work before any agent can help, and that structuring work usually exposes process problems worth fixing on their own. The specification is the deliverable, even when no agent gets built against it.
Once a workflow clears this gate, the next question is what shape the work takes. Four common patterns recur across the deployments we have run, and naming which one a candidate fits is usually how teams decide where to start. We cover the four patterns in a companion piece.