Which Workflows to Automate First (and Which Stay Human)

Most automation roadmaps start with the wrong question. “Which tasks can AI do?” produces a demo. “Which workflows should we rebuild around AI — and which decisions must a human keep owning?” produces a P&L line. The gap between those two questions is the gap between a pilot graveyard and an operating model.

Here is the filter we use to sequence the first builds inside client engagements. It is opinionated on purpose.

Which workflows should you automate first?

High-volume, rule-heavy, measurable — in that order. Volume compounds the return. Explicit rules make quality checkable. Measurability is what turns “the team likes it” into a number your CFO will sign. McKinsey’s Rewiring for AI research lands on the same sequence: start where volume is high and outcomes are measurable, prove the return, then scale.

The market is already voting this way. Anthropic’s June 2026 Economic Index report found that businesses concentrate Claude usage in tasks suited to programmatic access — coding and administrative work — far more than individual users do, and that the top ten enterprise API tasks now carry 32% of traffic, up from 28%. Enterprises that measure are converging on the same first targets.

What that looks like inside a real org:

• Triage. Tickets, inbox routing, lead scoring — anything where a human reads, categorizes, and forwards.
• Document-to-system movement. Invoices to the ERP, contracts to the CRM, meeting notes to the project tracker.
• Reconciliation and matching. Two lists that must agree, checked by hand every week.
• First drafts. Reports, briefs, summaries, responses — where a human edits instead of originates.

The common thread: done is definable. When done is definable, you can write evals. When you can write evals, you can hand the workflow to an agent without praying.

One more sequencing rule: internal before customer-facing. An internal error costs a rework; a customer-facing error costs a relationship. Let the system earn trust on internal volume — tracked accuracy, weeks of clean runs — before it speaks to anyone who pays you.

If you want the live version of this filter, watch JJ Englert hand Claude Cowork his entire job and record what it actually handled on the 10x Builder channel. The parts that snapped back to him are the next section.

Which workflows should stay human?

Keep a human wherever the value of the work is the judgment call, the relationship, or the accountability — not the keystrokes. Here is the position, and you are welcome to disagree: “hard stays human, easy gets automated” is the wrong axis. AI already handles plenty of hard work. What actually stays human is narrower and more specific:

• Decisions someone must own. Pricing exceptions, terminations, credit approvals, anything with a signature. The model can rank the options; a person owns the call and its consequences.
• Relationships where presence is the product. The renewal conversation with your biggest account. The apology after an outage. Speed is not the value here — showing up is.
• Judgment that sets precedent. The first ruling on a new edge case becomes policy. Automate the thousandth instance, never the first.

A useful tiebreaker when a workflow sits on the line: blast radius. If a wrong output gets caught downstream at the cost of a rework, automate it and let the evals tighten. If a wrong output walks out the door carrying your name — a quote, a commitment, a number a client will act on — keep a human between the draft and the send button until the tracked error rate says otherwise.

The nuance most lists miss: staying human does not mean staying manual. Your best account manager should walk into that renewal with an AI-built brief of every interaction, risk signal, and expansion opening. The drafting is automated. The call is not. Human-in-the-loop is not a compliance checkbox — it is a design decision about where accountability lives.

Why do most first automations fail?

Because teams automate tasks instead of redesigning workflows. MIT’s GenAI Divide study, reported by Fortune in August 2025, found roughly 95% of enterprise generative AI pilots deliver no measurable P&L impact. The root cause was not model quality. It was a learning gap: generic tools dropped into workflows that never adapt around them.

McKinsey’s work-redesign research makes the same argument from the other side: the right question is not which tasks can be automated but which whole workflows should be redesigned — and high performers are about three times more likely to have fundamentally redesigned workflows rather than sprinkled AI on top of existing ones. Automate a task inside a broken process and you get a faster broken process.

CJ Hess put the operator’s version of this on X in The Swarm Has Arrived: the constraint has moved from whether an agent can do the work to whether you can define the problem clearly enough for a swarm of them to solve it. A workflow that cannot survive being written down cannot survive being automated. Getting from a working pilot to an everyday operating process is its own discipline — we broke it down in how to move beyond AI pilots.

What does a first automation engagement actually look like?

Four moves: embed, ship, train, hand off. This is how we run an AI transformation, compressed.

Embed. We sit inside the team and trace workflows as they actually run — not as the process doc claims. The org chart lies; the workflow doesn’t. The output is a scored list: volume, rule density, measurability, owner.

Ship. We pick the highest scorer and build it in your stack, your repos. First production system by week four, median — a running system, not a deck. Eval-gated from day one, so quality is a number before anyone argues about it.

Train. Pairing, not lunch-and-learns. The operators who ran the manual workflow run the automated one, tune the prompts, and read the dashboards. The bar we hold ourselves to: 90%+ operator adoption — weekly active at handoff, tracked, and tagged illustrative until audited.

Hand off. Repos, evals, agents, and dashboards transfer to your team, and our access gets revoked. Dependency is a design flaw.

We publish teardowns of builds like these most Tuesdays in ultrathink, the weekly Tenex newsletter.

When should you not automate a workflow?

Do not automate a workflow you cannot measure, a process nobody owns, or chaos nobody has documented. Three failure modes show up constantly:

No baseline. If you cannot state today’s cycle time or error rate, you cannot prove the automation worked — and the ROI question becomes unanswerable. We covered how to set that baseline in where AI actually creates measurable ROI. Measure first. It is the prerequisite almost everyone skips.

Automating around a broken process. If the workflow only functions because one veteran quietly fixes it, automation removes the veteran and keeps the breakage. Fix the process, or at minimum document the workarounds, before a single prompt gets written.

No owner. Every automated workflow needs a person who wakes up Monday responsible for its output. No owner means no one notices drift until a customer does.

And the honest disqualifier: do not start this quarter if the team is mid-reorg, the process changes monthly, or the critical data lives in one person’s head. Automating a moving target burns budget and trust. Sometimes the right answer is not yet — and if that is your situation, we would be wasting your money, and we will say so.

---

You already know which workflow it is. Score it — volume, rules, measurability, owner — and bring it to us. We will tell you in one conversation whether it is worth automating first. If it is not, we will tell you that too.