Solving the AI Adoption Problem

The diagnosis: people want the work done, not a tool

The piece opens on why pilots fail, and the line is sharp: "AI users aren't in the market for a tool to help get work done. They just want the work to be done." Most enterprise AI still ships as a copilot or chatbot the employee has to pick up, learn, and fit into their day.

That makes employee adoption the bottleneck for any financial return, because the value only lands if people actually change how they work. His number for where most companies land is a 25-30% adoption rate.

The reason is habit, not stupidity. If someone has done accounts payable the same way for ten years, a new chat window will not break that groove. They will treat it as one more tab to ignore.

The reframe: outcomes-as-a-service, not interface-as-product

His pivot is the keeper sentence: "SaaS was the era of the interface; enterprise AI is the era of outcomes as a service." When a company bought a CRM, the interface was the product, because people needed a place to do the work.

His claim is that in an age of cheap intelligence, companies do not want a place to do the work, they want the work done. So instead of selling a tool, sell the outcome and let it happen in the background.

This is the same shape as service-as-software (the deliverable is a service, the execution runs through software), told from the delivery end rather than the agency-economics end.

Principle 1: build where the work already happens

The first of his two principles: if the workflow runs through NetSuite, build on top of NetSuite; if it runs through Salesforce, build there. The system may be old and legacy, but it is where the business actually runs.

So the agent reads from it, acts inside it, and writes back to the system of record the business already trusts. Where there is an API, build on the API. Where there isn't, use a computer-use agent — an agent that drives the screen like a person, clicking and typing.

His accounts-payable example is concrete: rather than asking finance to open a new platform, they put the agent on top of NetSuite and the manual parts of the workflow started getting done underneath. The employee kept working exactly where they always worked.

Principle 2: background autonomy with a control plane

The second principle answers the obvious objection, that pushing AI into the background takes control away from the client. His answer is a control plane for the process owner: one screen showing which agents are running, with the ability to pause a workflow, change a permission, or pull an agent back without writing any code.

On top of that, governance is embedded in the agent itself. Every run pauses before a consequential decision and asks whether a human is needed. If so it notifies that human where they already are (email, Slack), references internal policy, and acts as a human would.

The general name for this is a point of control: a gate that resolves policy, permission, and human approval before an action executes, rather than auditing it after.

The services bet: why back-office work needs people on site

His honest structural claim is that this is a services business, not a pure product. Coding is universal, so a coding agent can be generic. Procurement and operations are not universal, because every company does back-office work slightly differently.

Those differences only get captured by sending forward-deployed engineers — engineers who sit on the client's site for weeks to absorb the workflow and the tribal knowledge. That is an expensive, high-touch delivery model.

It also quietly limits the "it just happens" promise. If every deployment needs weeks of on-site context capture, the magic is bought with labour, not conjured by the model.

Read it as a sales doc, and run the counter-take

The post ends by booking August engagements for companies doing over $1B in revenue, which tells you what it is: a pitch, not a neutral study. The architecture is sound and corroborated elsewhere, but the ROI claims ("an explosion in adoption," "major ROI gains came very quickly") are self-asserted, with no independent numbers beyond the 25-30% stat.

The strongest case against his read is that invisible background automation can reach 100% adoption and near-zero scrutiny. When the agent runs silently underneath the workflow, the failure mode flips from "nobody uses it" to "nobody notices it's quietly wrong."

That is a harder problem than adoption, and the piece does not price it.

Vocabulary

• outcomes-as-a-service — sell the finished result, not a tool the buyer has to operate
• control plane — one dashboard to see, pause, re-permission, or pull back running agents
• point of control — a gate that checks policy and permission before an action runs, not after
• computer-use agent — an agent that drives the screen like a person where no API exists
• forward-deployed engineer — an engineer who sits on the client's site for weeks to capture the workflow
• adoption ceiling — the share of staff who actually use a new tool, often stuck at 25-30%

If you're building — what to watch for

• Meet people where the work already happens. If your users live in a spreadsheet or a legacy system, put the agent on top of that, not in a new window they have to remember to open.
• A propose-and-park design — the agent does the work, a human approves before anything lands — is the control plane in practice. Build the pause and the pull-back before you build the autonomy.
• Route the consequential decision to the human where they already are (email, chat, wherever they actually respond), instead of expecting them to come to a dashboard.
• Background automation trades one failure mode for another: high adoption, low scrutiny. The more invisible the agent, the more you need an explicit way for a silent wrong answer to make noise.
• If a deployment only works after weeks of on-site context capture, that is a labour cost hiding inside a product story. Price it honestly before you promise 'it just happens.'

Reading it critically

• It is a vendor playbook, pitching $1B+ revenue clients. The architecture is corroborated elsewhere; the ROI claims are self-asserted, with no independent numbers beyond the 25-30% adoption stat.
• The forward-deployed-engineers-for-weeks model is expensive and high-touch. It does not scale down to a small team, and it cuts against the 'it just happens' promise.
• It contradicts the other school of adoption thinking, which says you drive adoption by making people use the tool, not by removing them from execution. Both cannot be fully right; the reconciliation is probably 'remove the human from execution, keep the owner governing.'
• A control plane that makes the client feel in control is a sales concern, not proof of control. Check whether the pause and pull-back are ever actually exercised, or whether they are theatre.
• Invisible automation's real failure mode is silent error at scale, not low adoption. The more the agent disappears into the background, the fewer eyes are on whether it is right.