Start With One Consequential Operation
Why the first serious AI transformation project should be small enough to govern, important enough to matter, and complete enough to reveal the company around it
Across several game teams, automated systems ran tests overnight.
By morning, they had produced more evidence than people could gather manually: warnings, crashes, errors, and performance changes arranged in reports. The exact tools differed, but the handoff was familiar. At nine in the morning, the automation stopped being automatic.
Someone still had to decide which change mattered, open the detailed result, determine when it began, locate the relevant logs and profiles, compare telemetry, identify the likely subsystem, find an owner, negotiate priority against planned work, and later determine whether the response had actually restored the game.
The teams were not short of software. They already had tests, dashboards, logs, profilers, telemetry, build history, and experienced engineers. The immediate constraint was that abundant machine output still depended on scarce human attention to become an actionable organizational signal.
We tested a smaller intervention. AI could sift existing reports, compare them with history, explain meaningful changes, and produce a shorter set of observations for engineers. Working examples supported that narrower hypothesis. The complete operation from detection through priority, ownership, intervention, verified recovery, and changed later behavior did not reach production in this form.
That boundary matters. The useful lesson was not that an AI system had solved performance management. It was that the real design object was larger than the report and smaller than the company:
Turn a material performance regression detected by existing automated tests into a contextualized, prioritized, owned investigation whose result is verified against a later build and changes future monitoring or production behavior.
That is what I mean by a consequential operation.
It is important enough that failure has a real product, customer, financial, professional, or human consequence. It is bounded enough that the organization can understand who is involved, what evidence is required, which authority applies, what action is permitted, how recovery works, and what would count as success. It is complete enough that the responsibility does not end when the model produces an answer or a ticket changes state.
The first serious AI transformation project should look more like this than an agent org chart.
Begin with consequence, not capability
The natural way to explore a new technology is to ask what it can do.
Can it summarize meetings, write code, qualify leads, investigate incidents, draft proposals, reconcile invoices, plan production, or answer questions about the company? Each answer creates another use case. Soon the company has a long list of possible assistants and agents, several platform evaluations, and an architecture diagram that resembles the existing organization with synthetic workers added to every box.
This creates activity before it creates responsibility.
“Write outreach emails” is a task. “Automate sales” is a domain. Neither tells us whether the company can turn a warranted opportunity into a promise it can fulfil, with customer intent, delivery capacity, commercial authority, evidence, and next action visible to the relevant people.
“Summarize test reports” is a task. “Automate quality” is a domain. A consequential operation connects a material signal to a prioritized investigation, an authorized intervention, a verified result, and a change in what the organization does next time.
The distinction is not semantic. A task can complete successfully while the intended consequence fails. A workflow can move through every step while nobody possesses the authority to resolve the underlying conflict. An agent can perform a convincing sequence of actions while the company remains unable to explain why the action was warranted, who may contest it, or what evidence would reopen the decision.
The previous issue, Responsibility Before Automation, argued that responsibility has to be designed before the company decides what an agent should do. One consequential operation gives that responsibility a boundary in which it can be tested.
The starting question is therefore not:
Where can we deploy an agent?
It is:
Which recurring organizational consequence matters enough to learn from and is bounded enough to govern?
A consequential operation is more than a workflow
A workflow usually shows sequence. A request arrives, information is collected, a decision is prepared, an action is taken, and a record is updated. That view is useful, but it can hide the relations that make the work legitimate and consequential.
A consequential operation has to connect at least seven things.
First, it has an intended consequence. The organization is not merely completing an activity. It is trying to change something in the world for a customer, employee, patient, player, partner, community, or institution.
Second, it has a boundary. The team can say which cases, parties, products, regions, value ranges, or decisions belong inside the first version and which do not.
Third, it has parties and commitments. Someone defines legitimate ends. Someone contributes capability. Someone may decide or commit. Someone governs the system. Someone is affected by the outcome. These positions may overlap, but they should not be silently compressed into a single owner field.
Fourth, it has warranted state. The present action depends on a selected relation among evidence, policy, history, capacity, uncertainty, and current conditions. A model can help assemble that state. It should not make missing or disputed reality disappear by writing a fluent summary.
Fifth, it has authority and stops. The operation defines who may act, defer, refuse, escalate, interrupt, change policy, and recover. Permission to call a tool is not the same thing as authority to make the underlying commitment.
Sixth, it has verification and reopening. Completion is not proof. The organization needs evidence that the intended consequence occurred, along with conditions under which a declared success can be challenged later.
Seventh, it has revision. A completed cycle should change later execution when the evidence warrants it. Another stored trace is not organizational learning unless a threshold, policy, test, capability, routing rule, evaluation, or operating assumption changes.
This is why the operation is a stronger starting object than a task and a safer construction method than a company-wide transformation program. It contains enough of the institution to expose reality, but not so much that every unresolved organizational question has to be answered before anything can be learned.
Replay the operation before redesigning it
The first step is not to automate the current flow. It is to replay one real case from trigger to consequence without cleaning it up.
Follow the evidence people actually inspect. Notice which systems they consult and which conversations never enter a system. Record where copy and paste recurs, where a person translates between representations, where uncertainty changes the path, who can interrupt planned work, and what currently allows the organization to declare the case closed.
This is where human middleware becomes visible. The person everyone calls may be reconstructing state, preserving a commitment, translating technical evidence into product consequence, locating informal authority, or verifying the result after the official workflow is complete.
The goal is not to extract everything that person knows and build a digital copy of them. Some knowledge is contextual, relational, tacit, disputed, or legitimately private. Some human participation is part of the value. Negotiation, care, professional judgment, creative direction, and the authority to make a commitment are not infrastructure defects.
The replay is looking for a narrower distinction:
- Which human contribution gives the operation value?
- Which human work is transport, synchronization, memory, monitoring, format conversion, or repeated reconstruction?
- Which judgment depends on evidence the current systems fail to assemble?
- Which authority exists in practice but not in the workflow?
- Which outcome is assumed rather than verified?
- Which capability would disappear if one experienced person left?
Forward-deployed work is useful here because it discovers the operation from inside the work rather than imposing an abstraction from outside it. The purpose is not proximity for its own sake. It is to see the difference between the documented process and the responsibility people are actually carrying.
Choose the least architecture that can carry the responsibility
Once teams see the operation, they often jump immediately to the agent architecture.
That sequence should be reversed. The operation should determine the implementation surface.
OpenAI's practical guide to building agents advises teams to validate that a use case actually requires the kinds of complex decision-making, difficult rules, or unstructured interpretation that justify an agent. Otherwise, a deterministic solution may be enough. Anthropic's guidance on effective agents makes a related point: successful systems often begin with simple, composable patterns rather than elaborate frameworks.
This matters organizationally as well as technically.
A person-operated AI work surface may be enough to replay the operation and prepare evidence. A deterministic workflow with model steps may be sufficient when the path is mostly known. A model-directed agent runtime may be justified when tool selection and diagnostic sequencing vary materially by case. A governed operational system becomes necessary when software can send, spend, commit, classify people, change access, affect safety, or alter a live product.
These are not stages on a ladder toward autonomy.
The correct question is:
What is the least architecture and exposure capable of carrying this responsibility?
For the performance-regression example, the first useful authority might include comparing reports, assembling traces, identifying a probable change window, preparing a focused rerun, enriching the investigation record, and routing the case. It would not include autonomously changing the product merely because the system produced a confident causal story.
The same principle applies to representation. The company does not need a complete ontology before it can learn from one operation. It needs the smallest representation capable of supporting the responsibility, with exclusions visible.
For a commercial operation, that representation might relate customer purpose, current scope, price, delivery capacity, approved commitments, uncertainty, authority, and later fulfilment evidence. For the performance case, it might relate signal, build, configuration, baseline, profiles, affected experience, likely subsystem, owner, release context, action, and later result.
A smaller representation is not an excuse to ignore reality. It is a way to make the boundary contestable. What is unknown, disputed, private, delayed, or outside scope should remain visible rather than being converted into false certainty.
Authority should widen through evidence
A successful demonstration proves very little about the authority a system should receive.
The first cycle can remain manual. A person uses an AI work surface to assemble state, compare evidence, and prepare a possible action. The organization learns whether the representation is useful and what it omits.
The next cycle may run in shadow mode. The system produces its interpretation and proposed action without changing the live operation. The team compares those proposals with what people actually did and what happened later.
Recommendation mode allows the system to participate in the real workflow while people retain decision authority. This reveals review burden, automation bias, disagreement, missing context, and the practical meaning of refusal.
Bounded live authority comes later, if it comes at all. The system acts inside a narrow envelope with explicit purpose, parties, evidence requirements, value or exposure limits, stops, escalation, and recovery. The action should be reversible where possible, and the organization should know which capability or known-good path can be restored.
The World Economic Forum's 2026 playbook for trusted agent adoption, authorization, and scaling reflects the growing need to describe capability and authority at deployment level rather than treating access as a one-time platform decision. Anthropic's guidance on agent evaluations makes the complementary technical point that multi-turn, tool-using behavior needs evaluation across the lifecycle, not only a model benchmark before launch.
The operation adds another test. A technically correct action may still fail the intended consequence. It may transfer work to another team, weaken a capability, create a new dependency, increase proof burden for an affected person, or release time that the organization immediately fills with more low-value activity.
Authority should widen only when the evidence supports more consequence and recovery remains credible.
Figure 1. The least-sufficient path: begin with a replayable operation, then increase authority only as evidence, verification, and governance support it.
The Consequential Operation Test
Before selecting the first serious AI project, write down a candidate operation and test it against seven questions.
1. What consequence are we responsible for?
Describe the recurring result in the world, not the completion of an activity.
“We will summarize support conversations” is an activity.
“We will turn a customer problem that cannot be resolved in the ordinary path into an owned, authorized resolution whose outcome is confirmed with the customer and changes future handling where warranted” is closer to a consequence.
2. Where does the responsibility begin and end?
Name the trigger and the evidence that closes the operation. Include the conditions that can reopen it.
A ticket created, message sent, or recommendation approved may be an intermediate state rather than the end.
3. Who are the parties?
Identify whose purpose gives the operation meaning, who contributes capability, who may decide, who governs the system, and who is affected.
Do not assume the user of the software is the only party with relevant knowledge or standing.
4. What state must be warranted before action?
List the evidence, policy, commitments, history, capacity, current conditions, uncertainty, and contradiction that matter.
Then identify what is unavailable, disputed, delayed, private, or outside scope.
5. Who may decide, act, refuse, stop, and recover?
Separate technical access from legitimate authority.
State what the first version may do, what requires direct human authority, what must trigger escalation, and who can restore the known-good path.
6. What proves the consequence occurred?
Define the later evidence, the party allowed to judge it, and the time at which it becomes available.
A workflow can complete before the relevant consequence is observable.
7. What should change next time?
A cycle should be able to revise thresholds, policy, routing, tests, evaluation cases, artifacts, capability, or authority.
If nothing in later execution can change, the system may be producing output without organizational learning.
A candidate that cannot answer these questions is probably still a task, an aspiration, or an implementation idea. That does not make it useless. It means the team has more discovery to do before granting it operational authority.
One operation can still become another pilot
Starting small is not automatically wise.
A bounded operation can become a local optimization that ignores burden transferred elsewhere. It can produce shadow infrastructure that nobody owns. It can create an attractive ROI story by counting minutes saved while excluding integration, review, recovery, capability loss, and the destination of released attention. It can remain forever in recommendation mode because the company never resolves the authority question.
The answer is not to begin with the whole company.
The answer is to keep the company as the design object while using one operation as the construction method.
From the first cycle, record what the operation reveals beyond its boundary:
- Which shared purpose or promise governs several operations?
- Which capability should the company possess rather than borrow repeatedly from individuals?
- Which memory and artifacts need to persist across work?
- Which identity, tool, evaluation, observability, and recovery services are genuinely shared?
- Which professional or independent authority must not be absorbed into one operating team?
- Which new dependency or cost has appeared?
- Who receives the time, money, power, or capacity released by the change?
Patterns across repeated operations may justify a platform, a central capability, a new operating unit, a governance mechanism, or a change in management. One successful pilot does not.
Figure 2. Start with one consequential operation, learn the recurring pattern, then let company architecture emerge from repeated governed work.
This is consistent with a much older lesson about technology and organizations. Erik Brynjolfsson and Lorin Hitt argued in Beyond Computation that the value of information technology depends on complementary organizational change. Current enterprise guidance is arriving at a similar practical boundary. OpenAI's 2026 account of how enterprises are scaling AI emphasizes workflow design, enabling governance, and proof that survives production pressure.
The technology has changed. The organizational requirement has not disappeared.
Build from inside consequential work outward
The first month does not need a company-wide ontology, a synthetic workforce, or a promise of full automation.
Choose one consequential operation. Replay a real case. Make the boundary, parties, warranted state, authority, verification, recovery, and learning explicit. Use the least implementation capable of carrying the responsibility. Run one bounded cycle in manual, shadow, recommendation, or limited live mode. Then decide from consequence whether to promote, revise, roll back, remain manual, or reject the implementation.
The purpose of the first operation is not to prove that AI works.
It is to learn what the company must be able to represent, decide, preserve, verify, recover, and change when intelligence can participate directly in execution.
A consequential operation gives model capability somewhere real to collide with organizational reality. It reveals where context is missing, where authority is informal, where the workflow closes too early, where human judgment creates value, where people are being used as middleware, and where the company has delegated activity without retaining responsibility.
Then the organization can look across operations and decide what belongs in shared company architecture.
The first operation is the construction method.
The company remains the design object.
The next issue, Is the Loop Really the Right Unit of Company Design?, will challenge one of the central abstractions in this work: when does a loop reveal an executable responsibility, and when does it flatten a company into a diagram that is too neat to be true?
What is one recurring operation in your organization that is important enough to matter, bounded enough to govern, and currently depends on people reconstructing the situation before they can act?
Please describe the pattern rather than confidential company, customer, employee, product, or system details.