What I keep noticing in conversation about automating part of a business is that buyers that say no most often do so for exactly the right reason, which is that the workflow isn’t ready yet, and the conversation ends there. The “no” is correct, but I think the stopping point isn’t.
I know the stopping point because I used to live there. In a previous role I sat through a stretch of consultant pitches, agreed with most of them in principle, declined the ones that didn’t fit our operation, and went back to running the operation as it was, which all made sense at the time. The projects I was already responsible for needed to stay on budget and on time, and going back to my boss to say “the project as approved will need to grow, cost more, and probably touch other departments before the work I was actually tasked with even starts” felt like exactly the way to lose the trust I’d need for everything after it. Scope creep reads as poor project management at first glance. The vocabulary that lets a scope expansion read as discipline, not flailing, is the vocabulary the conversations didn’t yet have.
The “no” was right. The next step had a name; I just didn’t know it. That stopping point is the thing I want to think through here.
The two-option trap
The binary I kept running into in those rooms, and now run into on the other side of the table, is “deploy the agent now” or “wait until the agents get better.” There’s a third option that nobody in the room can see, including the buyer. It isn’t invisible because it’s sophisticated. It’s invisible because nobody in the room is selling it.
The vendor sells agents. The AI consultant sells deployment. The operations consultant sells process improvement but doesn’t frame it in revenue-based terms that would justify its priority. Each of them gets paid for their half of the work, but they all skip over the gap between them, where the work is less sexy and harder to bill at a premium. The third option: re-engineer the workflow so the agent can fit it. Then deploy. The re-engineering is the actual project. The deployment is what lands after it.
However, once the third option is no longer invisible, the next question I find myself asking is: which dimension of the workflow is actually doing the blocking? “The workflow isn’t ready” isn’t specific enough to fund a project against. The agentability rubric is exactly the tool I wish I had when I was hearing pitches myself.
The example I keep coming back to is pricing exceptions in renewal conversations, which I worked through in the agentability piece. In that example, a buyer declines an agent pitch because their pricing-exception workflow can’t support reliable agent output, and I’ll walk through what could have been done instead.
Which dimension is actually blocking
The agentability rubric names five dimensions: input clarity, decision determinism, failure cost or recoverability, verification ease, and exception frequency. The rubric is most intuitively used as a triage instrument. Score the task, decide whether to deploy. What I keep noticing is that the rubric is more useful as a project-scoping instrument than as a triage one.
Each dimension, when suboptimal, maps one-to-one with the playbook for a different re-engineering project. The dimension blocking deployment is the dimension that, once raised, would subsequently make the deployment feasible.
- Low input clarity → input normalization. Templated capture, structured intake, OCR-plus-extraction pipelines, voice-to-structured-text layers. The deliverable is a thin extraction layer with a known schema that any downstream agent (or human) can read and act against.
- Low decision determinism → decision-framework articulation. Documenting the rules, codifying the trade-offs, writing down what the senior operator would do here. The deliverable is a written framework that doubles as the agent’s system prompt and as onboarding material for new staff.
- High failure cost or low recoverability → guardrails and staged rollout. Verification layers, sampling-and-review queues, dual-key approval for high-stakes outputs. The deliverable is a deployment topology that contains errors before they reach production.
- Low verification ease → instrumentation. Output sampling, drift detection, comparison-against-known-good baselines (“evals”), structured decision logging. The deliverable is a monitoring layer that flags suspicious outputs before they propagate downstream.
- High exception frequency → task segmentation. Routing routine inputs to the agent and exception inputs to a named human, with an upfront classifier doing the routing. The deliverable is the classifier itself plus the two paths.
Knowing what to do isn’t the bottleneck. Funding it is.
Why this work doesn’t get funded
The funding question is the part I keep circling back to. The diagnostic is clear, the playbook is named, and still the project doesn’t get run. Three structural reasons keep showing up, in roughly the order I notice them.
The first is budget category mismatch. AI projects come out of the strategic-initiatives budget, the digital-modernization budget, or the IT capex line. Workflow redesign comes out of the operations improvement budget. Different owners, different approval cycles, different return standards. A project that legitimately requires both gets bounced between them, smuggled into one at the expense of clarity, or dropped because nobody owns the integrated case. The way out is to name the project as re-engineering from the start, with a downstream automation phase that depends on it, and fund both phases in one approval. The board approves the combined math; the operating budgets carry their respective phases.
The second is the deferred-gratification problem. Re-engineering is months of unsexy operations work before any visible AI deployment. Boards and CEOs want automation outcomes, not process documentation as a prerequisite. The pressure pushes teams to skip the re-engineering and deploy on whatever’s already ready, which is usually the wrong half of the work. The fix that works is structuring the re-engineering with intermediate deliverables that have standalone value. A structured customer-history capture accelerates analyst work the day it ships, before any AI ever runs against it. The agent is the second beneficiary, not the only one.
The third is the one that bothers me most. Operations consultants do workflow redesign but don’t speak to the reality of agents and LLMs fluently. AI consultants do agent deployment but don’t run process projects. Buyers hire one or the other and miss the integrated project, or don’t buy either without realizing a path to their goal exists.
What this looks like when it works
The pricing-exceptions task from the agentability piece scored low across input clarity (context lives in CRM notes and the rep’s memory), decision determinism (price judgment depends on customer history, competitive context, strategic relationship value, all weighted tacitly), and verification ease (catching a bad call requires being the rep, or being someone who has seen the customer’s full history). Three dimensions, across three workstreams:
- The input clarity workstream is addressed with structured customer-history capture → Pull notes from CRM, sales-call summaries, and rep memory into a standardized schema. Where the data doesn’t exist, instrument capture going forward. This can be eight to twelve weeks of work, depending on system complexity, mostly involving data engineering and process design.
- The decision determinism workstream is a framework articulation problem → Interview the three senior reps who handle most pricing exceptions today. Document the factors they weigh, the thresholds they apply, the cases they remember as inflection points, and produce a written framework with examples. Six to ten weeks, mostly interviewing, writing, and testing against real situations to gather feedback.
- The verification ease workstream involves variance-monitoring instrumentation → Build a comparison layer that, once an agent is drafting pricing recommendations, shows each draft alongside the senior’s actual call. Sample, drift-detect, calibrate. Something like this might be four to six weeks, mostly tooling-related.
Total execution time is about four to six months considering parallel execution where possible. Total spend is somewhere in the $50,000 to $150,000 range depending on how much of the work is in-house versus consultant-led. The number is small relative to the cost of a failed deployment of an unrelated AI tool, and it’s smaller still relative to the renewal margin the agent is meant to protect once it lands.
What I find myself noticing about this walk-through is that none of these workstreams produce an AI deployment by themselves. The deployment lands after they complete, which means the buyer has to fund six months of work before any agent goes live. That’s exactly the deferred-gratification problem I was referencing, and having the intermediate deliverables soften it. The structured customer history accelerates analyst work in week ten, before any agent is drafting anything. After that, the articulated framework becomes onboarding material for the next commercial hire, and the instrumentation layer becomes a quality monitor for the senior reps’ own work, regardless of whether an agent ever sees it.
The compounding part
What makes me think re-engineering is its own category rather than a sub-step is what happens after the deployment lands. The artifacts compound across downstream tasks in a way a single AI deployment doesn’t.
The structured customer-history artifact from the input-clarity workstream now feeds every other customer-facing task in the org: quote generation, renewal scoring, churn early warning, expansion opportunity detection. It’s built once for pricing exceptions, and every downstream task inherits the foundation.
The decision-framework articulation from the decision-determinism workstream is the agent’s system prompt and the onboarding material for the next commercial hire. Every new person who joins the commercial team inherits a written framework that used to live entirely in three senior reps’ heads. Better still, a learning from one rep gets updated in one place and propagates to every agent and new hire going forward.
The instrumentation layer from the verification-ease workstream is reusable across any other agent-drafted document type that needs senior review. The new tooling will need some tweaks, but the monitoring pattern itself travels well.
Here’s what I keep coming back to. The right unit of analysis isn’t “return on this re-engineering project.” It’s “return on this re-engineering project across the cluster of downstream tasks that share its artifacts.” That math is invisible in a single-project return calculation and obvious in a portfolio view. Most orgs do single-project math. The ones that do portfolio math win.
The political dimension I can’t shake
The dynamic I keep noticing about re-engineering specifically is that it asks the workflow’s current owners to redesign their own roles, not just hand off pieces of them. That’s a different ask, and it lands politically in a different way than a deployment does. Three patterns show up consistently.
The first is the “we already have a process” pushback. The current workflow has defenders. They built it, they’ve trained the team on it, or they’re just comfortable with it. Re-engineering reads as a critique of their work, even when framed neutrally. The pattern I’ve watched work is to name the change as adaptation for a new constraint (the addition of agents to the operating model, in service of achieving a common goal or OKR), not correction of a flawed prior design. Bring the workflow’s owner into the redesign as co-architect from week one. If they can’t or won’t co-architect, the project lands badly regardless of its technical merits.
The second is the “this is a tech project, not a process project” pushback, which comes sometimes from IT, sometimes from the COO. The work gets categorized as someone else’s project and stalls in the space between operations and technology. Joint sponsorship across ops and IT from day one, with clear ownership of each artifact named in the project charter, is the only structure I’ve seen actually survive this. A re-engineering project without joint sponsorship dies from the ambiguity.
The third is the “we’ll fix it when we deploy the AI” pushback. Teams committed to deployment soon want to do the re-engineering as part of the deployment, not before it. This always fails. The re-engineering compresses into the deployment timeline, doesn’t get the depth it needs, and the deployment ends up trying to compensate for un-fixed workflow problems by adding complexity to the agent. The structural fix is to insist re-engineering precede deployment by at least one quarter, ideally adding a separate “bake-in” period between the two. The board can approve the combined math, while the operating cadence executes the two phases in sequence.
The thing I keep noticing when I sit with these patterns is that the funding-category problem from the previous section and the political pushback here are the same problem in two different vocabularies. The CFO calls it a budget question. The COO calls it a turf question. The fix is realizing that they’re both right.
The three honest options
What I think the three honest options are for a buyer staring at a low-agentability task: re-engineer now, wait for better agents, or keep human. Each option fits different conditions. Most low-agentability tasks fit option one if examined honestly.
“Re-engineer now” fits when the task is high-volume (so the project amortizes), the artifacts are reusable across other tasks (so the compounding return is real), the political ground is workable (the workflow’s owner can be brought in as co-architect), and the org has the budget tolerance for deferred gratification (the deployment lands a quarter or more after re-engineering completes). For most operations-led businesses, this is the right answer for the majority of low-agentability tasks worth running the math on.
“Wait for better agents” is defensible when the blocking dimension is one that’s actually getting better with each agent generation. Exception frequency is the leading candidate; LLM agents are getting noticeably better at unusual content year over year. For tasks blocked on input clarity, decision determinism, or verification ease, waiting is wishful thinking. Those dimensions don’t improve passively, because the constraint is in the workflow, not in the agent.
“Keep human and accept the cost” fits when the task is low-volume (so re-engineering doesn’t amortize), the political cost of re-engineering exceeds the benefit, and the work is fine where it is. This is the right answer for a smaller subset of tasks than most orgs assume.
A fourth option exists to try a deployment anyway and fix the task’s agentability during implementation, but I don’t recommend it.
What I keep noticing is that the default in most orgs is option three, because option one requires a different budget conversation than the one they’re used to having. The orgs that develop the conviction to have the option-one conversation are the ones that win at automation and start to see the payback show up in their bottom line.
Where this leaves things
I’m still turning over whether workflow re-engineering is its own discipline or just operations consulting with an AI-era framing. I think it’s both. The discipline question matters less than the funding question, because the project doesn’t get run regardless of what we call it, and that’s the thing actually worth changing.
The thing I keep coming back to is the buyers I’ve been meeting who said no for the right reason. The next question I want them to ask, the one I’m trying to make available in this piece, is: which agentability dimension is currently blocking this task, and what would the re-engineering project for that dimension look like? If the vendor in front of them doesn’t have an answer, the vendor is selling the wrong half of the work. The buyer can keep saying no until someone shows up selling the right half. The work of identifying which re-engineering project to run, which the automation audit piece sits with more directly, is the half of the conversation most buyers have never been offered.
There’s one piece of this where I have the least confidence and would want pushback: the political dimension in the previous section. The patterns I’ve named are what I’ve watched, but the sample is biased toward the conversations I’ve been in or have been relayed to me. If you’ve run one of these projects from the inside, I’d love to hear where the political dynamics actually broke and what fixed them. That’s where the framework needs the most pressure-testing.