When Should You Stop an AI Agent and Hand the Work Back?
After you split drafts and decisions, you still need a stop rule. This article covers when to halt an agent, who decides, and what to attach when the work goes back to a person.
The previous article split AI-agent work and human-PM work into drafts and decisions. That split makes ordinary weeks simpler. Teams still get stuck on the exception. The draft looks fine, the baseline is old, the agent wants to continue, and the PM sees a result that already moved.
Handoff was named in the operating principles. It becomes a real question only after the split exists. What signal means stop. Who stops. What you attach when the work goes back to a person. This article closes the series on those three points. The split starts the loop. The stop finishes it.
When Continuing Is the Failure
The common failure is not that the agent makes nothing. It is that it keeps drafting from a weak baseline. Yesterday’s notes are treated as current. Yesterday’s scope is treated as current.
If a schedule change or a client update is prepared in that state, the problem is timing, not prose. A person steps in only after something is almost executed. If you never stop, the split is only a document.
Signals to Stop
If any of these show up, do not continue execution. Drafting may continue. Dates, owners, scope, and outbound messages should not change.
There is no current baseline, or two documents disagree.
The sources the agent used are older than the last change.
The same type of error has happened more than once.
A client, a contract, cost, or personal data could be affected.
The next action is hard to reverse: a send, a permission change, an external share.
The agent marks low confidence, or a required input is empty.
Typos are a correction. These signals are a stop.
Who Stops the Work
The stop belongs to the human PM. The agent can raise a signal. Turning permission off, pulling a draft out of the execution queue, and explaining it to the client belong to a person.
If a teammate sees the problem, they pass it to the PM. Asking the agent to “just fix it and continue” is the same as having no stop rule. If nobody is named, the split works only on quiet days.
What to Attach on Handoff
The unit you hand over is material for a decision, not a finished output. Without the items below, the PM rereads the job from zero.
What the agent was about to do when it stopped
Which sources it treated as current
What is missing or in conflict
What already changed — dates, files, drafts
Whether anything already went to a client or outside the team
What record must be fixed before the work can resume
Seen together, the handoff looks like this.
Situation | Agent | Handoff | Human PM |
|---|---|---|---|
Baselines disagree | Mark the conflict only | Attach both documents and dates | Lock the current baseline |
A draft would change dates | Do not execute | Pass the proposal and sources | Approve or reject |
The same error repeats | Stop auto-execution for that work | Record the failure type | Reduce permission or keep it |
The client needs an update | Draft only | Mark facts and unknowns | Decide the explanation and the send |
Two Paths After a Stop
A stop is not always a shutdown. Two paths are enough.
Turn it back on: Write the cause into the baseline, sample the same kind of draft, then resume in a narrow range.
Reduce permission: Leave that work as drafts only. You are not cancelling the split. You are closing the dangerous cell.
Without a cause record, the same failure returns next week. As the records article said, the agent will read the unfixed memory as if it were current.
A Weekly Close
If a team already has a split, these five questions close the series in practice.
Did anything stop this week?
Was the reason on the signal list?
Did the handoff include sources, unknowns, and what already changed?
If the client needed an explanation, did the human PM give it?
If work was turned back on, was the record fixed first?
If those are empty, the split is a document. If they are filled, principles, records, the split, and the stop run as one cycle.
The Line That Closes the Series
We started with what AI can do in project work, then why records make that help accurate, then the operating rules for an agent on a team, then the split between drafts and decisions. The remaining piece is the exception.
In ordinary work the agent prepares material and the human PM decides. When a signal appears, the agent stops and a person fixes the baseline or reduces permission. With those four parts, bringing in an agent is an operating system, not a feature list.
The next thing to write down is not a new tool. It is whether your stop signals and handoff bundle actually exist.
FAQ
Frequently asked questions
Is it enough if the agent stops itself?
No. The agent can flag low confidence, but a stop that touches dates, scope, or a client message is the human PM’s call. The right to stop and the right to turn the work back on should stay with a person.
Should you stop for every small error in a draft?
Typos and format issues can be a correction. Errors that could change dates, owners, scope, or a client promise should halt execution and go to a person.
What if the same mistake repeats?
Once is a baseline fix. If the same type repeats, turn off auto-execution for that work and leave drafts only. Reducing permission is also a handoff.
Who explains the stop to the client?
The human PM. The agent can draft the note. What went wrong, what was stopped, and what changes next should be said by a person.
Can you hand over only the output?
No. Attach what was tried, which sources were used, what is uncertain, and what already changed. An output alone makes the PM reread the job from scratch.
When can you turn the agent back on?
After the cause is written into the baseline, and a person has sampled the same kind of draft. Without that record, the same failure returns.
Related updates
How Should an AI Agent and a Human PM Divide the Work?
The split between an AI agent and a human PM is not a local habit of one tool or team. Drafting, decisions, approvals, and handoffs are already used across many kinds of work.
Read moreBlogOperating Principles for AI Agents on Project Teams
Introducing an AI agent into a project requires more than automating tasks. Teams must define its role, permissions, approval conditions, information access, escalation rules, and human accountability. This guide explains how to let AI agents contribute safely while people retain control.
Read moreBlogWhy Better Project Records Make AI Smarter
AI needs reliable project context to provide accurate and useful answers. When requirements, decisions, changes, owners, schedules, issues, and test results are managed as connected records, AI can deliver better summaries, grounded answers, risk analysis, onboarding support, and project recommendations.
Read more