AI Automation Triage
Use this skill when the user wants to decide which tasks or capabilities their team should automate with AI, which need human review or decision rights, and which AI is quietly eroding versus strengthening as a real advantage.
This skill is Labor as Code™ for Chasing Native Alpha's "Test Whether AI Erodes or Strengthens the Advantage" chapter. It runs the book's task-classification method and its erosion/amplification matrix against the reader's own actual task or capability list — it does not retell the book's care-management-dashboard example, and it does not decide, by itself, that a given task is safe to automate. It produces a classified list and a set of questions still open for a human to answer.
Two of this book's central terms apply directly: this skill helps a reader find which of their own team's tasks might be ready to become Labor as Code — durable, inspectable, versioned execution of a method — by first testing whether Native Alpha is actually present in the task's current form, or whether it's a task any competent alternative already performs.
Before running
Confirm with the user before starting:
- The actual list of tasks or capabilities to classify, and who currently does them. A vague "everything we do" produces a useless triage — ask for a real, bounded list (the book's own exercise caps it at the important capabilities consuming the most attention).
- What quality or outcome baseline already exists, if any — cost, error rate, cycle time, customer-visible result — versus what will have to be estimated. Flag every estimate as an estimate.
- Who has authority to change where AI is or isn't used. This skill produces a classification and recommended actions; it does not implement automation, change access controls, or remove a human checkpoint. That is always a decision for the named owner of the work.
Step 1: Classify by context, consequence, evaluability, and frequency
For each task, ask the four questions below and place it in the matching row. Do this per task — do not classify a whole department or workflow at once, since different steps inside the same workflow often land in different rows.
| Task characteristics | Recommended approach |
|---|---|
| Low context, low consequence, easily evaluated | Move toward automation quickly |
| High context, easily evaluated | Benefits from retrieval and specialized agents |
| High consequence, strong evaluation | Allow automation inside strict gates |
| High consequence, weak evaluation | Needs decision support, not autonomous action |
- Context: does this task need only public or generic knowledge (low), or does it depend on this organization's own conventions, architecture, customer commitments, risk tolerances, and operating history (high)?
- Consequence: what happens if the output is wrong — a clinical recommendation, a security decision, a financial commitment, a production change (high), or something easily caught and cheaply corrected (low)?
- Evaluability: can a correct or acceptable output actually be checked, cheaply and reliably, before it does damage? If nobody can say what "good" looks like for this task, evaluation is weak — treat it as weak even if the task feels routine.
- Frequency: does this task recur often enough that the investment in automating or building an evaluation harness pays for itself?
This is not a one-time policy. Note the date of this classification — the book is explicit that the boundary moves as models, context systems, and evaluation improve, and the classification should be revisited, not frozen.
Step 2: Classify each capability's AI effect
For each of the same tasks, or for a broader capability the tasks roll up into, classify the effect AI is actually having — not the effect a demo suggested it should have:
| Effect | Question | Likely action |
|---|---|---|
| Erodes | Can others now reproduce the output cheaply? | Reduce protection; move up the value chain |
| Amplifies | Does AI compound scarce context, data, trust, or judgment this organization actually has? | Invest and measure the combined outcome |
| Releases | Can AI remove work that was blocking a capable person from their highest-value work? | Automate, then verify the freed time actually moved to higher-value work |
| Exposes | Does AI reveal that this capability never produced real differentiation to begin with? | Run a replacement test (see the false-alpha-hearing skill) |
| Uncertain | Is reliability too uneven, or consequences too high, to classify yet? | Time-box an evaluated pilot rather than guessing |
For every row, require:
- The mechanism — what, specifically, does AI change here?
- A benchmark — better than what reasonable alternative?
- Confidence and missing evidence — say plainly what's assumed versus observed.
- A failure mode and leading signal that would show the classification is wrong.
- A thirty-day test where the classification is genuinely uncertain.
Do not count tool adoption as the outcome. The book's own warning: a dashboard that's entirely green on usage and output volume can still be hiding a bottleneck that moved downstream (their care-coordination example: adoption and message volume rose while patient follow-through did not improve). Ask for the business or customer-facing result the combination actually produced, not the amount of AI-generated output.
Step 3: Decide what stays a human checkpoint
Before recommending automation for anything in the "high consequence" rows, ask explicitly why the current human check exists:
- Does it prevent a cheap action from becoming an expensive mistake?
- Does it force accountability, conflict detection, or an irreversible tradeoff into view before it happens?
State which of the two this is, with the reasoning: if the friction exists only because information is hard to assemble, name it a removal candidate and recommend fixing the information flow rather than removing the check itself. If the friction exists to force a human decision on genuine ambiguity or consequence, say so and recommend it stay. Either way, this skill states the classification and its reasoning - actually removing a checkpoint is the accountable owner's act, not this skill's, and the recommendation is what they act from, not a decision already made on their behalf.
Step 4: Name what happens to the freed capacity
For anything recommended for automation or release, do not let the recommendation stop at "this saves time." Ask: which specific higher-value work — whose Native Alpha — will the recovered time go to? Automation without a named destination tends to get reabsorbed into more low-value activity, not redirected.
What this skill does not do
This skill classifies and recommends, with reasoning traced to the mechanism, benchmark, and evidence behind each call - it does not flip the switch. Stating that a checkpoint looks like a removal candidate is this skill's job when the evidence supports it; actually removing it is the accountable owner's act, informed by this skill's reasoning and by their own weighing of consequence and reversibility, not overridden by either. Where the evidence is thin (uneven reliability, untested consequence, no real baseline), the correct output is "uncertain — pilot this," not a confident automate/don't-automate verdict manufactured to close out the list.