AI Workflow Optimization: 2.7x Cheaper Pipeline Case Study

The Business Problem: AI Worked, but Cost Too Much

Our system already did its job: it turned a brief into a published multilingual article in the CMS. Each run, however, needed hundreds of model calls and more than half an hour. The output quality was acceptable. The trouble was the economics and how unpredictable the process had become, and both would get worse as volume grew.

In plain terms, the platform takes a brief and walks it through a chain of steps. It gathers context and research with source authority tiers, builds a structure, writes the main text, translates it, adds internal links, prepares metadata, FAQ and media, and publishes into the CMS. The articles support our SEO and GEO work, so they have to be accurate in every language. We did not change any of these business steps during the optimization. We only changed who performs each one.

The old setup was multi-agent and ran on Claude Code. An orchestrator model started more than ten subagents, one per phase. Each subagent received file paths instead of the data itself. It then had to read those files, figure out how to sign API requests, write temporary scripts, edit text in small pieces and report its own status back.

We measured 11 full runs in agent mode. The median cost was $42.49 equivalent per article, with a range from $20.87 to $66.39. The median run made 234 tool calls. A threefold spread between the cheapest and the most expensive article is hard to plan around, even when the average looks tolerable.

For a business, this is the familiar risk of AI workflow automation. The cost per unit is unpredictable, reruns quietly add to it, and every extra language or optional phase multiplies the spend. Any company automating a real process, from order handling to customer support, hits the same wall once the pilot turns into daily operations.

What We Measured and What Surprised Us

The cost did not come from writing. It came from the agents rereading their context over and over: on average 12.7 million cache-read tokens against 202 thousand output tokens, or about 63 tokens read for every token written. The expensive model we suspected was never even running during generation.

We started from a simple question from our product owner and answered it by analyzing session transcripts line by line. Guessing would have led us to swap models, which would not have fixed anything.

63 Tokens Read for Every Token Written

An average agent run consumed 12,734,402 cache-read tokens, 833,199 cache-write tokens, 202,319 output tokens and only 375 fresh input tokens. In simple words, the model kept paying to reread the same documents instead of producing useful text.

One orchestrator run shows how this happens. It made 71 model calls in 22 minutes, and 21 of them were short no-action messages like "reading the brief". Its context grew from 17k to 91k tokens, and each call reread all of it. The 63:1 ratio is an average from our system and should not be treated as a universal ratio for language models.

The Expensive Model Was Never the Problem

The product owner asked whether to keep an expensive model on the orchestrator, because generation had "stopped losing steps" after it was switched on. The transcripts gave a surprising answer. A backend flag overrode the agent settings, and all 106 generation sessions used Sonnet.

Stability came from instruction fixes and a machine check at the end of the run, which we call the preflight gate. The model choice played no part. The orchestrator also made 23.5% of model calls while accounting for only 4.7% of cost, so it was never the place to save money.

A Measurement Trap That Doubled Our Costs

Our first numbers were wrong by roughly a factor of two. One model response is written to the transcript as several lines (text, reasoning, each tool call), and every line repeats the same usage data. Adding up lines gave $95.43 for one run, while counting unique responses gave $48.37.

We fixed the method by deduplicating on the response ID. The relative findings held, but the absolute numbers changed. The business lesson is simple: check how a number is calculated before you make decisions based on it.

Why More Agents Were Not the Answer

Adding more agents or a stronger model would have made the same mistakes more expensive. The agents were not struggling with hard tasks. They were struggling with the environment: signing API calls, finding files, parsing responses and inserting links one at a time.

We disagree with the popular idea that more autonomy means better automation. Our data shows the opposite for well-defined processes. The interlinker is a clear example: the backend had already chosen pages, anchors and relevance scores, so the model only had to weave links into paragraphs. That is a one-call job. It took up to 91 calls, 26 of them inserting a single link per edit, and across 24 runs the count ranged from 3 to 91.

Environment Errors, Not Hard Tasks

We counted 69 tool errors in 10 runs, about seven per generation. Errors appeared in 27 of 30 runs, and the final script had to be rerun in 11 of 30. The causes had nothing to do with task difficulty:

• environment variables lost between shell calls: 13;
• final script failures: 13;
• response parsing: 7;
• missing files at expected paths: 7;
• edits missing their target string: 6;
• network calls blocked by a security hook: 6;
• tool unavailable in a subagent: 4.

The interlinker also signed requests with an outdated scheme and got 401 errors, while its instructions pointed to a signing module that did not exist.

Invented Data and Drifting Formats

Some of the agents' "data" was invented. In 92 keyword subagent runs, not one received real Google data: the package was missing and the token was invalid. The model made up keywords and marked them "manual".

