Ask an organisation which of its AI uses has a measurable return and the answer is rarely the assistant everyone has. It is usually something nobody outside the team has heard of. A model that reads non-standard supplier invoices and proposes the match. A step that summarises a case file before a person decides. A classifier that routes incoming queries to the right queue. These uses do not make good keynote slides. They do tend to show up in the numbers.
That is not a coincidence, and it is not because narrow uses are cheaper. It is because they are built in a way that makes value both more likely and easier to see. A narrow, embedded use starts with a process that already has an owner, a volume, a baseline and a definition of a correct result. A horizontal assistant starts with a tool and hopes people find a process for it.
Part 1 showed how minutes saved by a general assistant leak away before they reach the income statement. This part looks at the other end of the spectrum: what makes a use case narrow, embedded and boring, why that combination works, how to choose one, and what the evidence does and does not show.
Tsitsikamma Hardware Group is fictional, and its systems and figures are illustrative.
Two patterns, two budgets
Most enterprise AI spending falls into one of two patterns.
The horizontal assistant is a general tool given to many people: a chat interface, an assistant in the office suite, a coding assistant. Each person decides what to use it for. The organisation sees usage, not outcomes, because the outcomes are scattered across thousands of small tasks that were never measured individually. AI consumption is not AI value explains why the usage dashboard then gets mistaken for a value report.
Embedded workflow AI is built into a specific step of a specific process. The process owner chose it. The step already has volumes, cycle times and error rates. Every output is checked by a rule, a match against a system of record, or a named reviewer. When it works, a measure the business already tracks moves.
Horizontal tools are easier to buy and roll out, which is why they dominate budgets. Embedded uses are harder to build, because they require integration, a check and process change. That difficulty is exactly what makes them provable.
What the evidence suggests, and what it does not
The best-known controlled study of an embedded use is Brynjolfsson, Li and Raymond's Generative AI at Work, later published in the Quarterly Journal of Economics. It followed more than 5,000 customer-support agents at one company as an AI assistant that suggested responses was rolled out inside their existing support tool. Access to the tool increased issues resolved per hour by 14% on average, with the largest gains among novice and lower-skilled agents and minimal effect for the most experienced. Customer sentiment and employee retention also improved.
Notice the shape of that use. One task, inside the system where the work already happened, measured with a metric the operation already tracked, against a baseline. It is narrow, embedded and boring.
At the other end, the widely quoted claim that most generative AI pilots produce no return comes mainly from MIT NANDA's July 2025 report The GenAI Divide: State of AI in Business 2025, as reported by Fortune. The report was labelled preliminary, drew on interviews, a survey and a review of public implementations (secondary accounts of the sample sizes differ), and measured success narrowly, as measurable profit-and-loss impact. Its own framing was that only about 5% of integrated pilots were extracting significant value. Critics have pointed out that this definition excludes efficiency, quality and many other kinds of gain. The figure is better read as "few organisations can show P&L impact from custom AI" than as "AI does not work".
Two honest caveats apply to the narrow-and-embedded argument as well:
- Selection bias. Narrow uses are easier to measure, so the successes we can see are disproportionately narrow. Horizontal tools may be producing value that nobody measured. Absence of evidence is not evidence of absence, for either pattern.
- Survivorship. Published case studies describe the uses that worked. Narrow projects fail too, usually on integration cost, data quality or a process that changed underneath them.
The case is therefore not that narrow uses always win. It is that narrow, embedded uses are the ones where an organisation can find out whether it is winning, and adjust quickly if it is not.
Why boring works
Four properties do most of the work.
A defined correct answer. An invoice either matches the purchase order and delivery note or it does not. A query either went to the right queue or it did not. When correctness is defined, quality can be measured, and the evaluation that gates real work can be built from historical examples.
A cheap check on every output. Embedded uses usually sit next to a system of record that can confirm the result: totals add up, the product code exists, the account is active. Errors are caught before they cause harm, which means the use can be trusted at volume.
A baseline that already exists. The process was being measured before the AI arrived, so the before-and-after comparison is real rather than reconstructed from memory.
An owner who answers for the result. A process owner, not a tool owner, decides whether the use stays. That person cares about the process measure, not about adoption.
Tsitsikamma's three boring uses
After the review described in Part 1, Tsitsikamma moved most of its AI budget out of the general rollout and into three narrow uses.
Supplier invoice matching. About a fifth of supplier invoices arrive in formats the accounts-payable system cannot read automatically, so a clerk keys and matches them by hand. A model now extracts the fields and proposes a match to the purchase order and goods-received note. A rule checks totals, VAT and quantities. Anything that does not reconcile goes to a clerk with the discrepancy highlighted. The measure is invoices processed per clerk-day and the exception rate, both already tracked.
Product data for the online catalogue. Suppliers describe the same product in dozens of ways. A model normalises descriptions into the catalogue's attribute set, and catalogue rules reject anything with a missing size, unit or category. The measure is time from new product to listed product.
Credit-application summaries. The constraint identified in Part 1. A model assembles the bureau extract, payment history and account notes into one summary for the credit officer, who still decides. The measure is applications cleared per day, which is also completed trade orders.
None of these would interest a conference audience. Each has a baseline, an owner and a check. The general assistant was kept, but reclassified as a cost of doing business with a smaller licence count.
Seven tests for a use case worth embedding
Tsitsikamma now screens new AI proposals with seven questions, answered by the process owner rather than the technology team.
A use case does not have to pass all seven to be funded, but every failure must be named in the business case along with how it will be addressed. "Not yet measured" can be fixed by measuring for a month before building. "No owner" usually cannot be fixed, and is a good reason to stop.
The tests also explain why horizontal rollouts are so hard to justify on value. A general assistant is frequent, but its tasks are not bounded, not cheaply checkable, not measured in advance and not owned by anyone who answers for the result. It usually fails at least four tests at once, which is why its value has to be argued rather than shown.
Where to look first
Narrow, embedded opportunities are usually hiding in three places:
- Exception queues. Work that the existing automation cannot handle and drops into a person's queue: unreadable documents, mismatched records, ambiguous requests. The volume and handling time are already known.
- Assembly before a decision. A person spends most of their time gathering information from several systems before making a judgement that takes a few minutes. AI can assemble; the person keeps the decision, as in The human in the loop must show their work.
- The constraint. Whatever step limits the throughput of a process that matters, as Part 1 showed with credit approval.
Start with one. Measure for a month before building. Build the check before the model. Then decide on evidence whether to scale, redesign or stop, using the criteria in When should an organisation stop funding an AI use case?.
Next: Part 3, Sovereign AI or sovereign spend? A procurement test for governments. All parts are on the series page.
How CloudNala can help
We help process owners find the narrow, embedded AI uses in their operations: exception queues, decision assembly and process constraints. We screen candidates against the seven tests, establish the baseline before anything is built, design the check that sits next to the model, and set up the measure the process owner will use to decide whether the use stays.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an AI Value Review or write to us at consult@cloudnala.co.za