Make Reusable AI Work Earn Its Build Cost

A preprint from City University of Hong Kong, submitted on 2 October and included in arXiv’s 5 October release, studies when repeated computer-use tasks should become programs. Its PACE system accounts for unsuccessful build attempts as well as successful ones, and considers whether future use can repay that cost. ¹

The evidence is narrow: seven task families, three model profiles and simulations using measured costs. Its live study does not evaluate the full decision algorithm. Token savings are not a measure of enterprise profit, and the cost constraint does not guarantee task success. The useful signal is the question being measured, not a universal payback number. ¹

A separate JPMorgan Chase research paper illustrates another option: route suitable financial-chat cases through rules and reserve a language model for harder cases. The authors describe institution-specific data and adaptation requirements; the confidential source conversations prevent direct external replication. This supports testing a mixed approach, not copying its reported savings into another business case. ²

The management gap is broader than either experiment. KPMG’s Q3 survey covered 2,131 senior leaders in 20 countries, territories and jurisdictions, with fieldwork from 23 July to 26 August. Its release says only 12% consistently assess AI’s value against cost. This is reported practice in that sample, not audited returns or proof of causation. ³

Start with the current cost of completing an eligible case acceptably. Include model use, staff checking, retries and correction. Compare it with the proposed routine using the same case mix and acceptance standard. A faster output that transfers more checking to another team has not necessarily lowered the organisation’s cost.

Next, estimate the investment required to make the routine usable. Include development attempts that fail, integration, test cases, security review and the time of the people who understand the process. These costs do not disappear because an AI system writes much of the code. Record them separately from ongoing costs so the business case can be challenged.

An illustrative calculation makes the test concrete. Suppose a routine costs 1,000 currency units to build and validate, then saves two units on each acceptable case after recurring checks and exceptions. It needs 500 such cases to recover that initial cost, before any additional maintenance. These are invented numbers for explanation, not research findings or a suggested target.

Now shorten the expected useful life. If only 300 qualifying cases are likely before the underlying process changes, lower execution cost alone cannot repay that investment. Conversely, reliable high-volume work may repay a more expensive build quickly. The decision turns on valid reuse and net savings, not the number of automations delivered.

A working routine needs a boundary. Specify the applications, inputs, permissions and business rules under which it has been tested. A change in any of these may require revalidation. Assign an owner who can notice that change, suspend the routine and restore an approved alternative. A low-cost process that quietly produces the wrong result is not an efficient process.

Do not pool international volume until the work is genuinely comparable. An English-language routine tested in one North American business unit has not thereby passed on French documents, Arabic interfaces or a Latin American subsidiary’s records. Across European, Asia-Pacific, African and Middle Eastern operations, local formats, language and systems can change how much work is eligible. Test those differences rather than assume a regional adoption rate.

Legal and institutional differences belong in the eligibility decision too. Have the relevant teams establish whether the proposed data use, permissions and retention are allowed for that workflow. This brief makes no claim that approval in one jurisdiction travels to another. Restricted data access or unavailable integration may change the available design before cost comparisons even begin.

Buying an existing integration may beat building a routine around a changing screen. A managed service may offer support that an internal script lacks, while also adding fees or dependency. Compare the actual alternatives, including keeping a human step. Where work is infrequent, highly variable or consequential, retaining flexibility can be the economically sensible choice.

Choose one frequent routine with a clear definition of acceptable completion. Observe a representative set of cases before selecting only the easiest examples. Keep a record of the cases excluded, and why. That record defines the market for the proposed automation inside the organisation.

Set a capped development budget and a review point. Measure the complete cost of the current method and the candidate routine, including maintenance observed during the test. Separate measured use from forecast demand. Finance should be able to see which assumptions would have to change for the investment to stop paying back.

Then choose among building, buying, continuing with the agent or stopping the task altogether. Require a named operating owner and an approved fallback before expanding use. Revisit the decision after a material process or system change. The investment has earned its place when useful repetition repays the work required to make it dependable.