A company can have several successful AI demonstrations and still have no clear answer to a more important question: which one deserves the next pound of investment?
One pilot produces a better answer. Another saves time in a single team. A third promises a shared agent platform that might support both. Each sponsor can describe progress. The same engineering, security and operating teams are expected to make all three production-ready.
AI pilot investment needs a portfolio decision, not a collection of enthusiastic project updates.
In brief: fund the next piece of decision-useful evidence, account for shared constraints and agree stop criteria before results arrive. Separate stopping an experiment from rejecting AI. Scale only when the proposed next stage has a credible outcome, owner and operating capacity.
This is a practical funding framework for founders, CTOs and enterprise operators. It is not a claim that any particular allocation method guarantees returns.
This week's research points beyond adoption
In HBR's 21 October article on AI deployment failures, Justine Hastings, Chad Syverson and Seth Zimmerman argue that gains within separate functions can miss the coordination work between them. The accessible public summary supports that distinction. It does not provide enough methodological detail to treat its headline coordination statistic as a universal planning assumption, so no such percentage is used here.
Amii Barnard-Bahn's HBR article on 23 October identifies another problem: executives either monopolising decisions or withdrawing from decisions outside their specialism. Its public summary is management analysis, not a controlled estimate of investment performance.
A 21 October GRC Report analysis revisits KPMG's Q3 Global AI Pulse survey. The primary KPMG release is dated 24 September, not this week. Based on a survey of 2,131 senior leaders across 20 countries, it reports that 12% consistently assess AI value against cost across the organisation, compared with 48% among those reporting established returns.
Those are self-reported survey findings from a professional-services provider. They do not prove that measurement causes returns or establish a target budget for a smaller SaaS business.
Taken together, the sources suggest a useful question for the next funding meeting: does the organisation know how to compare its AI options, including the work they impose on other teams?
Ask what the next tranche will resolve
“Continue the pilot” is too vague to be an investment request.
Ask for the uncertainty that the next tranche will reduce. It might concern customer demand, integration reliability, review capacity or the feasibility of an important policy boundary.
Define the evidence to be produced, the cost and time limit, the decision date and the possible decisions afterwards. The output should help someone choose between stopping, redesigning, extending or scaling.
For example, a support-triage pilot might request funding to test whether the proposed routing works on representative cases without increasing downstream transfers. It should not present better classification on a convenient sample as proof that the entire service should be automated.
Distinguish a learning objective from a production commitment. An experiment can succeed by showing that an approach is unsuitable before the business pays for a larger implementation.
The discipline is similar to turning uncertainty into a delivery plan, but the decision here is comparative: what evidence is worth buying next, given the other demands on the business?
Compare outcomes without pretending every pilot is identical
Do not rank unrelated pilots solely by hours saved, model accuracy or the number of active users. Those measures answer different questions.
Give each proposal a clear business outcome and a baseline. State who benefits, which costs change and which service or risk constraints must remain intact.
Then use a common decision format rather than a forced common metric. Compare the size and credibility of the opportunity, the remaining uncertainty, the cost of the next stage, implementation dependencies and reversibility.
A compliance experiment and a revenue experiment need not claim the same kind of return. They still compete for people, time and executive attention. Make that competition visible.
Use ranges where evidence is weak. A precise spreadsheet based on an unsupported adoption assumption is less useful than an honest range with a plan to test its most influential variable.
For customer-service proposals, the resolved-case unit economics guide explains the underlying cost calculation. Portfolio review asks the next question: even if the calculation is credible, is this the best next use of constrained delivery capacity?
Account for shared capacity only once
Several pilots can each claim the same released capacity.
An assistant reduces preparation time, a knowledge tool reduces search time and a scheduling agent improves allocation. If their estimates all assume the same staff hours become available, adding them together overstates the combined benefit.
Map overlapping users, workflows and dependencies. Ask what remains after the first intervention has changed the baseline for the second.
Apply the same discipline to costs. Shared infrastructure should not disappear from every business case because a central team pays for it. Equally, charging its full cost to every pilot can make useful work look uneconomic.
Show an agreed allocation alongside the incremental cost of adding the next workload. Explain which costs are fixed for the period, which grow with use and which increase in steps when capacity is exhausted.
Include scarce human capacity. Security review, integration engineering, legal assessment and operational training may constrain the schedule more than model expenditure.
A portfolio that funds six pilots but can support only two safe production launches has not funded six credible delivery plans.
Put the right disagreement in the funding meeting
HBR's warning about executive control and disengagement is relevant here. Technical leadership should not decide workforce consequences alone. Nor should a commercial sponsor approve production scope while leaving operating risk for someone else to discover.
Assign one accountable decision owner, with explicit input from the people who control the affected resources and consequences.
The service owner should explain whether the proposed outcome matters. Engineering should explain integration and maintenance needs. Finance should challenge benefit conversion and shared costs. Security and relevant compliance specialists should identify boundaries. People responsible for the work should explain training and workload effects.
This is not a requirement for unanimous approval of every experiment. Set proportionate decision rights and identify which objections represent a mandatory constraint rather than a preference.
Record unresolved assumptions and who will test them. Avoid replacing disagreement with a blended confidence score that nobody can explain.
The coordination-layer article covers cross-functional workflow design. A portfolio review needs a related but distinct discipline: deciding which change the organisation can responsibly support next.
Make stopping rules specific and usable
Agree stop criteria before the team has spent months defending the project.
Useful criteria might include inability to establish authorised data access, unacceptable unresolved actions, a benefit too small to justify the next stage or a dependency that cannot be delivered within the business window.
State the conditions rather than borrowing arbitrary universal thresholds. A workflow changing customer records needs different evidence from a private drafting assistant.
Separate a hard stop from a redesign trigger. A failed assumption may justify narrowing the use case rather than ending all work. An integration constraint might support an assisted workflow instead of autonomous execution.
Specify what an extension can buy. An extension should test a named unresolved question within a bounded cost, not simply postpone the decision.
Make closure operational. Retire access, resolve outstanding work, preserve required evidence, communicate the outcome and stop recurring expenditure. Capture what was learned so that a later team does not pay to rediscover the same constraint.
Stopping should release resources deliberately. Otherwise the organisation can accumulate a portfolio of officially paused experiments that still consume subscriptions, maintenance and attention.
Do not fund an abstract platform to rescue weak use cases
Shared infrastructure can be valuable. It can also become a way to avoid admitting that a pilot lacks a compelling outcome.
The 22 October AAIF expansion and The New Stack's reporting on Open Responses show an ecosystem developing common interfaces and reusable components. These are infrastructure developments, not evidence that every business needs to build its own agent platform.
Ask which proven workloads require the shared component, what duplication it removes and who will maintain it. Distinguish an interface standard from identical provider behaviour or universal support.
Where possible, test a thin shared capability against real workflows before approving a broad platform programme. Keep the option to use established components or a simpler deterministic service.
The Omningage case study offers product-building context. It should not be read as a financial benchmark for a new AI investment or evidence that the hypothetical portfolio in this article exists in those businesses.
Run the next review as a decision session
Before the meeting, ask each sponsor for a one-page proposal: outcome, baseline, evidence obtained, next uncertainty, next-stage cost, shared dependencies, operating owner and stop or scale conditions.
Review the portfolio together. Identify overlapping benefits and constrained teams before approving individual requests.
For each pilot, record one explicit decision:
- Stop: the opportunity or feasibility does not justify further spending.
- Redesign: preserve the valuable problem but change the scope or approach.
- Extend: buy specific missing evidence within a defined limit.
- Scale: fund a specified production stage with capacity, ownership and acceptance criteria.
Do not treat “scale” as approval for unlimited rollout. A staged commitment preserves the ability to learn as the workload, supplier or operating context changes.
Review outcomes at the agreed date. Compare them with the decision assumptions, not only with the latest presentation. Reward teams for exposing an uneconomic idea early as well as for delivering a viable one.
For the surrounding architecture and governance, follow the Agentic AI topic hub. My technology transformation and delivery approach connects discovery and proof of value to implementation. Discuss a bounded delivery brief if the next funding decision needs clearer technical evidence.
The aim is not fewer experiments for its own sake. It is a portfolio in which each additional commitment has a reason, an owner and a credible route to an operating result.
Sources and evidence notes
- HBR: The Deployment Failure Holding Back Your AI Investments, Justine Hastings, Chad Syverson and Seth Zimmerman, 21 October 2026. Accessible public summary and introduction only; summarised without reproducing paywalled text.
- HBR: C-suite decisions that stall AI transformation, Amii Barnard-Bahn, 23 October 2026. Descriptive reference to the public summary used for the leadership distinction.
- KPMG: Q3 Global AI Pulse survey release, 24 September 2026. Provider-published survey of senior leaders, not a causal evaluation.
- GRC Report: KPMG survey finds investment rising as companies struggle to measure returns, 21 October 2026. Recent coverage of the earlier survey, not a new October field study.
- AAIF: Four new projects, 22 October 2026. Primary announcement about open agent infrastructure.
- The New Stack: OpenAI donates Open Responses, Frederic Lardinois, 22 October 2026. Technology reporting; the publication discloses owner investments in OpenAI, Anthropic and Databricks.
Sources checked on 26 October 2026. The funding framework and examples are original recommendations, not reported results from Ahmad Nizami's businesses.