Scenario analysis

What would have to change for AI to run more of the working day?

A scenario analysis, not a forecast: five conditions that would need to hold before AI carries most of an ordinary business day, and what evidence would tell you each one is arriving or stalling.

Published
September 9, 2026
Last checked
September 9, 2026
Written by
Dryvn AI editorial
Edited by
Dryvn AI editorial
Reviewed by
Not yet reviewed by a named person
Read as
Scenario (labelled future possibilities)

Why we are writing a scenario and not a forecast

Plenty of people will tell you what AI will do to work by a particular year. We will not, because we do not know, and neither do they. What we can do is something more useful for an owner: name the conditions that would have to be true for AI to carry most of an ordinary business day, and say what you would expect to see if each condition were arriving.

The baseline is modest. Statistics Canada reported in June 2026 that 19.2% of Canadian businesses used AI to produce goods or deliver services in the twelve months before the survey [S07]. That is one in five, on a defined question, over a specific period. It tells you adoption is real and early. It tells you nothing about how much of anyone's day it runs.

Condition one: authority is written down

For a system to act on your behalf it needs to know what it may do alone, what needs a yes, and what it must never do. Vendor tooling already has the mechanism: OpenAI's agents documentation describes guardrails and approval flows that pause before risky work [S29], and Anthropic's computer-use guidance tells you to have a person confirm decisions with real consequences [S30]. The mechanism is not the constraint. The constraint is that most businesses have never written their authority rules down, because until now the people holding the authority were the same people doing the work.

What would confirm it: businesses routinely keeping a written permissions sheet per process, the way they keep a signing authority for cheques. What would weaken it: a run of public incidents where systems acted outside authority nobody had defined. What you control: you can write yours this week with the approval boundaries worksheet.

Condition two: records a system can act on

An assistant cannot chase an invoice it cannot find, or reschedule an appointment that lives in a text thread. AI running more of the day requires that the customer, the job, the document and the money exist as records with owners and current versions. Many small businesses run on a mix of software and memory, and the memory part is invisible to any system.

What would confirm it: small-business software that makes a next step and an owner mandatory on every open item, and businesses actually using it that way. What would weaken it: assistants that keep answering from stale or duplicate records, which is the failure the documents explainer describes. What you control: one authoritative version per document, an owner per record, a next action on every open item.

Condition three: tools connect through shared standards

Today, connecting an assistant to a calendar, an accounting package and a document store often means three separate integrations. The Model Context Protocol is described by its maintainers as an open-source standard for connecting AI applications to external systems, with support listed across several assistants and developer tools [S34]. That is a real development. What is not yet shown is how far it reaches into the software small businesses actually use, and how well it handles permissions and audit when several tools are involved.

What would confirm it: the accounting, scheduling and communication tools common in your industry shipping support for a shared standard, and integrations that carry who-may-do-what along with the data. What would weaken it: competing standards, or vendors keeping connections proprietary. What you control: deciding now which tool is the source of truth for each record, so that when connections arrive you know which way the data should flow. The integration checklist is that decision on paper.

Condition four: a way to evaluate the work

If a system handles fifty customer requests a day, somebody needs to know how many were resolved, how many were resolved wrongly, and how many quietly stalled. That is evaluation, and it is harder than it sounds because the easy signals (a message was sent, a box was ticked) are not the outcome. Vendor guidance still says to keep a person confirming consequential actions [S30]. Until evaluation is good enough that the guidance changes, a person stays in the loop, and that caps how much of the day a system runs.

What would confirm it: vendors documenting outcome-level evaluation, and their oversight guidance loosening for defined classes of task. What would weaken it: continued guidance to confirm consequential actions, or evaluation that only measures whether steps ran. What you control: defining completion evidence for each piece of work, which is what the handoff assessment asks for in its last question.

Condition five: someone owns each process

