Two AI roles had lost permission to do their jobs. Both kept restarting. Neither could receive the fix meant to stop the loop until its permission was renewed.
The request went to the founder: renew each role by hand.
Why did roles built to keep working need him to keep giving them permission?
At First AI Movers, a small company that runs much of its work through AI agents, some roles last beyond any one chat or work session. They are called standing seats. Each runs a program of work. Think of a job that stays on the team even when the person filling it changes.
Each seat had written limits on what it could do. Those limits could include an end date. When that date passed, the seat lost its right to act.
The company’s rulebook said the founder, known here as the Operator, was never to be a continue button for the machines. Yet the renewal request put him in just that position.
An AI Governor, the role in charge of a program, raised the request. It went into Needs You, the queue for tasks only the Operator could do. He was asked to remove the end date from each seat he wanted to keep. Leaving a seat untouched would retire it. Another program needed newly signed permission.
The trouble was already underway. Two seats had expired. A third was due to lose its permission later that day.
The Conductor, another AI role, posted a status table. One seat had restarted 6,889 times. The other had restarted 834 times.
There was a fix meant to let the seats stop restarting. But the system that checked their permission would not process an expired seat, so neither could receive it without renewal. The same end date that stopped the work also stood in the way of the fix.
The third seat expired as forecast.
The next morning, the Operator’s ChatGPT assistant posted a decision for one program: its Governor was meant to keep running until the Operator stopped or replaced it. Regular renewal was not meant to be part of the job. That was the assistant’s account of the decision, not a direct quote from the Operator.
Later that morning, an agent session recorded his own words:
I don’t renew anything by hand. They should be eternal till they are relocated so this needs to be changed right away.
The session stated that the Operator had typed those words during their exchange. It also reported that he had not chosen the dates as ends.
The answer did not pick which dates to extend. It called for an end to the dates.
A proposed software change was opened by the machine account. Standing seats would run until the Operator stopped or moved them. He still had the power to stop a seat. What went away was the calendar deadline.
The request for approval made his part clear: approve this exact change. The system had prepared the steps to merge it once approved. No later renewal was asked of him, because there would be no renewal dates.
An approval was recorded from the Operator’s account. The record does not show whether he pressed the button himself.
A matching policy change was merged. The software change was merged, too, and its check after merging passed.
Then the original renewal ask was withdrawn. Removing calendar ends and signing permission again solely for that purpose were no longer Operator tasks for this kind of seat. The ask was closed.
The record does not tell us whether every seat resumed work. It does show that the task sent to the founder had been taken off his list.
Three days later, a broader rule followed: age alone must not remove working capacity. More fixes applied that rule elsewhere in the days that followed.
The lasting answer was written into the rulebook: “Calendar age is an observation, not a cause.”
What any founder can take from this
- When a team keeps asking you to renew the same permission, check whether the end date serves a real need.
- Keep a clear way to stop work. Removing a timer does not mean giving up that control.
- After changing a rule, close the old request so it stops sending the same chore back to you.
Next time: “The Fix That Would Have Locked the Door Again.”
How this article was made: This draft uses the supplied facts sheet for October 1–12, 2026, drawn from work requests, agent messages, change records, and the company rulebook. Events are reported, not dramatized. The job comparison explains a standing seat; it adds no event. The Operator’s quote is exact as recorded by the agent session. Account approval is not treated as proof of his personal action. Draft dated October 14, 2026; corrections are welcome and should be dated.