My current view is that AI adoption brings technology and operating-model change together. The opportunity is to redesign specific business capabilities so people and intelligent systems can deliver measurable results, with clear authority and accountability.
A business capability is something an organization needs to be able to do: resolve a service request, approve a purchase, or prepare a customer proposal. Each depends on people, information, and systems. That makes it a useful place to start when deciding where AI belongs.
I arrived at this view by working through a series of questions. First, what happens when producing work gets faster? Then, what makes that work reliable? More recently, how should the organization change around it, and which capabilities are worth redesigning?
These are edited reconstructions of dated notes from September through November 2026. The dates identify the source notes; the wording reflects this retrospective. They describe a developing argument, not measured results from an enterprise deployment.
September: Where the bottleneck moves
My starting point was the relationship between two changes: companies modernizing their technology, and AI changing how that modernization gets done. Discovery, design, coding, and testing could all involve more AI assistance.
That raised a practical concern. Producing a change faster may leave people with more to understand, check, and absorb. The constraint could move from creating the work to accepting it and putting it to use.
The shift in my thinking: speed needed to be measured through to a useful result. Review, corrections, exceptions, and operating effort belonged in the calculation alongside the cost of generation.
This remains a hypothesis to test in each situation. Some processes may still be constrained by production; others may be held up by approvals, poor information, or limited demand.
Early October: What reliable execution requires
The next question was architectural: what would let an AI system carry useful work through to completion?
It needs reliable information, an understanding of what that information means, and clear limits on its authority. Enterprise systems need to control the actions it requests. Someone also needs a way to verify what actually happened.
For example, an AI could help prepare a purchase request. The purchasing system would still enforce spending authority, approval rules, and transaction records. A recommendation, an approval, and a completed purchase are distinct events.
The shift in my thinking: understanding and trust became concrete design responsibilities. Information freshness, permissions, execution records, and outcome checks could be specified and tested.
October 9: Add economic limits and preserve understanding
The October 9 notes added spending authority alongside action authority. Cost reporting helps explain usage; enforced budgets and stop conditions govern what can happen next.
They also emphasized preserving business definitions, tests, and operating knowledge as implementations change. Replacing code still leaves the work of moving data, checking behavior, and maintaining continuity.
The open question was how much of this machinery a given task actually needs. The right level depends on the consequences of an error and the cost of detecting and correcting it.
Late October: How the operating model changes
By the October 30 synthesis, the question had expanded beyond the architecture. AI could help interpret requests, assemble information, and coordinate work across people and systems. That makes its introduction an organizational decision as well as a technical one.
Someone owns the business result. Someone decides which actions may be delegated. People handle exceptions, accept completed work, and recover when something fails. Funding, training, incentives, and performance measures influence whether the new process gets used.
The shift in my thinking: the operating model became part of the design. A technically capable system creates value when the organization can use it, support it, and take responsibility for its results.
The investment question also became more specific: which changes in working practices are necessary to realize the expected benefit, and what will those changes cost?
November: Which business capabilities to redesign
The November 2 refinement brought these ideas together around specific business capabilities. The two transformations became more explicitly connected: modernizing the technology estate, and modernizing the economics and operating model around it. AI-assisted delivery remains an important way to do that work.
The starting point is a business outcome. Trace the capability needed to deliver it through its people, process, information, applications, and controls. Then reconsider how the work should happen: where human judgment matters, where an AI could help, and where an ordinary rule or workflow is sufficient.
Approved capabilities can be made accessible through controlled interfaces. Existing systems can continue to execute transactions. Underlying technology can be modernized where its limitations or economics justify the investment.
The shift in my thinking: the unit of change became a specific capability with a measurable outcome. That makes it possible to prioritize a portfolio of improvements, each with its own readiness, authority, and business case.
Readiness does not imply full autonomy. A sound assessment may lead to a better workflow, a clearer human decision, or a data improvement before agent access is appropriate.
From operational improvement to realized benefit
An operational gain and a financial benefit are not the same thing. Faster completion, fewer errors, or less rework are improvements. They become money only when something converts them: capacity redirected to work that was not getting done, spending that actually comes out of a budget, revenue that arrives sooner, or a risk that is now less likely to cost something. Hours saved that spread thinly across a team, with no decision to use them, usually stay invisible on the financials.
Capturing the benefit also has its own cost. Redesigning a process, training people, changing incentives and measures, migrating data, and running the old and new ways in parallel for a while are real expenditures, and they come before the gain is realized. A credible business case names the conversion path, the transition cost, and who owns delivering it. Absent that, a promising trial can still fail to pay back.
What would change my mind
I would test this view on a bounded piece of work with an agreed baseline. Before the trial starts, I would set what the trial is meant to find out and what each result means: the evidence that would justify expanding it, the evidence that would narrow its scope or change the design, and the evidence that would stop it. Deciding those thresholds in advance is what keeps a trial from becoming a sunk cost that justifies itself after the fact.
Then measure correct completion, elapsed time, human effort, exceptions, and total operating cost against the baseline. Check whether another person can run and recover the process.
If the result shows that simpler automation delivers the same benefit, that is the better choice. If review and recovery consume the expected savings, the design or the scope needs to change. If the main gain comes from clarifying ownership or improving information, that finding should guide the next investment.
The question I am carrying forward is where this combination of technology and organizational change produces enough benefit to justify doing it again.