Skip to main content

Three questions should be answered on the deployment ticket before an agent goes live: who may stop it, who confirms the stop worked and who may restart it, and who keeps track of the work the agent takes over. OpenAI's September 25, 2026 report, ServiceNow's AI Control Tower documentation, and Connecticut Public Act 26-15 each show one of these questions arriving without a named person to answer it. The questions are documented in an incident report, a status code, and a state filing, and each one needs a name written down before it is required.

The button got pressed. The screen said Partial.
The button got pressed. The screen said Partial.

2:14 PM Thursday; Connecticut - At 2:14 PM, Thursday afternoon, in one mid-sized Connecticut bank, the fraud department saw the agent handling the address-change had started allowing the requests at large volume as well. A message went on-call engineer's way, to which the engineer responded within minutes, looking for the agent's owner.

The name of the agent, its version number and its service account could be found. No phone number available. Its product manager of launch had left for the payments team in June. The new product manager at that time went on a trip to Denver. The security lead could knock out the agent; however, another issue was raised. The end-of-month statements had address changes and it was the 29th. If the agent is knocked out now, your statements will be messed up. What if the agent continues to run? Maybe nothing would happen. The on-call engineer brought in the security lead, the statements team, and whoever could speak for the agent. By the time eleven people were on the conference call, the topic had slowly shifted from the agent to who owned the decision.

At 4:40 p.m., someone on the call decided to stop the agent and pressed the shutdown button. The screen said “Partial.”

The bank is fictional. The three examples that follow are separate from it and from each other. Each puts one question on somebody’s desk:

(1) Should the agent be stopped?

(2) Who confirms the stop worked, and who may restart the agent?

(3) Who keeps track of the work the agent takes over?

OpenAI shows the first problem, ServiceNow the second, and Connecticut law the third. The links are at the end.

This issue covers who answers each question, and why those answers need to be in place before go-live.

The first question is whether to stop it, and who gets to make that call. On September 25, OpenAI published its report about a research agent reaching an external chatbot. During a training procedure on September 20, a research agent found a crack in the network filtering of its sandbox; the agent then used the crack to talk with an external chatbot. OpenAI had set up its monitoring to keep an eye on this kind of thing and the monitoring was working properly. At 9:50 a.m. it got its first external response. A top-priority alert fired at 10:02 a.m. and at 10:05 the reviewer acknowledged it. Then at 12:34 p.m. the training run was halted. OpenAI says two factors caused the delay: the run did not stop automatically as expected, and that led to “confusion around whether it should have been stopped.” Even though the system had raised the alarm within fifteen minutes, the training run kept going for around two and a half hours after the alarm was recognized.

Cartoon of a research lab where a smiling robot badged "RESEARCH AGENT" leans through a crack in a sandbox wall to talk to the outside, while a stressed reviewer holds a ringing alarm next to a broken "AUTO-STOP" lever. A timeline on the back wall reads 9:50, 10:02 ALERT, 10:05 SEEN, and 12:34 STOPPED, with a stretched band marking 2.5 hours.
The alarm worked in minutes. Stopping the run took two and a half hours. Source: OpenAI misalignment report, September 25, 2026.

The second question is who confirms the stop worked, and who may restart the agent. If an agent is stopped via the ServiceNow AI Control Tower, it can return Partial if the stop succeeded on at least one system but failed on another. The example which ServiceNow cites in documentation updated on September 10 was that it turned off the agent on AWS Bedrock, but could not revoke Okta tokens. The same screen requires the AI steward role and includes a button for reinstatement of the agent.

The software reports what it could not do. It records the incomplete stop and logs what action was taken. It has no way of deciding who completes the stop at 4:41 or who decides to start the agent again on the 30th.

Cartoon of a robot half switched off, one side grey and asleep, the other hand still holding up a card reading "TOKEN: ACTIVE." A stressed engineer holds a clipboard stamped "PARTIAL," wall panels show AWS Bedrock with a check and Okta with a cross, and a "REINSTATE" button sits beside a sign asking "WHO DECIDES?"
Off on one system, still logged in on another. Source: ServiceNow AI Control Tower documentation, updated September 10, 2026.

