INSIGHT · AI GOVERNANCE & COMPLIANCE

Before a scheduling agent runs:
who can stop it,
and what turns it off.

4 November 2026

Australia's national AI guidance asks for three things to be written down before an AI system is switched on, not after it goes wrong: who oversees it and how they intervene, what will be monitored, and the criteria that would end the deployment. For a construction scheduling or progress agent those are concrete questions with contractual consequences, because a resequencing moves crews and a progress position feeds a claim. The guidance does not say an agent may not do this work. It says the authority to stop it has to exist, be held by a named and trained person, and be decided in advance.

Stylised isometric illustration of connected timeline blocks on a rail with a single glowing stop lever raised beside them

Analysed 4 November 2026 · Guidance for AI Adoption, practice 6, ai.gov.au, published 21 October 2025 · Voluntary AI Safety Standard, guardrail 5, industry.gov.au · both read 4 November 2026.

Key takeaways

The oversight requirements are due before implementation, in writing: Guardrail 5.1.3: "Create and document competency, oversight and intervention requirements and support needs for each AI system before implementation." 5.1.4 asks the same of monitoring requirements "prior to implementation". Both say document, and both say before.
Override is named as a thing the overseer must know how to do: The Guidance for AI Adoption states: "The person overseeing your AI systems should know how to do so appropriately, and what they need to do to override the system if something goes wrong." Knowing how to override is treated as a competency, not an assumption.
Two different populations need training, not one: Guardrail 5.1.7 covers "training needs for end users for each AI system you deploy". 5.1.8 covers "those responsible for the ongoing operation and monitoring". A site supervisor reading an agent's output and the person watching whether the agent is still behaving are different jobs.
Switching it off is a process the guidance asks you to design first: Practice 6.2 is "Decommission when appropriate". It asks you to define "the criteria or reasons that termination of an AI model or system might need to occur, and at what point intervention should take place", "the most appropriate role or person to oversee the intervention and decommissioning process", and whether the system "is essential to any critical infrastructure or service delivery".
Why this bites harder in construction than in most settings: A scheduling decision is not only an internal matter. Resequencing changes who is on site and when; a progress position becomes the basis of a claim. The guidance is general, and the consequences of an unreviewed output are not.
We would hold the stop authority as a record, not a convention: Our system-design recommendation: per agent, store the named overseer, what they may reverse without further approval, what they were trained on, what is being monitored, and the criteria that would end the deployment, each with the date it was decided.

Three documents the guidance
wants before you start.

Guardrail 5 commits an organisation to "assigning accountability to a suitably competent and empowered person in the organisation for each AI system and product". The sub-clauses turn that into paperwork with a deadline attached to it: the deadline is implementation.

The dated pair is the unusual part. Most governance language describes a state to be in; 5.1.3 and 5.1.4 describe a document to exist by a point in time. A business that cannot produce them has not met the clause as written, whatever its practice looks like in operation.

Clause	What it asks for	When
5.1.3	"competency, oversight and intervention requirements and support needs for each AI system"	"before implementation", then evaluated "as part of the continuous improvement cycle"
5.1.4	"monitoring requirements for each AI system"	"prior to implementation", evaluated on the same cycle
5.1.1	accountability assigned "to someone who shows suitable competence and has the necessary tools and resources"	Not dated in the clause
5.1.2	that role given "sufficient authority to oversee, intervene and be effective"	Not dated in the clause
5.1.6	accountability for "oversight of third-party development and use of AI systems and components"	Not dated in the clause

What an overseer
is supposed to be able to do.

Practice 6.1 of the Guidance for AI Adoption is "Maintain human oversight and control", on the basis that "Ensuring that people in the organisation retain oversight of AI systems, with the ability to intervene where necessary is important to the safe ongoing operation of the system."

Two of the Practice 6 clauses, 6.1.2 and 6.1.3, carry a "(DEV)" marker on the page, which the guidance uses for actions sitting with developers rather than deployers. A construction business buying an agent is a deployer. Whether a supplier has implemented those mechanisms is a question to ask the supplier, and the standard's procurement note for guardrail 5 says to "Develop a plan with your supplier for governance and oversight over the AI system or component, with clear responsibilities between parties. Reflect this in your contracts."

6.1.1 operational accountability across the lifecycle: "Maintain operational accountability, capability and human oversight throughout the lifecycle of AI systems." Lifecycle, not launch. An agent that was overseen in its first month and not since does not satisfy the words.
6.1.4 training on failure modes specifically: "Ensure appropriate training is provided to anyone overseeing or using AI systems to understand each system's capabilities, limitations and failure modes and when human intervention is needed." Failure modes and intervention timing are named, not left as general familiarity.
The reason the guidance gives: "while regular software does exactly what you program it to do, AI might interpret your instructions differently than you intended." That sentence is why an override path is treated as mandatory rather than prudent.

