What an agentic workflow actually costs to run, and how we model it upfront

The token cost per API call is the easy, visible part of pricing an agentic system, and it's rarely the number that actually determines whether the project makes financial sense. Every cost model we build before a client commits to a production agent includes at least four other line items that get missed far more often than they should, and two of them have killed otherwise well-designed projects once the real number was in front of the client.

A single user request to an agent rarely maps to a single model call. A task that requires three tool calls and a final synthesis step is four calls minimum before anyone accounts for a call that needs retrying because a tool returned an error or the model's output didn't parse cleanly. We've seen naive cost estimates built by simply multiplying an expected monthly request volume by the cost of one model call, understating the real cost by three to five times once actual multi-step execution and retry behavior gets accounted for. We model this explicitly now, based on the actual number of steps in the agent's typical execution path, not a single-call assumption.

Every production agent we run keeps sampling live traffic against evaluation checks, logging full execution traces, and periodically re-running the standing evaluation set against any model or prompt changes. None of that is optional if you actually want to know whether the system is still working correctly six months after launch, and all of it costs real compute and, often, real model calls of its own. We size this at roughly fifteen to twenty-five percent on top of the core production cost, depending on how much of the evaluation pipeline itself relies on model calls versus simpler rule-based checks, and we put that number in front of clients upfront specifically so it doesn't arrive as a surprise on the first full month's invoice.

Any agent with a human-in-the-loop checkpoint, which is most of what we build for anything with real consequences attached, shifts cost from pure compute to staff time spent reviewing the agent's proposed actions. That's often the right trade for the risk profile of the task, but it's a real ongoing cost that needs to be in the model from day one, not treated as a separate line item the operations team discovers later. We estimate review time per case based on a pilot period with real staff doing real reviews, timed honestly, rather than an optimistic guess about how quickly a reviewer will be able to confirm the agent's proposed action once they're used to the tool.

Once all four components are accounted for, token cost, retries and multi-step execution, the evaluation and monitoring pipeline, and human review time, the real monthly cost of a production agent typically lands two to four times higher than a back-of-envelope estimate based on token pricing alone. That's not a reason to avoid agentic systems; in every project we've shipped, the fully-loaded cost still comes in well below the labor cost of the manual process it replaced. It is a reason to build the honest number before a client signs off on the project, since a client who commits based on an understated estimate and gets surprised later is a client who loses trust in the system regardless of how well it actually performs.

Presenting a fully-loaded cost estimate rarely kills a project outright, in our experience, but it does change which workflow a client chooses to automate first. A client who arrived wanting to automate their highest-volume process often reconsiders once the full cost model shows that a lower-volume, higher-stakes process, one where each individual case currently costs significant staff time to handle manually, actually produces a better return once the agent's fully-loaded operating cost is weighed against the labor it replaces. High volume isn't automatically the best starting point if each individual case is cheap to handle manually already; the better first project is often the one where manual handling is expensive per case, even if there are fewer cases overall.

We build this comparison directly into every proposal now: the fully-loaded monthly cost of running the agent against the fully-loaded monthly cost of the manual process it would replace, broken down by the same categories, staff time, error correction, and overhead, on both sides of the comparison. Seeing both numbers built the same way, rather than an optimistic automation estimate next to a vague sense of what the current process costs, is what actually lets a client make an informed choice between competing candidate workflows rather than defaulting to whichever one felt most obviously automatable at first glance.

This comparison has redirected more than one project. A logistics client came to us wanting to automate a high-volume, low-complexity data entry task; once we built the full cost comparison, a lower-volume exception-handling process, the kind of case that currently pulled a senior ops person away from other work for twenty minutes at a time, several times a day, turned out to have a far better return once both the automation cost and the true cost of the manual alternative were built out fully. We ended up building the exception-handling agent first, and the original data entry task a full six months later, once budget freed up from the return on the first project. Neither choice would have been obvious from token cost or ticket volume alone; it only became clear once both sides of the ledger were built out completely, in the same units, at the same level of rigor. None of this is unique to logistics or to this particular client. We now build the same side-by-side comparison as a standard first step on every new agentic engagement, regardless of how confident the client already feels about which workflow to start with, specifically because that confidence is usually based on which process feels most annoying day to day rather than which one the actual numbers support most strongly.