← All articles
- Chatbots
- Agentic AI
- Auditability
- Category Management
Ask the same question twice, get two answers: the reproducibility problem
Why AI cost analysis needs an audit trail, not better prompting.
By EXOS Research · · 9 min read
Two people, one supplier proposal, two different analyses
Here is a situation that will be familiar to anyone who has run a category alongside a demanding internal stakeholder.
You paste the supplier's proposal into a general-purpose model and ask what the real cost of ownership looks like over five years. You get a considered answer. Your engineering stakeholder, working from the same document, asks the model whether the pricing is reasonable given the specification. They get a considered answer too. The two answers do not agree, and neither of you can establish why, because the difference is not in the document. It is in the question.
You then spend the next meeting reconciling two AI-assisted analyses instead of deciding anything. This is a worse position than having had no tool at all. Both parties now hold something that looks like analysis and neither can be audited.
The output depends on who asked and how
A large language model without constraints is not a calculator with a conversational front end. It is a text generator whose output is conditioned on the entire prompt: the phrasing, the order of the information, what was emphasised, what was left out, what the previous message in the conversation happened to be.
That conditioning is a feature when the task is writing. It is a defect when the task is analysis, and it produces three problems in sequence.
| Failure | What it looks like | Consequence |
|---|
| Not reproducible | The same question in different words next week returns a different answer | No version, no fixed method, nothing to point at when someone asks how the figure was arrived at |
| Steerable, including unintentionally | "Is this proposal reasonable" invites a different answer from "what has this supplier left out" | The model accommodates whichever framing it is given, without indicating that a choice was made |
| Not resolvable on the merits | Two analyses conflict and neither has a traceable method | The argument reverts to seniority |
The third is the expensive one. Any procurement professional who has had a specification dictated by the loudest stakeholder in the room knows how that resolves.
Internal alignment is already the hard part
This matters more in procurement than in most functions, because the negotiation with the supplier is frequently easier than the negotiation with the business.
The requester wants the incumbent, for reasons that are half technical and half habit. Finance wants the number that fits the budget line. Operations wants the shortest lead time. Legal wants terms nobody will accept. Procurement's actual work is establishing a single defensible position out of that. The instrument that does it is a shared method — an analysis everyone can inspect, disagree with on specifics, and ultimately accept because the basis is visible.
A tool that produces a different answer depending on who typed the question does not support that work. It supplies each party with independent ammunition and no common ground. The technology has been introduced, and the coordination problem it was expected to reduce has been amplified.
In regulated procurement, reproducibility has become an obligation
The internal argument above is about persuasion. In financial services it is now also about evidence.
The Digital Operational Resilience Act has applied since 17 January 2025 to roughly 22,000 EU financial entities. Its third-party regime requires a register of every ICT contractual arrangement submitted annually to the competent authority, concentration risk assessed before entering an arrangement, and documented, tested exit strategies for arrangements supporting critical or important functions (Articles 28–30). The European Supervisory Authorities designated the first critical ICT third-party providers in November 2025, and during 2026 supervision moved from dialogue to formal compliance review.
An assessment that cannot be reproduced cannot be evidenced. A supervisor asking how a concentration judgement was reached is asking for the method, the inputs and the date — none of which a chat transcript supplies in a form that survives review. This is the same defect described above, met by a reader who is entitled to an answer.
The model does not check what it was given
A second problem, and in high-value work the more expensive of the two.
A general model has no view on whether the input is any good. Paste in a supplier's cost breakdown and it will analyse it. It will not ask whether the volumes are the ones actually purchased last year, whether the exchange rate assumption is current, whether the baseline is last price paid or list price, or whether the specification attached is the revision that was signed. These are the questions that determine whether the answer means anything, and they are exactly the questions an experienced buyer asks first.
To this add the model's own tendency to fill gaps. Asked for a total cost of ownership model on a fleet of industrial assets, it will produce a serviceable formula. It will not prompt for cost of capital, depreciation treatment, decommissioning obligations or the inflation assumption applied across the term. It generates plausible text, and where a variable is missing it will frequently supply a plausible one rather than flag the absence.
The characteristic failure is therefore not visible arithmetic error. It is a confident, well-formatted model resting on an assumption nobody stated and nobody checked. That is difficult to catch in review precisely because it reads correctly.
Constraining the model is an engineering decision, not a prompting skill
The response to all of this is not better prompting, and it is not a longer system prompt. It is narrowing what the model is permitted to do.
In a system built for this work the model reads unstructured material — contracts, proposals, specifications, market commentary — and extracts variables. Those variables pass into a calculation layer where the arithmetic is performed by fixed logic.
| Task | Handled by | Why |
|---|
| Reading a contract, proposal or specification | Language model | Unstructured text, high variation, no single correct output format |
| Extracting variables from that text | Language model, with the extraction schema fixed | The schema constrains what may be extracted; the model only locates it |
| Performing the calculation | Fixed logic | The same inputs must return the same figure, on any day, for any user |
| Presenting and explaining the result | Language model | Explanation is a language task |
The consequences are the ones a chat interface cannot offer. The method is fixed, so two colleagues starting from the same inputs reach the same figure. The inputs are explicit, so a disagreement can be located in a specific assumption rather than in the tool. And the analysis can be re-run when a variable changes, which is what makes it usable inside a negotiation rather than only before one.
None of this is visible from outside, which is why chat interfaces and analytical systems are so often compared on the quality of their prose.
Where the market is going, with the failure rate attached
The direction of travel is not much disputed. Gartner's August 2025 forecast put 40% of enterprise applications integrating task-specific AI agents by the end of 2026, against under 5% at the time.
The same firm expects a substantial share of agentic AI projects — on its estimate over 40% — to be cancelled or paused by the end of 2027. Both figures belong in the same paragraph. Task specialisation is where enterprise software is heading, and specialisation is hard enough that many attempts will not reach production.
The general model remains the right tool for language work
Summarising a long contract, drafting correspondence, extracting clauses, producing a first comparison of two texts: these are language operations and general models are good at them. Nobody using them this way is mistaken, and this is not an argument for using them less.
It is an argument against transferring confidence from that category to the other one. Fluency in the first is not evidence of reliability in the second, and the interface offers no indication that the boundary has been crossed.
Where EXOS sits
EXOS is a scenario-based procurement analytics system: it models total cost of ownership, negotiation scenarios and supplier risk before a contract is awarded. Language models are used within it for what they are suited to, with the arithmetic held in fixed logic behind them, so that the same inputs produce the same analysis regardless of who opened it.
Where this sits among the other classes of procurement AI → · Six kinds of procurement AI, as we see them →
Sources:
Market forecasts: Gartner — Gartner Predicts 40% of Enterprise Apps Will Feature Task-Specific AI Agents by 2026 (26 August 2025) · Gartner — Over 40% of Agentic AI Projects Will Be Canceled by End of 2027 (25 June 2025)
Regulatory: Regulation (EU) 2022/2554 (DORA), Articles 28–30 · ESAs designate the first critical ICT third-party service providers under DORA (November 2025)