The decision an agent
should not be making alone.

The guidance is deliberately general. Applying it to construction means separating outputs that are drafts from outputs that are positions. The distinction is not about how good the agent is; it is about what the output does next.

This table is our application of general guidance to construction work, not a classification published by anyone. Nothing in it determines what any contract requires, whether any notice must be given, or whether any claim is valid. Those are matters for the parties and their advisers.

Agent output	What it does next	Why a named person is on it
Proposed resequencing of trades	Changes who attends site and when	People are redirected on the strength of it. 6.1.4 asks the overseer to know when intervention is needed; a resequencing that nobody reviewed is the case it is describing.
Slippage flag against the programme	Triggers, or fails to trigger, a notice	A missed trigger is not visible in the output. Monitoring requirements under 5.1.4 are what make the absence detectable.
Drafted progress position	Feeds a claim	The claim carries the business's name. Nothing in the guidance transfers that to a supplier.
Resource reallocation across projects	Moves cost between jobs	Accountability under 5.1.1 is per system, and the person needs "the necessary tools and resources" to see what moved.
Summary of where a project stands	Informs a decision someone else makes	The lowest-risk output here, and the one most likely to be read as settled fact. Worth marking as drafted.

Scheduling agent · Scheduling systems

When to switch it off,
decided before you need to.

Practice 6.2, "Decommission when appropriate", is the part of the guidance least likely to be read before it is needed. It states that establishing processes to decommission AI systems "when they are no longer needed or performing as intended can protect ongoing service delivery and data assets", and asks an organisation to define, in advance:

The construction reading of 6.2 is narrow and practical. If an agent has been drafting the programme for six months, the question "what happens if we turn it off on Monday" has an answer that is either written down or discovered on Monday.

The termination criteria and the intervention point: "the criteria or reasons that termination of an AI model or system might need to occur, and at what point intervention should take place". For a scheduling agent, the honest version of this is a threshold someone agreed to in writing while nothing was wrong.
Who runs the shutdown: "the most appropriate role or person to oversee the intervention and decommissioning process".
Whether anything critical depends on it: "whether the model or system is essential to any critical infrastructure or service delivery". An agent that quietly became the only place the programme is maintained has answered this question by default.
The impact of stopping: "Assess the risks and impacts of shutting down the AI model or system, including impacts on end-users and interdependencies with other integrated systems on which the model, data or outputs rely to function."
A timeframe, and how the data comes out: "Develop a timeframe and treatment plan to minimise impacts or disruption caused by the decommissioning process", and determine a method to extract data.

What we would put in a system

The point of contact is the moment an agent is approved for a job, and every output it produces afterwards.

Where agents help is narrow, including here. A reporting agent can draft the monthly list of outputs that went out unreviewed, and flag where an agent's position and a person's final position differed. A compliance agent can draft which deployments have no dated pre-implementation record. A person decides what an agent may do unreviewed, whether a threshold has been crossed, and when to stop it. No agent decides whether a programme is correct, whether a notice is due, or whether a claim stands. Those are matters for the business, the contract and your advisers.

Field	Why it is load-bearing
The named overseer, and the authority they hold	Guardrail 5.1.1 and 5.1.2. A role title is not a person, and authority that has not been written down is discovered during an argument.
Oversight and intervention requirements, dated before go-live	5.1.3 says before implementation. The date on the record is what shows it was not written afterwards.
Monitoring requirements, dated before go-live	5.1.4. What is being watched, and what reading would prompt a look.
What the overseer was trained on	5.1.7 and 5.1.8 separate end users from operators; 6.1.4 names capabilities, limitations and failure modes specifically.
Which outputs may act without review, and who decided	The boundary between a draft and a position. This is the field that decides what an unreviewed output can cost.
Termination criteria, and who runs the shutdown	Practice 6.2.1. A threshold agreed while nothing is wrong.
What depends on the agent, and how the data comes out	6.2.1's criticality and data-extraction questions, answered before they are urgent.
Per output: agent version, and whether a person changed it	Without it, a later review cannot tell an agent's position from a person's.

How we deploy AI · Reporting systems

Questions worth asking
of your own deployments

For a construction company director: for each AI agent in the business, can you produce a document dated before it went live that says who oversees it and how they intervene?

Guardrail 5.1.3 asks for exactly that, "before implementation". If the document exists but is undated, or dated after go-live, it does not answer the clause as written.

For a project manager: which of the agent's outputs can reach a subcontractor without a person reading them first?

That boundary decides what an unreviewed output can cost. The guidance does not set it for you; it asks that someone with authority does, and that the authority is real.

For a scheduler or planner: do you know what this agent is bad at?

Practice 6.1.4 asks for training on "capabilities, limitations and failure modes" and "when human intervention is needed". Knowing the strengths is the easy half.