Competitor analysis was done by hand even though scripts for it already existed. The keywords.json file existed in four incompatible formats, and three signing schemes were in use at the same time. For a business, this is the most dangerous finding: an agent can hide broken integrations behind output that looks believable.

What We Changed in the AI Workflow Architecture

We replaced the network of agents with a deterministic pipeline. Code collects data, builds prompts, writes files, runs checks and routes work. The model makes one focused inference per phase, with no tools and a fully prepared context, and its output is validated before the next step starts.

For a non-technical reader, the principle reads as a straight line: Data -> Prepared context -> LLM -> Validation -> Result. The whole project, from analysis and implementation to benchmark, fixes and the production switch, took one working day. It produced 144 commits and 652 automated tests, and all live model runs cost about $82 equivalent, less than two agent generations of a long article.

The Model Only Does What Needs Meaning

In the new pipeline, the model spends tokens only on writing, translating and synthesizing meaning. Everything around that work is code. Scripts put the actual content into prompt templates, so the model no longer receives file paths and has to go looking for its inputs.

We also cleaned up what each call carries. After we turned off tools, hooks, plugins and MCP and set our own system prompt, overhead per model call dropped from about 9,000 input tokens to about 537, or about 950 when a JSON schema is attached. That cut matters because it repeats on every call.

Contracts, Validators and Retries With Feedback

An artifact contract fixes file names and JSON schemas and checks them on every write and read, so formats can no longer drift. A validator runs after every model phase. If it fails, the retry includes the validator report, and the model knows exactly what to fix.

Languages come only from the brief, with no hardcoded lists, and production is switched only after a benchmark on the same briefs. Rollback is a config value: generation.mode is set to agent or script, and switching takes one value and a worker restart. Both modes write the same artifacts, so an article generated in one mode can be corrected in the other.

One Shared Link Plan for All Languages

The writer, the translators and the check all use a single linking plan. Plain code verifies whether each link is present, duplicated, invented or pointing to another language's domain. The model is called only when something is wrong, and it receives a list of discrepancies instead of the whole task.

Before and After: How the Workflow Changed

Before, many agents interacted in loops with files, data, search, code and settings. After, the workflow is a straight line: prepare data, generate, validate, publish the final article. The business steps stayed the same. What changed is who does each step: code or the model.

The table below compares the two modes on the three benchmark briefs. Tool call figures for agent mode include the extra sessions briefs A and B actually needed.

Output tokens, the useful text, changed much less than cache reads. That confirms where the waste had been: in navigation and rereading, while the writing itself stayed roughly the same size.

The interlinker makes the difference concrete. In agent mode it averaged $4.52 per run. In script mode it cost $0 on all three briefs, because the writer inserted every planned link and the code check passed without calling the model at all.

We made one deliberate exception. Corrections requested from the CMS stay in agent mode. When an editor asks to change a term across the whole article, the script route has to return the full text, and that costs about as much as a translation. The agent's pinpoint edits are comparable or cheaper here, so we kept the tool that fits the task.

Results on the Same Real Workloads

On three real production briefs, the script pipeline cost $35.13 equivalent instead of $95.32 (2.71x less) and took 36.8 minutes instead of 94.2 (2.56x faster). Model calls fell from 197/163/117 to 13/10/6. Counting the reruns the agent mode actually needed, the gap reached 4.86x in cost and 4.40x in time.

We picked briefs with different configurations. Brief A covered en/de/ru, comprehensive, with all optional phases. Brief B covered ru/en/de, long, with keywords only. Brief C covered en/ru, medium length, with no optional phases. Agent data came from existing production transcripts. Script runs went through a replay backend that reads from production but writes nothing to it, and both modes used the same price table. We keep A, B and C anonymized.

Cost: From $95.32 to $35.13 Equivalent

Per brief, comparing the agent median run with the script run, the numbers were:

• Brief A: $44.49 vs $18.77;
• Brief B: $29.96 vs $12.11;
• Brief C: $20.87 vs $4.25.

These are equivalents based on public model pricing while the project operates under a subscription. They measure resource use and should not be read as a literal invoice. Validation retries made up about 29% of the script cost, or $10.3. Without them, we estimate about $24.9 for the three briefs, but this is an estimate and has not been measured separately.

Time: From 94.2 to 36.8 Minutes

Time dropped on every brief, with the biggest relative gain on the simplest one:

• Brief A: 38.2 vs 19.1 minutes;
• Brief B: 34.2 vs 13.1 minutes;
• Brief C: 21.8 vs 4.6 minutes.

The chart rounds the measured totals to 94 and 37 minutes. The 2.6x figure describes our pipeline on these briefs, and we would not present it as a universal speedup for AI projects. Your gain depends on how much routine work your current setup gives to the model.

