A lot of enterprise AI pilots stall below the model, in the systems they have to read from and write to. I call that layer the substrate: the data, permissions and system contracts a workflow runs on.
That's my argument, not a survey finding, but the numbers leave room for it. In McKinsey's 2026 State of AI survey, nearly nine in ten respondents report regular AI use in at least one business function. Only 37% attribute any EBIT impact to it, and about 6% clear the high performer bar. These are self-reported shares of respondents, and not reporting impact doesn't mean a program is stuck. Still, that figure barely moved. It was 39% in the 2025 edition.
Leadership tends to buy AI as an application. Engineering inherits it as an infrastructure tax: integration, data work and review that the application's price doesn't show. EY estimates tokens are roughly a third of what an agent costs to run. That's a consultancy estimate and your ratio will differ, but I wouldn't budget from a per-token price.
Accuracy hides cost too. Take a hypothetical: 95% per clause, eight clauses, independent errors. 0.95^8 is 66.3%, so roughly a one-in-three chance of at least one extraction error per contract. Someone has to pay for the checking.
What I'd propose is a layer between the model and the backends, which I call the Substrate Adapter Pattern. It's my composition of existing patterns, not an established one, and no source I've found measures its results.
- Normalization gate. A deterministic proxy turns messy legacy data into validated, typed records before the model sees a token.
- Execution sandbox. Every tool call is a non-binding proposal. A deterministic gateway checks permissions, business invariants and an idempotency key, then stages the change in an outbox. Above a risk threshold, a person signs off.
- Scoped steps. Narrow, single-purpose steps instead of one general agent, each with a check you can test, so you can see which one failed.
This doesn't make answers correct. A typed schema proves shape, not meaning. If the assistant proposes a valid credit on the wrong account, idempotency just guarantees it's applied exactly once. That still takes agreed definitions, data quality work and business review.
Before a pilot gets more budget, I'd start here:
- Price the verification. You can't check only the wrong outputs, because you don't know which ones they are.
- Make write tools proposal-only. Any direct POST, PUT or DELETE without an idempotency gateway gets converted.
- Track cost per verified transaction against your pre-AI baseline, with model fees, infrastructure and review time included.
Towards AI published the full article, and thanks to them for taking it. It has the diagrams, the sources and the complete checklist: https://pub.towardsai.net/the-substrate-trap-why-enterprise-ai-use-outruns-its-ebit-impact-6de1f29e6606
