How AI complexity changes the cost of business outcomes

“Generative” and “agentic” describe how an AI system works. They do not establish whether that system produces a better business outcome for a particular task. For high-volume work, the distinction matters because model calls, tool use, retries and human review can accumulate across thousands of executions. Buyers need to evaluate the mechanism alongside the outcome and expected production volume.

More sophisticated AI has to earn its place

Enterprise teams can use four broad mechanisms: rule-based, predictive, generative and agentic. A rule-based system executes explicitly written logic, while a predictive model scores an input using patterns learned from historical data. A generative model uses a large language model, or LLM, to create content or responses from an input. An agentic system puts a model into a loop where it can plan steps, call tools, inspect results and continue toward an objective.

These mechanisms offer different capabilities. Rules can produce predictable behavior for conditions designers have encoded. Predictive systems can classify or score cases based on learned patterns, while generative systems can interpret open-ended language and create new outputs. Agentic systems can extend those capabilities across several steps and external tools, depending on the workflow design.

Feature-level purchasing discussions can blur these distinctions. A vendor calling a product “fully agentic” is making a claim about its design; the phrase alone does not establish its business value. Assistance can use a generative model without autonomous multi-step execution, while multi-system workflows can also contain deterministic rules. Buyers need to establish what the task requires and which mechanism can meet those requirements at the expected production volume.

Greater complexity can buy useful capability. A generative model can handle language that an explicit rule did not anticipate, and an agentic workflow can retrieve records, choose actions, invoke tools and adapt across several steps. These designs can also involve repeated model calls, carried context, tool use, subagents and retries. Each extra step can add consumption and another point where an error may affect the final result.

Consider an illustrative customer refund workflow. A rule could automatically approve a request under $50 and within 30 days, while a predictive model could classify the request as approve, deny or escalate based on historical patterns. An LLM could draft a response to an unusually worded request. An agent could retrieve the order, apply policy, issue the refund and send confirmation through the customer’s preferred channel.

These approaches solve different versions of the problem. Autonomous multi-step execution may justify an agent when the task requires several tools and decisions. A request covered reliably by explicit policy conditions may be handled with deterministic logic, with exceptional cases routed to a generative or agentic path. The economic question is whether the extra capability creates enough incremental value to cover its production cost and risk.

Production economics can change the price calculation

Production cost depends on the whole workflow. A model price can fall while the cost of completing a task rises if the workflow uses more calls, tokens, tools or retries. In a multi-step workflow, the model may process earlier context again before choosing its next action. Subagents can add further consumption.

Gartner’s estimate points to the potential consumption multiplier when a workflow invokes a model repeatedly. EY’s stated figures imply around 30 times the cost, although the comparison spans different years and architectures. EY is a commercial professional-services firm that sells services to enterprises, so its estimate about enterprise AI economics comes from an organization that can benefit commercially from demand for related advisory and implementation work.

The useful purchasing unit is total production cost per successful business outcome. That calculation can include model consumption, orchestration, tool usage, retries and the human work required to make the result usable. A per-token or per-interaction rate covers only the components included in that rate. Comparing complete workflows requires buyers to establish what work sits inside each quoted unit.

Volume magnifies unit economics. For illustration, at a tenth of a cent per product description, 200,000 descriptions would cost $200 for one refresh and $800 if the full catalog were refreshed four times a year. At an illustrative $0.90 per automated ticket, 400,000 tickets a year would cost $360,000 before any additional review expense. A small unit price still needs to be multiplied by realistic annual usage.

Marketing makes this effect visible because some workloads repeat the same operation across large catalogs or customer volumes. Product content is one example: architecture costs recur with every execution and again when the content is refreshed. Open-ended creative work, customer interactions and cross-system processes can have different requirements. Buyers should calculate production economics from the workload they expect to run.

A successful pilot can hide the production equation

A proof of concept can show whether a system performs a task under test conditions. Its economics may look very different at production volume because a small experiment generates only a small absolute bill. An illustrative pilot with 500 interactions could demonstrate functionality without establishing whether the same design is economical across the organization. Economic validation requires realistic annual volume and the production work around each interaction.

Procurement and governance processes can separate two tests. Functional validation asks whether the system works under defined conditions. Economic validation asks whether the cost per successful outcome remains acceptable after expected volume, retries, review, revisions and other production work are included. Making both explicit prevents technical success from substituting for a production business case.

A useful purchasing calculation can begin before the pilot. Apply the vendor’s per-interaction estimate to the organization’s expected annual count, then add expected labor for review and revision plus any separately charged tools or services. The result depends on assumptions, so make those assumptions visible and test them during the pilot. Teams can also test routing: in the refund example, routine requests can follow explicit policy logic while exceptional cases go to a generative or agentic workflow.

Human verification belongs in the operating cost

Compute is one component of AI operating cost when employees verify outputs. A deterministic process and a generative system can fail in different ways: a generative response can contain an incorrect policy statement expressed in fluent language. Detecting that error may require an employee who understands the relevant policy to inspect the response. That review time belongs in the workflow economics.

Labor and technology spending can also appear in different budgets. Platform expense may sit on a technology invoice, while verification appears as employee time, contractor expense or headcount in an operating team. A system can reduce drafting or execution time while retaining meaningful review work. ROI should reflect the end-to-end process, including the people required to check or correct outputs.

The cost changes again when a system moves from creating content to taking actions. An agent that retrieves an order record, interprets policy and issues a refund creates consequences beyond those of a draft that an employee approves before sending. Greater autonomy can remove manual execution, while controls, verification and the expected impact of errors remain part of the business case. Buyers should measure those costs against the labor the automated workflow actually removes.

Nominal automation rates alone cannot capture this labor. If staff routinely correct, reject or double-check outputs, their time is part of the system’s operating cost. Review time across annual volume can materially affect a comparison between architectures. Finance and business owners need verification labor attached to the same workload calculation as model and orchestration spending.

Cost ownership crosses organizational boundaries

Different enterprise functions see different parts of the decision. Procurement sees contract and seat prices, legal examines data handling, and marketing judges whether an output meets the business need. Budget owners see departmental spending, while engineering and data teams can assess the mechanism and estimate how its architecture affects production consumption. A full economic assessment depends on combining those views around the same workload.

When costs remain separated, no individual review necessarily captures model consumption, orchestration, human verification and expected volume together. The purchasing process can close that gap by assigning ownership for cost per successful outcome. Engineering and data review can then inform commercial decisions by identifying which cases require generation or agentic execution and which can follow deterministic or predictive paths. The answer should come from the task’s requirements and measured production economics.

Key highlights

• Match AI complexity to the task: Generative and agentic AI earn their place when their added capabilities improve business outcomes enough to cover higher cost and risk. Buyers can route predictable work through rules or predictive models and reserve more complex AI for cases that require it.
• Calculate production cost per outcome: Model pricing alone does not capture orchestration, tool calls, retries, human review or production volume. Procurement and finance can compare architectures using total cost per successful business outcome at realistic annual usage.
• Test economics during the pilot: A successful proof of concept can conceal costs that become material at scale. Business owners can validate expected volume, retries, review labor and routing assumptions alongside functional performance before approving production deployment.
• Include human verification in AI economics: Review, correction and oversight consume labor even when AI automates part of a workflow. Budget owners can attach that labor to the same workload calculation as model and orchestration spending, especially when AI systems take consequential actions.
• Assign ownership across organizational boundaries: AI costs often span technology invoices, operating budgets and employee time. Procurement, engineering, finance and business owners can establish a shared cost-per-outcome measure that captures the complete production workflow.