Model Calls and the Reruns Nobody Budgets For

The number of model calls per brief fell from 197/163/117 in agent mode to 13/10/6 in script mode. Fewer calls means less rereading, fewer places for an environment error and a shorter path to a finished article.

Median runs hide the part that hurts budgets most. Brief A actually needed three agent sessions to finish: $119.23, 105.2 minutes and 593 model calls. Our best case, brief C, came out 4.91x cheaper and 4.72x faster in script mode.

The final step tells the same story. Agent mode needed 8 script reruns plus 2 worker restarts for brief A, 10 reruns for brief B and 1 for brief C. Script mode needed none. Every rerun also costs someone's attention: a person has to notice the failure, restart the job and check the result again.

When you budget an AI process, include the reruns. A plan built on the happy-path run will look good in a pilot and miss the real cost in production.

Reliability Improved Together With Cost

The cheaper pipeline also turned out to be more reliable. All script versions passed the final pre-publish check and included 100% of planned internal links. Deterministic checks also found defects that the agent setup had let through into already published articles.

Here cost and reliability did not compete with each other. Both improved for the same reason: routine work stopped depending on the model, so it stopped depending on the model's improvisation.

Defects Found in Already Published Articles

We ran the new link check on 23 published articles. It found 3 cases where a link listed in the linking report was missing from the text, 2 duplicate links to the same page and 23 URLs outside the planned page set. Page sets also differed between languages in 4 of 30 articles.

Two findings stood out. In one article, the English and Russian versions linked to a page on the German domain. In another, the linking report did not match the actual text, so the agent had reported work it had not done.

The illustration shows types of defects and says nothing about their frequency. For a multilingual site, such errors are costly: a wrong-language link breaks the user journey that a good web design agency plans with care, and a missing link weakens the page structure search engines rely on.

Self-Healing Rules and Failure Scenarios

Reliability in the new pipeline comes from explicit rules, which we wrote down before anything failed:

• a failed validation triggers a retry with the validator report, at most twice;
• an unavailable external system falls back to a backup source;
• a failed non-critical phase writes an empty artifact that matches the schema, and generation continues;
• a failed critical phase (text, translation, upload) stops the run with a clear reason;
• backend 5xx errors get 3 retries, and a 409 slug conflict is not retried.

We tested these rules in failure scenarios. With the search provider unavailable, generation continued, and the error was logged and categorized. When we removed a planned link from the German version, one correction inference restored it on the first try.

One scenario exposed a defect of our own. Rerunning only the German translation left the other languages untouched, but metadata and FAQ were recalculated for all languages. We fixed it. Finding problems like this in a controlled test is exactly why we benchmark before switching production.

What This Means for Enterprise AI Integration

The lesson goes beyond content. In any business process, including ERP and CRM integrations, the model should handle only the steps that need judgment or language. Data retrieval, API calls, checks, record writes and routing should be deterministic, measured and easy to roll back.

Outside research points in a similar direction. MIT Sloan research on how AI is reshaping workflows argues that the biggest value comes from redesigning whole workflows, and that every handoff adds coordination costs such as review and validation. Its focus is chaining tasks for AI, while ours is separating model work from code, but both judge AI by the efficiency of the whole process. Google Cloud describes a shift from assistants to agentic teams and a trend of layering natural-language interfaces over legacy systems such as decades-old SAP instances. That layer is exactly where deterministic integration work decides whether the AI is reliable.

Agents Are a Tool, Not the Default Architecture

Our position is direct: use agents when a task needs open-ended exploration, and design everything else as a pipeline. An agent is valuable when the path to the answer is unknown. When the path is known, code walks it faster, cheaper and with fewer surprises.

Andrey Popov, CTO and Founder of Webdelo, sums up the team's editorial position based on this project:

Agentic behavior is a tool we pick for a specific task. Our own pipeline showed that most of the cost came from agents rereading context and fighting their environment, while the writing itself was a small share. We give the model the work that needs meaning, and we make data, APIs, checks and routing deterministic, measured and reversible.

Andrey Popov, CTO and Founder, Webdelo

Our own case includes the counterexample. CMS corrections stay agentic, because whole-text edits in script mode cost more: $6.75 vs $5.12. Generation defects, on the other hand, are found by code in seconds. We choose per task, based on measurements.

Questions to Ask Before Scaling AI Automation

Before you scale an AI process, we suggest your team answers these questions with data:

• Where does the model really need meaning, and where is it doing routine work that code could do?
• What does one unit of the process cost, including reruns and manual restarts?
• How is quality checked by a machine before the result reaches a customer or a record?
• Are integrations with your ERP, CRM and internal APIs real and working, or is the AI covering for broken data with invented output?
• Is there a benchmark on the same real workloads, and a rollback switch, before production changes?
• Has anyone verified the measurement method itself, like the duplicate transcript lines that doubled our first cost estimate?

