When Custom Software Gets Cheaper, the Work Moves to Trust

For decades, most enterprises bought packaged software and bent their processes around it. Custom software was costly to build, integrate and maintain, so the package usually won.

AI is changing part of that sum. Frontier models and coding agents make it cheaper to build something shaped around an organisation’s own data, workflows and rules. It is tempting to conclude that the hard part is now easy. This note argues that the hard part has moved.

Cheaper building shifts the work to everything around it

Early public evidence suggests demand is moving, though the figures are not directly comparable. Each firm defines its own AI measure, and each is self-reported.

Read together, these show that AI work is growing quickly at firms that report it, and that a sizeable share of organisations are already weighing build against buy. They do not show that the market as a whole will grow, or that new demand will outweigh the delivery effort AI removes. That is a forecast, not a finding.

The McKinsey result cuts both ways. Fewer purchased products means more things an organisation must now own. When a vendor’s product is replaced by an internal build, the controls the vendor carried do not vanish. Access models, upgrade paths, audit evidence and incident response land on the buyer.

Package selection and project delivery assumed someone else held the controls

A packaged product arrives with a permission model, a release cadence, a support contract and the scrutiny of many other customers. A bespoke agentic solution arrives with whatever its builders decided. Agents add a second difference: they can propose actions, not only display data.

Conventional delivery measures such as features shipped, tests passed and go-live achieved do not show whether the solution knows which record is current, who authorised an action, or what evidence survives afterwards.

Illustrative scenario: a fictional composite written to make the point concrete. It does not describe a real organisation, and its figures are not reported outcomes.

A regional insurer builds an assistant around its own claims notes and policy documents. It performs well in the demo. In the first week of use, three questions arrive. Which policy wording did the assistant apply to a claim lodged before a wording change? May it read notes the fraud team has restricted? And who approved the payment it proposed above the adjuster’s limit? A package would have answered each from its documented design. The bespoke build answers them only if someone decided them.

CAE reads this as four decisions that have to be made on purpose

The Contextual Agentic Enterprise (CAE) is the author’s proposed framework, a vendor-neutral architecture and operating model for letting people, models, agents and systems act together under delegated authority, with evidence. It is not an industry standard. Applied to a custom build, it asks for four decisions:

• Context. What may the agent receive for this purpose, from which sources, and how fresh must they be? A Context Contract is a declared, versioned specification of exactly that.
• Authority. What may it propose or do, with which tools, up to which values and for how long? An Authority Envelope states those bounds.
• Commitment. Before a proposal becomes an effect on money, records or messages, a deterministic check of current state and authority sits at the Commit Boundary. The model proposes; the shell decides.
• Evidence. Can the decision be reconstructed later without trusting the model’s own explanation? An Evidence-First Decision Record keeps claims, policy decisions, approvals and outcomes separately retrievable.

The principle underneath is probabilistic reasoning, deterministic control and governed enterprise action. For the longer treatment, see the Contextual Agentic Graph and Evidence-First Decision Records.

A build-or-buy test should price the trust work too

For each workflow, not each organisation, work through these steps.

1. Name the workflow and the outcome it must support. A vague “AI assistant” cannot be costed or governed.
2. List the data it needs and who may see each part.
3. List the actions it could propose, and mark those that change a record, move money or send a message.
4. List the controls a vendor would have supplied (permissions, audit trail, change notice, support) and name who now owns each.
5. Run an exit test: could the organisation replace the model, the platform or the builder without rebuilding the controls?
6. Decide workflow by workflow. A mixed answer is normal: buy what is commodity and build what differentiates, keeping the same four decisions in both.

The test prices the trust work as a line of its own. It does not claim that building is cheaper or dearer than buying; that depends on the workflow.

Where cheaper building goes wrong

• Treating build cost as total cost. Building is the first bill. Running, governing and changing the solution continue after it.
• Inheriting the demo’s defaults. A generator supplies a plausible answer to every design question, including questions nobody asked.
• Access mistaken for authority. A credential that can read a record does not confer a mandate to act on it.
• No owner after handover. The delivery team leaves and nobody holds the change log, the tests or the incident route.
• Evidence rebuilt from chat logs. The first audit question arrives and the record is a conversation transcript.
• Overreading the market numbers. Self-reported, firm-defined figures are context, not a business case.
• Delivery that outruns the client. A partner builds what the organisation cannot operate or explain.

What each role should do

Executives decide. Which workflows justify a bespoke build, who is accountable for each after go-live, and what level of residual risk is acceptable. Ask suppliers, internal or external, to state which controls they are providing and which they assume the buyer holds.

Architects design. The four decisions as written artefacts before build, with the tenant boundary, the data paths and the point where an action commits. Design for the exit test from the start.

Engineers implement and test. Contract tests for each boundary, a record of every proposal and its outcome, and a failure path for the case where a call may already have succeeded. Retire generated defaults that nobody chose.

Where the work moves

This is a CAE interpretation of where responsibility typically falls. Contracts and products vary.

Key takeaways

• AI lowers the cost of building bespoke software, but the integrating, securing, governing and operating work remains and may grow.
• The public figures reported so far are firm-defined and self-reported, so they are context, not proof of market-wide growth.
• When a bought product is replaced by an internal build, the controls the vendor carried transfer to the buyer.
• CAE proposes four decisions to make on purpose for each workflow: context, authority, commitment and evidence.
• A build-or-buy decision should price the trust work as its own line and include an exit test.

Sources and further reading

• EY (8 October 2026) “EY global revenue increases 4.7% to US$57b for fiscal year 2026”, press release.
• Tata Consultancy Services (8 October 2026) “International Growth and Strategic Wins Underpin TCS’ Q2”, press release.
• Infosys (23 October 2026) “Q2 FY27 results press release”.
• McKinsey & Company (August 2026) “The state of AI in 2026: On the road to ROI”.
• Related on this site: the Contextual Agentic Graph and Evidence-First Decision Records.

Where Contextual Agentic could help: a proposal

Contextual Agentic (CA) is an independent initiative built around the CAE framework. What follows is a proposal, not a description of existing engagements. No clients, results or partnerships are claimed.

Directly with an organisation. CA proposes to help a team apply the four decisions to one workflow: a review of the Context Contract, Authority Envelope, Commit Boundary and evidence design before or during a custom build, together with workshops and training for the people who will own it.

With consulting and services partners, to accelerate delivery. CA proposes to supply the reference framework, shared vocabulary, review checklists and diagrams that a delivery team can adopt, while the partner supplies engineering capacity, industry knowledge and the client relationship. The working hypothesis is that agreeing the control questions early may reduce rework later. That is a hypothesis, not a measured result.

To discuss either, use the contact page, choose the advisory work subject and say whether you are an organisation or a services partner. Scope and terms would be agreed case by case.

The book The Contextual Agentic Enterprise develops these ideas at length.

This article is part of CAE Field Notes, a series accompanying the book, The Contextual Agentic Enterprise.