This is the quiet one. A system can only carry a process that exists. In many businesses the process for, say, a change order lives in the head of whoever has done it longest. Handing that to a system means first agreeing what the process is, then naming who owns it when the system gets it wrong. That is organisational work, and it does not speed up because models got better.

What would confirm it: small businesses documenting their recurring processes as a normal part of running, not as a project. What would weaken it: systems being deployed on undocumented processes and failing in ways nobody can diagnose. What you control: the SOP template turns one messy process into something a person or a system can follow.

The five conditions at a glance (all scenario)
ConditionExists today?Confirming evidenceWeakening evidence
Authority written downMechanisms yes [S29]; practice rarelyPermissions sheets become routineIncidents from undefined authority
Actionable recordsUnevenMandatory owner and next step in common toolsStale and duplicate records keep causing errors
Shared connection standardsEmerging [S34]Your industry's tools ship support with permissionsCompeting or proprietary standards
Outcome evaluationPartial; human confirmation advised [S30]Vendor guidance loosens for defined tasksGuidance stays; evaluation stays step-level
Process ownershipRare in small businessDocumented processes become normalDeployments on undocumented processes fail

Illustrative example · fictional

One business, five conditions, one year

A fictional plumbing company with six staff asks what AI could run for them by next autumn. Going through the conditions: authority is in the owner's head; records are split between a scheduling app and a paper diary; the accounting package and the scheduler do not talk; nobody measures whether a call-out was actually resolved; and the process for warranty call-backs is whatever the senior plumber remembers.

None of that is a reason to do nothing. It is a list of what the owner controls. Over a year: write the permissions sheet (a week), move the diary into the scheduler and make next step mandatory (a month), decide the scheduler is the source of truth for appointments (a decision), define completion evidence for a call-out as the customer's confirmation (a form field), and write the warranty call-back process down (an afternoon with the senior plumber). At the end of that year, whether or not the industry's tools have connected, the business is ready for whichever tools do.

What this means for working people

We are not going to tell you jobs are safe or jobs are gone; both are predictions and both get made with more confidence than the evidence supports. What the five conditions suggest is narrower. The work that moves to systems first is the work that is already well-defined, well-recorded and well-owned. The work that stays with people is judgement, exceptions, authority and the defining itself. Someone has to write the permissions sheet. Someone has to own the process when the system fails. That is not a consolation; it is where the value sits.

Keep a watch sheet

Write the scenarios you are planning around, the evidence you would expect to see if each were true, what you have seen so far, and a review date. Then stop reading headlines about it until the date. The facts, forecasts and open questions guide keeps a maintained version of this sorting and includes the watch sheet as a worksheet. We will update it as the evidence moves, and we will say when it does.

Sources

Dates are when each source was last checked by the editor. Sources support specific claims; they are not endorsements.

  1. S34What is the Model Context Protocol (MCP)? · modelcontextprotocol.io · checked September 9, 2026Describes MCP as an open-source standard for connecting AI applications to external systems with support across several assistants and tools. Used as evidence that an interoperability standard exists; not as evidence of how widely it is used in small businesses.
  2. S29Agents SDK · OpenAI developer documentation · checked September 9, 2026Documents guardrails and resumable approval flows that pause before risky work. Used as evidence that approval mechanisms exist in vendor tooling.
  3. S30Computer use tool · Claude Platform documentation (Anthropic) · checked September 9, 2026Advises human confirmation for decisions with meaningful real-world consequences and notes the model may follow instructions found in on-screen content. Used as evidence of current vendor guidance on oversight.
  4. S07Analysis on artificial intelligence use by businesses in Canada, second quarter of 2026 · Statistics Canada · checked September 9, 2026Released 11 June 2026. 19.2% of businesses reported using AI to produce goods or deliver services over the 12 months preceding the survey. A defined survey measure, cited as a baseline for adoption, not as a trend.

B03 · Published September 9, 2026 · Opinions are the author's. Vendor facts are dated and sourced above; scenarios are labelled as scenarios.