What are the office hours of an AI agent?

MEHO — Mon, 09 Nov 2026 12:19:47 +0000

Ask anyone why their company is suddenly interested in AI agents for operations and, once the slides are out of the way, the honest answer is usually about the clock. Agents do not sleep, do not take holidays and do not mind being asked to do something tedious at two in the morning, and in infrastructure the tedious things have a habit of becoming urgent precisely at that hour: the certificate that expires overnight, the datastore that fills up on a Sunday, the service that falls over on a public holiday and waits for someone to notice. Vendor material across the category leans on this; one widely read 2026 guide lists "no fatigue" and "AI as first responder reduces human fatigue" among the core benefits of AI in site reliability [1].

The same guide, a few paragraphs later, describes where the industry actually stands. Autonomous remediation "remains limited, with human oversight and decision-making central to production environments"; the recommended model is "AI proposes, human approves, AI executes"; and agents that act in production without approval gates are called "a liability risk, not a productivity gain" [1]. Put those two passages next to each other and the tension is obvious. The thing being sold is work that happens while you sleep. The thing being shipped is work that waits for you to wake up and click.

The design debate is open, not settled

The practical literature on human-in-the-loop design has converged on one principle: gate actions by their nature, not by the clock. A representative 2026 guide recommends placing each action type on a spectrum according to reversibility, blast radius and confidence, adding a gate when two of the three are elevated, and widening an agent's permissions one step at a time as it builds a track record [2]. On the specific question of what to do when an agent needs approval and nobody is available, the same source lists the options honestly: checkpoint files the agent writes and polls, timeouts that abort by default and log the pending action, escalation to a secondary approver, or proceeding after a timeout. It offers no standard answer, and notes that its own dollar thresholds are examples rather than norms [2]. In other words, the overnight problem is a live design question with several competing answers and no consensus.

The human gate is weaker than it looks

There is now empirical evidence that the "human approves" model degrades under volume. In August 2026 The Register reported on a browser game built by developer Alex Wauters that simulates coding-agent permission prompts. Across more than 40,000 runs and 409,000 decisions, players approved roughly one in three malicious requests. Scope violations such as reading Kubernetes config or cloud credentials were missed 35% of the time, and one innocuous-looking but malicious script was approved by nearly two thirds of players even though its contents were visible in the log. Obviously destructive commands were the ones most often caught [3]. The game is informal and front-loads far more malicious requests than real work would, which the author acknowledges, but the real-world telemetry quoted in the same article points the same way: Anthropic reports that users approve about 93% of Claude Code permission prompts, and states plainly that "the more approvals a user sees, the less attention they pay to each" [3].

The implication for the night shift is uncomfortable. A design that depends on a human reading each request carefully is already fragile at two in the afternoon. At two in the morning, with a tired on-call engineer woken by a notification, it is not a control at all.

How we approached it

When the question first came up in our own lab, which runs VMware Cloud Foundation environments for more than a hundred engineers with AI agents doing operational work under supervision, we tried to answer it the way it was asked, by sorting operations into ones that felt safe enough for the night and ones that should wait for daylight. Restarting a visibly failed service seemed fine. Growing a disk, probably. Touching the network, not without a person. It was a sensible conversation and the wrong one, because every answer leaned on an assumption we could not guarantee: that during the day someone would be watching and at night nobody would.

Before describing what we did instead, it is worth saying what we did not do, because it is where our approach parts ways with most of the field. The common pattern today is to give the agent freedom to write its own scripts and execute them, and to put a second agent in front of it as a supervisor that decides whether each action is acceptable. Gartner has already named this category: "guardian agents", reviewers, monitors and protectors that can "redirect or block actions" of other agents, forecast to make up 10 to 15 percent of the agentic AI market by 2030, on the argument that humans cannot keep pace with what multi-agent systems get wrong [4]. That is an optimistic design: it assumes the supervisor will understand what an arbitrary script does, at three in the morning, better than the agent that wrote it. We did not want our safety at night to rest on one model grading another. So we went the slower way. The agent does not write operations; it chooses from a catalogue of operations we wrote in advance, each with a known blast radius. Every one of those operations goes through an ordinary software development lifecycle, with code review, versioning and tests against real systems in the lab, before an agent is ever allowed to call it; nothing reaches the catalogue because a model generated it on the spot. Because we know what every operation can touch and what the worst case looks like, we can classify it by risk and put a deterministic policy in front of it, a plain rule that checks who may do what, with no judgement call involved. The agent cannot take credentials, because it never holds any, and it cannot widen the scope of an operation, because the scope is fixed in the operation itself. Building connectors and operations this way is tedious and unglamorous work, and it is the only deterministic way we know to be certain of what an agent is doing.

That is what makes the rest possible. Permission is tied to the operation and the identity rather than the hour. Every operation carries one of four risk levels. An agent acting on its own may only execute operations classified as safe; anything above that is parked until a human approves it, or runs only where someone has deliberately granted that specific automation a standing permission for that specific class of work. The most destructive operations wait for a person every time, and no grant bypasses that. A parked request is not cancelled and never runs by itself; it waits, with its own audit record, for up to fourteen days before expiring with a second record saying so. Since October, approving requires a recent human sign-in, so a stored CLI, MCP or API token can never approve anything, including its own requests. There is no time-of-day policy, by design: the rule at 03:00 is the rule at 15:00, and it can be that simple only because the thing being permitted is a known, tested operation rather than whatever the agent came up with.

Three entries from our lab notes show different sides of this. In August an agent was told to bring a new lab environment to full parity overnight without stopping to ask. Around two in the morning it hit the one wall it cannot climb on its own: the human credential it was working under expired, and only a person can renew a person's login. It wrote its full state to disk, left the operator a single command to run on waking, and once that was run it picked the chain up exactly where it had stalled. In June, during an ordinary working day, the operator parked a change for approval and then tried to approve it himself; the system refused, because requester and approver must be different people. When he tried routing the same request through an agent, it was refused again, because an agent started by a human acts under that human's identity, so four-eyes still saw the same person on both sides. And during a storage rebalance that had degraded part of the cluster, the team chose to diagnose rather than force a repair; the agent's token expired overnight before the diagnosis finished, and by the next morning the cluster had healed itself without anyone touching it.

None of these is a story about the clock. The first shows what a well-behaved agent does when it runs out of authority at night: it stops and leaves a clear handover, rather than failing or improvising. The second shows that the approval rule does not bend for the person who owns the agent. The third is a reminder that the cheapest safe action overnight is often to wait.

What this means for the business question

The office hours question turns out to be a trick question. If an agent's permissions depend on who is awake, the organisation does not have a control, it has a hope. If they depend on the operation and the identity, decided in advance by the people who own the consequences, then the agent's working hours are simply always, and the risk conversation becomes an ordinary one: the same logic a company already applies to who may approve a payment or sign a contract, applied to who may change infrastructure. That conversation has to happen before the first night shift, not after the first incident, and the evidence above suggests that "a human will check" is not a sufficient answer to it.

We would be interested in how others have resolved the timeout question in particular, since the field has not. We chose waiting over aborting. There are good arguments for the other choice.

Sources