For a commercial manager: if the agent were switched off on Monday, what stops?

Practice 6.2.1 asks whether the system is "essential to any critical infrastructure or service delivery" and for an assessment of interdependencies. An agent that became the only place the programme lives has answered that by accident.

For an operations lead: who is allowed to override it, and have they ever done so?

The Guidance states the overseer should know "what they need to do to override the system if something goes wrong". An override path that has never been exercised is a claim, not a capability.

Questions people ask
about AI agents in project management

Can an AI agent manage a construction schedule in Australia?

Nothing in the guidance read here prohibits it. What the guidance asks is that a named, competent person holds oversight with authority to intervene, that the oversight and monitoring requirements are documented before implementation, and that criteria for stopping the system are defined. Whether any particular use is appropriate is a matter for the business and its advisers.

Who is responsible if an AI scheduling agent gets it wrong?

The documents read place accountability inside the deploying organisation: guardrail 5.1.1 assigns it to a person with suitable competence, 5.1.2 gives that role authority to intervene. Nothing in them moves responsibility to a supplier. What a contract says about liability is a separate question for the parties.

What does meaningful human oversight mean?

Guardrail 5 frames it as human control or intervention mechanisms "in place as needed across the AI system lifecycle", resulting in "appropriate intervention". The Guidance adds that the overseer should know how to override the system. Neither document defines a threshold at which oversight becomes meaningful.

Do we have to write this down before using the tool?

Guardrail 5.1.3 says to create and document competency, oversight and intervention requirements "before implementation", and 5.1.4 says the same of monitoring requirements "prior to implementation". The standard is voluntary; the wording is not ambiguous about sequence.

When should we stop using an AI agent?

Practice 6.2 asks organisations to define the criteria in advance, together with who oversees the shutdown, what depends on the system, the impacts of stopping, a timeframe and a method to extract data. It does not prescribe the criteria themselves.

What this analysis
does and does not show.

As read on 4 November 2026

Documents: Guidance for AI Adoption (practice 6) on ai.gov.au, published 21 October 2025; Voluntary AI Safety Standard (guardrail 5) on industry.gov.au
Documented before go-live: Guardrail 5.1.3 oversight and intervention requirements; 5.1.4 monitoring requirements
Override: The overseer should know "what they need to do to override the system if something goes wrong"
Training populations: 5.1.7 end users; 5.1.8 those responsible for ongoing operation and monitoring; 6.1.4 capabilities, limitations and failure modes
Decommissioning: Practice 6.2.1: termination criteria, intervention point, who oversees, criticality, impacts, timeframe, data extraction
Developer-side clauses: 6.1.2 and 6.1.3 carry a (DEV) marker on the page

Both documents are guidance published by the National AI Centre and the department, not legislation. The Voluntary AI Safety Standard is voluntary on its face. Each standard page states that the Guidance for AI Adoption evolves it, and neither says which an organisation should apply; that relationship is examined in a separate article and is not resolved here.
The table in section 03 mapping agent outputs to consequences is our application of general guidance to construction work. No publisher classifies outputs that way.
We did not download the PDF copies of either document. Every quotation is from the web pages named.
Nothing here determines what any contract requires, whether any notice is due, whether any progress claim is valid, or whether any use of an AI system is appropriate for any business.
No tool, vendor or product is named, tested or assessed, and no claim is made about any agent's accuracy or reliability.
What to record after an AI tool has touched a decision, what a licensed person may sign, and what to ask a vendor before buying are three separate articles on this site. This one is about operating a system you have already decided to run.

What to watch next

Only what the publishers have themselves stated.

The two documents still sit side by side: The standard's pages were live and unmarked on 4 November 2026 while stating that the newer guidance evolves them. Whether guardrail 5's clause-level detail survives into the newer guidance is a question a reader can only settle by rereading both.
No commencement date attaches to any of this: Neither document sets a date by which an organisation must hold the records described. The sequence language in 5.1.3 and 5.1.4 is relative to your own implementation, not to a calendar.

Bring us one agent
and the day you turned it on.

Tell us which AI agent touches your programme or your progress reporting, and when it went live. We will show you which of the pre-implementation records the guidance asks for would already exist, which would not, and what a stop-authority register would have held.

This article is general information about published Australian Government AI guidance and how records of a deployment are structured. It is not legal, contractual or procurement advice. It does not assess any product, does not determine what any contract requires, and names no vendor. All pages are as read on 4 November 2026 and can change.

Send us the agent · How we deploy AI

Sources

Suggested citation: Guidance for AI Adoption practice 6 and Voluntary AI Safety Standard guardrail 5, as read 4 November 2026. No figure in this reading is derived by us.

Before a scheduling agent runs: who can stop it, and what turns it off.