Rising AI spend is becoming a management topic, as McKinsey's analysis of how CIOs can manage AI demand at scale shows. The questions above turn that topic into concrete checks for a single workflow.

Limits of This Case and What We Would Test Next

This is a small, honest benchmark, and it does not prove anything universally. It covered 3 blog-type briefs and 7 corrections, used dollar equivalents instead of invoices and relied on a model to score quality instead of a human editor. We have not re-measured since fixing the gaps the benchmark revealed.

We also missed our own strict target of "4x cheaper" on a single run: we reached 2.7x per run and 4.9x per actual article with reruns. At the time of measurement, the first script generation through the production worker had not yet run.

Where the Script Version Fell Short

A model scored the drafts blind, as A/B, against a five-criterion editor checklist. The script version won on brief C (4.1 vs 3.7) and lost on brief A (3.6 vs 3.9) and brief B (3.2 vs 4.0). Losing two of three comparisons told us the pipeline was not ready as it stood.

We found and fixed specific causes:

• a model service phrase leaked into the article text;
• the FAQ ignored questions listed in the brief;
• the text came out 38% shorter than the agent version;
• the exact keyword was missing in the Russian version;
• all research sources landed in the lowest authority tier;
• "nothing to fix" correction requests went to the expensive agent mode.

Validation retries also ate about 29% of script cost, which is the next obvious target.

What We Would Test Next

Our next steps follow directly from the limits above:

• re-run the benchmark after the fixes on the same briefs, then on more content types;
• add human editorial scoring alongside the model scoring;
• track actual usage limits and the cost of production runs in script mode over time;
• reduce validation retries and find a cheaper way to handle whole-text corrections.

More content types matter because blog articles are only part of what the platform produces. Industry pages have different structure and stricter requirements, for example pages about real estate website development, appliance repair SEO or beauty salons SEO. We will publish only what the measurements support.

Planning AI Workflow Optimization in Your Company

If your AI automation works but is expensive, slow or hard to trust, the fix usually sits in the architecture, and a bigger model rarely helps. We apply the same method to client workflows: measure first, separate model work from routine code, validate, and compare on real workloads before scaling.

For mid-market B2B companies in the US and Germany, that approach to AI workflow optimization usually means working with systems that already run the business. Order data lives in the ERP, customer history lives in the CRM, and content feeds the website and digital marketing. AI has to fit into that landscape with clear inputs, checks and rollback.

Talk to our team about your AI workflow: we can help assess the process, design the architecture, integrate AI with your ERP/CRM or internal systems, and measure the economics before scaling. A typical engagement covers:

• Workflow audit: where the model adds meaning, where it does routine work and what one unit really costs, including reruns.
• AI assistant or agent architecture: a design that uses agents only where exploration is needed and deterministic steps everywhere else.
• ERP/CRM integration: working connections to your data and APIs, so the model never has to guess.
• Cost and reliability benchmark: a comparison on your real workloads, with a rollback plan before production.

When the workflow touches customer-facing systems, our Web Development team builds the integration layer with the same discipline of contracts, validators and measured releases. Budget is always discussed individually, after we understand the process.

Key Takeaways From Our Pipeline Rebuild

Our AI workflow got cheaper and more reliable once we stopped letting agents do routine work. On the same three briefs, cost dropped 2.71x and time 2.56x, and up to 4.86x and 4.40x when real reruns are counted. Deterministic checks also caught defects in articles that were already published.

The main lessons we took from the rebuild:

• Cost came from the environment. Agents reread context and fought file paths, signatures and parsing, with about 63 tokens read for every token written in our setup. The model price was a minor factor, and the expensive model was not even running.
• Agents are a tool. The model handles meaning: writing, translating, synthesis. Code handles data, APIs, checks, record writes and routing.
• Reliability follows structure. Contracts, validators, retries with feedback and one shared link plan made quality measurable and repeatable.
• Measurement needs checking too. Duplicate transcript lines doubled our first estimate, and fixing the method changed the absolute numbers.
• Limits stay visible. We report dollar equivalents, a small sample, model-based scoring and the briefs where the script version lost, and we keep a rollback switch in config.

These principles apply well beyond content. Any process that connects AI with an ERP, a CRM or internal APIs benefits from the same split between judgment and deterministic work, and from a benchmark on real workloads before anything scales.

If you are planning to automate a business process with AI, or your current automation costs more than it should, talk to our team. We will assess the workflow, design the architecture, integrate AI with your ERP/CRM or internal systems and measure the economics with you before you scale.