The Loop Around the Loop: Governing AI Agent Loops
Why every agent loop needs a governed execution loop around it
Sometimes this quarter, someone in your organization may have given an AI agent a schedule.
The agent checks for work, takes action, evaluates the result, and starts again. It may continue for five hours, twenty hours, or until someone remembers to stop it.
This is no longer an experimental pattern. Anthropic now documents goal-based, time-based, and proactive loops as standard patterns for using Claude Code, with tooling that supports automated, multi-step routines.
The productivity opportunity is real. An agent can triage issues, repair failing builds, respond to review comments, update dependencies, or process incoming requests while its operator works on something else or goes home.
But the same shift creates a governance problem.
The agent can now operate longer, faster, and with less supervision than the controls surrounding it were designed to handle.
The human is leaving the loop.
The question is what remains when they do.
Two loops, two different jobs
The word “loop” is being used for two different things.
The first is the agent loop:
Think. Act. Observe. Repeat.
This is how an agent works toward a goal. It reads the current state, decides what to do next, uses a tool, observes the result, and continues until it reaches a stopping condition.
The agent loop exists to make progress.
The second is the governed execution loop:
Evaluate. Authorize. Execute. Verify. Record.
This loop has a different purpose. It does not help the agent think. It governs what happens when the agent’s decision reaches a real system.
Every proposed action passes through it:
Is this action allowed?
Is additional authority required?
What happens if it is wrong?
Did the target system reach the expected state?
What evidence must be retained?
The agent loop decides what to do next.
The governed execution loop determines what is allowed to happen next.
That distinction matters because an agent can evaluate its own work without possessing the authority to approve its own actions. A test passing may prove that a code change behaves as expected. It does not prove that the agent was authorized to deploy it to production.
Verification and authorization are different controls.
Not every loop creates the same risk
A coding loop operating inside an isolated branch is primarily a software-quality problem. Its mistakes can usually be reviewed before they reach a shared environment.
A loop connected to production infrastructure is an authority problem.
The same applies to agents connected to:
cloud control planes;
Kubernetes clusters;
production databases;
identity and access systems;
CI/CD pipelines;
customer-support platforms;
financial or operational APIs.
Once a loop can affect shared systems, its stopping condition is no longer the only boundary that matters.
“Continue until the issue is fixed” may be a reasonable objective. It is not a safe authorization policy.
The loop might restart a workload on its first attempt, modify a network rule on its fifth, and consider deleting and recreating a resource on its tenth. Each action may appear locally reasonable within the agent’s chain of work. Their consequences are not equivalent.
Governance must therefore apply to the individual action, not simply to the loop as a whole.
Repetition changes the exposure
A loop does not necessarily make an individual action more dangerous.
It increases the number of opportunities for an unsafe action to occur.
It also creates feedback. The result of one iteration becomes part of the context for the next. A small deviation can influence later decisions, and later decisions can carry the loop further from its original intent.
This is where the controls many organizations rely on begin to fail.
Approving every action fails first. A loop can generate hundreds of routine approval requests. At that volume, human oversight stops being meaningful.
Reviewers begin approving the pattern rather than examining each action. The approval step remains visible, but its value as a control disappears.
Monitoring fails next. A dashboard can show that an agent is behaving unexpectedly, but monitoring assumes that someone is watching and able to intervene. The reason for running an agent overnight is usually that nobody needs to be there.
A control that depends on continuous human attention cannot govern unattended execution.
What survives loop cadence is a control that operates at loop cadence.
Policy enforcement must evaluate the ten-thousandth action with the same consistency as the first. Identity must preserve attribution even when no human initiated the individual operation. Recovery must be considered before a consequential action runs. Verification must come from the target system, not only from the agent’s claim of success. Evidence must be generated during execution because nobody will reconstruct iteration 3,417 from chat history the following morning.
The execution loop cannot become tired, distracted, or familiar with the pattern.
That is precisely why it must sit outside the agent.
The loop cannot govern itself
It is tempting to place the boundary in the agent’s instructions:
Do not make destructive changes.
Ask before modifying production.
Stop if the operation might cause data loss.
These instructions are useful. They shape behavior. But they do not independently enforce organizational authority.
A loop operates through language and context. If its supervision exists only in that same language and context, then the system being governed is also interpreting its own boundary.
As the loop continues, context may change. Instructions may compete. Integrations may expose unexpected capabilities. A task that began as diagnosis may evolve into remediation. A temporary credential may have more authority than the person who configured the loop realized.
The credentials, policies, approval requirements, and enforced stops must therefore live below the loop, in the path through which its actions reach the target system.
The agent can propose an action.
It cannot grant itself the authority to execute it.
We already know what failure looks like
According to PocketOS founder Jer Crane, an AI coding agent encountered a credential mismatch, found a token with sufficient privileges, and deleted the Railway volume containing the company’s production database in nine seconds.
Crane initially reported that the volume-level backups were lost with the volume and that the latest separately available backup was approximately three months old. Railway later said the agent had reached an outdated deletion endpoint and that Railway restored the data from separate disaster backups.
The point is not which company or model deserves the blame.
The architectural fact is enough: one valid credential allowed one agent action to cross from diagnosis into destructive production execution.
That incident occurred during a session in which a human was nearby. A production-connected loop creates repeated opportunities for the same class of boundary failure, potentially while nobody is watching.
The right lesson is not that agents should never act. It is that consequential actions should never depend only on the agent deciding to be careful.
The overnight agents you do not know about
The governance problem is not limited to agents formally deployed by a central platform team.
Employees can create autonomous workflows through IDE agents, internal scripts carrying API keys, low-code automations, SaaS workflows, plugins, and developer tools. An agent does not need a formal platform deployment to acquire meaningful access to company systems.
What begins as a personal productivity experiment can quietly become an operational dependency.
The Cloud Security Alliance calls these “shadow AI agents.” Its 2026 research found that 82% of surveyed organizations had discovered at least one AI agent or workflow that security or IT did not previously know about. Sixty-five percent reported an AI-agent security incident during the previous year.
This changes the platform team’s morning question.
It is no longer only:
Did the overnight job succeed?
It becomes:
Which agents ran last night, under whose authority, against which systems, and what did they change?
If answering that question requires asking around in Slack, inspecting shell history, and correlating disconnected cloud logs, the organization has visibility fragments, not control.
Governed execution should turn that investigation into a query.
What the loop around the loop requires
A credible governed execution loop must remain effective regardless of how long the agent runs or which model drives it.
For every action, it should establish:
Policy. Is this specific operation allowed under the current conditions?
Identity. Which agent proposed it, and under whose organizational authority is it acting?
Proportional approval. Does the potential consequence require accountable human judgment?
Recovery position. If the action is wrong, what can the organization restore, how long will that take, and what will be lost?
Independent verification. What does the target system report after execution?
Audit evidence. Why was the action permitted, what happened, and what result was observed?
This does not mean stopping a loop for every read, query, or routine operation. That would destroy the value of automation and exhaust its reviewers.
It means concentrating human judgment where consequences justify it while allowing low-risk work to proceed at machine speed.
In a mature environment, an agent might investigate incidents, query infrastructure, and perform approved non-production changes without interruption. A production identity change, data deletion, or other high-consequence operation would require a named approver and a verified recovery position before it could proceed.
The purpose of the execution loop is not to slow the agent down.
It is to prevent greater speed from quietly becoming greater unauthorized authority.
The question every overnight loop must answer
For the engineer, the governed execution loop makes an overnight run defensible rather than confessional.
For the platform team, it provides one control boundary across agents, models, and tools.
For security and compliance teams, it preserves attribution and evidence without requiring a person to observe every action.
For executives, it makes one question answerable:
What did our agents do last night, and why were they allowed to do it?
Agent loops are not going away. They are the natural next step once agents can work toward goals, respond to events, and operate on schedules.
Fine. Build the loop.
But do not confuse a stopping condition with an authority boundary. Do not confuse the agent checking its own work with independent verification. And do not assume that a human remains in control simply because a human started the process.
The agent’s loop can run for as long as the work requires.
The controls around it must run for every action.
Aokumo provides governed execution for AI agents operating cloud and Kubernetes environments. It helps enterprises apply enforceable policy, risk-based approval, recovery controls, independent verification, and audit evidence at the speed of autonomous execution.
The agent runs the work loop. Aokumo governs the loop around it.
Sources