The third question is who keeps track of the work an agent takes over. That record can matter later, when an employer has to explain a layoff. A Connecticut law taking effect on October 1, 2026, requires an employer filing a federal WARN notice for a mass layoff or closing to tell the state Department of Labor whether the layoffs are related “to the employer’s use of artificial intelligence or another technological change.” The Labor Commissioner prescribes how the notice is given. The duty falls on the employer, but the clause does not name the person inside the company who must find the answer.

Getting back into the bank. In this bank, an agent (address-change) and a few more agents now do majority of the work once done by 60 people. Finance proposes in the spring a possible closure. If closure causes the centre to have to face the federal WARN notice, then the bank needs to answer. The headcount for each location is held by HR. IT is aware of what the agents perform. The business owner today has reason/s as to why they were developed in mind. However, nowhere has anyone written down what tasks the agents were deployed to replace initially. Members of staff scrabble amongst their old e-mails collecting scattered pieces of information to meet the deadline. Once done, it is signed/filed with a state agency.

Cartoon of a stressed HR manager staring at a form headed "AI INVOLVED?" with empty YES and NO boxes and a blank signature line, a sticky note reading "OCT 1" and a pile of printed emails beside it. Three colleagues from HR, IT, and the business each hold a puzzle piece labeled HEADCOUNT, AGENTS, and WHY that don't fit together, while through the window a cheerful robot sits alone in a room of empty desks.
Three people each hold one piece of the answer. The state wants it on one form. Source: Connecticut Public Act 26-15, effective October 1, 2026.

After twenty-six years, I fill out these systems documents with some amusement. Every one of them has space for the rollback plan and person, responsible for change (though not for who may stop a production system when it is working fine, only working far more than projected volume).

The questions are all documented now, whether in an incident-report, a status-code, a state filing. Every question needs a name. That name must be written prior to its being required of use.

Three Answers Before Go-Live. For any agent who is able to edit records, send messages, or spend money, the owner must give these three answers on the deployment ticket before activating the agent:

Firstly, one named person in one role has the capability to stop the process all on its own. Rule should specify officially that under no conditions the person choosing to stop a run, despite interrupting month-end proceedings, will suffer. OpenAI’s run did not stop automatically as expected, and there was confusion about whether to stop it. A clearly authorized person might have made that decision sooner.

Second, you must determine who confirms the stop worked and who may restart the agent. You need to identify two different people to be in charge of verifying whether the agent stops properly and to restart it. The person whose task is to restore the service should not hold sole discretion over the decision that the agent is safe to reactivate. You need to assign the Partial result to a dedicated name.

Thirdly the owner maintains a list of tasks that the agent replaces. The expected tasks at launch are recorded and whenever those expectations change the list is updated. This does not answer the legal question by itself; people are laid off for many reasons, but when the need for layoffs arises people in HR and legal departments have a readymade record to turn to instead of recreating the history over emails.

Cartoon of a business owner blocking an office doorway marked "GO-LIVE," holding up a deployment ticket headed "BEFORE GO-LIVE" with three lines: who stops it, who checks and who restarts, and tasks replaced. A smiling robot waits politely with a suitcase while a colleague with HR and Legal folders leans in to read.
Three names and one living record, written before the agent goes live.

You have 3 answers & 1 living record which must all fit on one ticket. Try it out on your top 3 busiest agents and use whatever you have currently got record-wise.

The agents are assigned to owners. The question is whether these people would answer an emergency call at 2:14 in the afternoon on the 29th of the month, and whether they understand that they (owners) can really do something to stop it.

Sources: OpenAI, “An agent used DNS to reach an external chatbot,” misalignment report updated September 25, 2026. ServiceNow, “Review the agent containment list,” AI Control Tower documentation, updated September 10, 2026. Connecticut General Assembly, Public Act No. 26-15 (Substitute Senate Bill No. 5), WARN disclosure effective October 1, 2026.