From Pilots to Governed Scale

Leadership uses the sequence as a management cycle. Each move produces a decision and a visible output that allows leadership to determine whether the deployment has earned the right to proceed.

1. Choose: start with the business outcome

The first decision is where an agent should be allowed to act.

Organisations often begin with a technology demonstration and then search for a workflow. Leadership should begin with a business outcome that matters, identify the decisions and actions inside the workflow, and ask whether agentic capability is necessary. A simpler assistant, rules-based automation or improved process may be sufficient.

The distributor example that follows is illustrative rather than a documented company case. It reflects the operating decisions a mid-market organisation would need to make.

Consider a mid-sized distributor with a growing backlog of supplier orders that need manual review. An agent might compare purchase orders, delivery records, inventory levels and approved vendor terms, then recommend or execute a resolution. The opportunity is concrete: reduce cycle time without increasing payment errors or supplier disputes.

Before authorising the work, leadership should establish the current baseline. How long does resolution take today? What errors occur? What judgement is involved? What is the cost of delay? Which decisions affect cash, customers or contractual commitments?

The visible output from Choose is a priority workflow, an intended business outcome and a named accountable sponsor.

• EXECUTIVE OBSERVATION:  A pilot should reduce uncertainty enough to support a better decision. Momentum by itself proves very little.

2. Bound: convert intent into explicit authority

Once the workflow is chosen, leadership must define what the agent may decide, access and do. It must also be clear where the agent will stop.

This requires more precision than saying that a human remains responsible. Authority should be separated into practical levels. The agent may advise on some actions, act only with approval on others, and operate independently within defined thresholds. Certain actions should remain prohibited regardless of performance.

For the distributor, the agent might be permitted to request missing documents, identify mismatches and reschedule a delivery within an approved window. It might require human approval before changing a payment amount. It might be prohibited from altering banking details, creating a new supplier or waiving a material contractual term.

The boundary should also cover data, tools, users and whether the agent’s actions can be undone. Which systems may the agent access? Can it send external messages? May it call other agents or external tools? What financial or customer-impact thresholds trigger approval? Can an action be reversed quickly if it is wrong?

Singapore’s updated Model AI Governance Framework for Agentic AI provides a useful implementation example. GovTech Singapore initially limited agentic coding assistants to internal employees and low-risk systems and did not allow external tools. That bounded first phase gave the organisation time to build central logging, monitoring, attack testing and a framework for approved external tools before widening access.

Each organisation will set different technical restrictions. The governing principle is consistent: authority should expand only after the controls needed for the next level are operational.

The visible output from Bound is a documented authority record: permitted actions, approval gates, prohibited actions, tool and data access, human checkpoints and stop conditions.

3. Operationalise: make the controls work in daily operations

A written boundary becomes an operating control only when people and systems can carry it into daily work.

Approval requests need a recipient, exceptions need a reviewer, and escalation routes must be reachable when the agent behaves unexpectedly. Monitoring must identify events that matter. The organisation must then be able to act on what the monitoring reveals.

This is where governance can exist on paper but fail in practice. A human may technically be “in the loop” while lacking the information, time, competence or authority to challenge the system. The 2026 International AI Safety Report highlights the continuing problem of automation bias: people may rely too heavily on automated output and ignore information that conflicts with it. With agents, intervention can be more difficult because the system may take several actions before a person sees the consequence.

Meaningful supervision therefore requires four conditions:

1. The reviewer understands what the agent is requesting and why.
2. The reviewer has enough time and evidence to judge the request.
3. The reviewer has the authority to refuse, modify, escalate or stop it.
4. The organisation has enough capacity to perform that work consistently.

For the distributor, this could mean routing payment changes to an accounts-payable manager, changes to supplier records through finance and security, and unresolved contractual exceptions to procurement. The system should record the request, the evidence presented, the decision, the decision maker and the resulting action. Supervisors should practise the escalation and stop procedure before a live incident forces them to discover whether it works.

Technical safeguards still matter: access limited to what the agent needs, secure authentication, action limits, testing, logs, alerts and systems that allow actions to be reversed. The operating model determines whether those safeguards will work when a real decision must be made under pressure.

The visible output from Operationalise is working ownership, monitoring, approvals, escalation and intervention capacity.

• EXECUTIVE OBSERVATION: Human oversight works only when the person can understand, challenge and stop what the system is doing.

4. Prove: require operating evidence

The agent should now operate within a limited environment long enough to generate evidence. Completing the task is only part of the test. The agent must also produce sufficient value while remaining under control when conditions change.

Evidence should cover more than accuracy or completion time. Leadership needs to see at least five areas:

1. Business outcome: cycle time, quality, service, capacity or another result compared with the starting baseline.
2. Operating performance: successful completions, errors, retries, exceptions and reliability under changing inputs or system conditions.
3. Control performance: approval volumes, rejected actions, overrides, escalation frequency, policy breaches and failed safeguards.
4. Consequence: incidents, near misses, customer or employee effects, financial exposure and unresolved risks.
5. Total operating cost and workload: integration, monitoring, human review and the cost of correcting problems, alongside model and licence costs.

A clean demonstration offers limited evidence for a system expected to operate in changing conditions. A 2026 preprint benchmark of tool-using agents found that performance declined when agents encountered unexpected changes and system failures. Although the study does not predict enterprise failure rates, it supports a practical conclusion: production readiness requires evidence from realistic operating conditions.

For the distributor, the relevant evidence might show that the agent reduced average resolution time by 35 percent. Alongside that gain, 18 percent of cases required human review, and a small group of recurring exceptions generated most of the supervision burden. That evidence is more useful than a headline productivity figure because it tells leadership where the design is working and where the operating cost remains.

The visible output from Prove is an evidence pack combining performance, control, incident, override, value and supervision-cost information.

5. Decide: scale, restrict, redesign, continue testing or stop

Every bounded deployment should end with an explicit portfolio decision.

There are five legitimate outcomes:

1. Scale when the evidence supports a wider group, broader feature set or carefully increased authority.
2. Restrict when value exists but certain actions, users, tools or conditions should remain limited.
3. Redesign when the workflow, controls, interface or division of human and machine work needs to change.
4. Continue testing when the evidence is not yet sufficient for a final decision, while keeping the existing boundary and setting a new review date.
5. Stop when the value does not justify the consequence, supervision burden or unresolved risk.

A decision to stop can be a successful result. A disciplined pilot may establish that a particular use case should not proceed. The more serious failure is allowing a temporary pilot to become permanent operating infrastructure because no one scheduled the decision.

The OECD’s 2026 Due Diligence Guidance for Responsible AI supports an ongoing management cycle: assign responsibility, assess impacts, prevent or reduce harm, track results, communicate and correct problems. NIST’s AI Risk Management Framework similarly organises ongoing work around Govern, Map, Measure and Manage. Neither source sets out the Horizon SPI sequence, but both show that governance must continue after deployment.

The visible output from Decide is a recorded decision, the evidence relied upon, the conditions attached to the next stage, the accountable decision maker and the date of the next review.

The first 90 days: one governed learning cycle

The five moves can become a practical starting plan, especially for an SME or mid-market organisation that needs a disciplined approach without a large governance structure.

The timetable, however, requires care.

There is no credible basis for claiming that every organisation can reach governed scale in 90 days. A regulated, customer-facing or technically complex deployment may require longer legal review, security testing, procurement, integration, validation and stakeholder consultation. Rare events and seasonal conditions may take months to observe.

A more realistic objective is:

• 90-DAY DISCIPLINE: The first 90 days are not a deadline for full autonomy. They are a disciplined cycle for deciding whether one bounded workflow has earned the right to proceed.